There is a moment, a few weeks after an AI-built project goes live, where the nature of the work changes completely and nobody announces it.
Up to that point everything was building. Prompt, run, look, adjust. Fast, legible, satisfying. Then the building finishes and the project enters the part nobody vibe-codes: it has to run. Continuously. On a machine. Facing the open internet. While you do your actual job.
That second phase has no prompt. It is operations, and it is a different discipline from writing code — which is why plenty of very capable developers still hire someone else to do it.
What “running it” means in practice
If your AI-built app is sitting on a VPS you span up during the build, here is the standing workload that now belongs to you:
- Operating system patches, applied before the exploits for them become public rather than after.
- The runtime underneath your code — PHP, Node, Python — tracked across versions, because branches reach end of life and stop getting security fixes whether you are ready or not.
- Dependencies, which number in the hundreds for most generated projects, each with its own advisory feed.
- A firewall that is actually restrictive, rather than the default of everything open because that was easiest while you were testing.
- SSH hardened: key-only, no root login, no password auth. The default on a fresh droplet is a password prompt that bots are already hammering.
- TLS certificates that renew reliably, including the renewal that fails quietly at 3am in eleven months.
- Database access locked to localhost, not listening on a public port with the password the AI generated in the setup script.
- Backups off the machine, tested by actually restoring them, because an untested backup is a belief rather than a plan.
- Monitoring, so that “the site is down” reaches you before it reaches a customer.
- Logs you can read later, which is the difference between knowing what happened in an incident and guessing.
None of this is exotic. All of it is standard. The problem is that it is standard for people who do it professionally, and an AI build does not produce a person who does it professionally. It produces a working app and an empty chair.
Why the default setup is worse than you think
When you ask an AI to get an app deployed, it optimises for the thing you asked: the app being reachable. That produces a server configured for the demo and not for the next three years.
We see the same handful of things again and again. The database open to the world because that made the connection string work. Root SSH left on because it was faster. Debug mode still enabled in production, printing stack traces with file paths and sometimes credentials to anyone who triggers an error. A .env file sitting inside the web root, fetchable by URL. Automated deployment running as root. The one test that was run was “does the homepage load”, and it passed.
Every one of these is a five-minute fix on day one. Every one is a disclosure event or a ransomware incident later.
Our post on hardening a server for a custom warehouse system walks through what the other version looks like on a real project — not a bigger server, just a correctly configured one.
The care plan is the empty chair
This is precisely the job our Managed Web Server plan exists to do, and it is the plan we point AI-built projects toward most often, because the thing they are missing is not WordPress maintenance — it is an operator.
What it covers:
- Deployment and provisioning on AWS, Alibaba Cloud, DigitalOcean, OVHcloud or Hetzner, with server costs included in the plan rather than a separate bill you forget about.
- Hardening — firewall, SSH, security headers, database lockdown — done once, properly, and then kept that way.
- Uptime and security monitoring, so problems surface as alerts rather than as complaints.
- Air-gapped off-site backups, held away from the server they protect.
- Cloudflare DNS and CDN management, which also puts something in front of your app that absorbs the routine hostile traffic every public IP attracts.
- WhatsApp support, for the Saturday when something is wrong and you need a human.
It starts at RM120 a month. If your project is WordPress plus some AI-built additions on top, Managed WordPress + Web Server covers both layers from RM150. Full pricing is on the care plans page.
To be clear about what it is not: we are not maintaining your application code. We are not adding features, and we are not taking responsibility for logic we did not write. The plan covers the platform your code runs on — which is, conveniently, where almost all the security exposure lives, and the part you are least equipped to handle yourself.
The real argument
The appeal of vibe coding is that it removed a dependency. You no longer need a developer to get from idea to working software, and that is genuinely a good thing for a small business in Malaysia that was previously quoted five figures for a brochure site.
But it only removed one dependency. The server still needs running. The patches still need applying. Somebody still has to be awake when it breaks. AI moved the bottleneck; it did not delete it.
The honest question is not whether you can build it yourself. You clearly can, and did. It is whether you want operations to be your second job — because once something is live and customers are using it, it is somebody’s job, and by default that somebody is you.
If you have an AI-built app running on a server nobody is looking after, get in touch. We will look at what is exposed, tell you plainly what we would change, and you can decide from there. If it has already gone wrong, that is Emergency Rescue first, and a plan afterwards.