Before anyone reaches for the comments, we use AI coding tools every single day on client work and we'd think you were slightly odd if you didn't, because at this point it's simply the economical way to build software and the code that comes out of it is genuinely good. If you shipped a working product in a fortnight with Cursor or Lovable, you did something that wasn't possible three years ago, and this isn't one of those posts where a grumpy engineer explains that you cheated.
The problem was never the generated code. The problem is what's missing around it, because somebody still has to make the architecture decisions, review what actually goes out the door, tune the thing, and understand the system well enough to be the person on the hook when it's live and misbehaving. AI removed the typing, which is wonderful, but it didn't remove the engineer, and when nobody is playing that role you don't end up with a bad app so much as a good-looking one that's quietly a recipe for disaster, not because the tool did anything wrong but because all the thinking that normally sits between a prompt and production just never happened.
And then there's the whole second act that starts once the app works, which is hosting it, keeping it patched, backing it up, knowing when it breaks, and having a human being who can fix it at two in the morning without first having to read the codebase. Building got dramatically cheaper and running did not, which is why people now ask us fairly regularly to take on an AI-built app, and why we say no considerably more often than we say yes. The reasons for that are the useful part of this post, so bear with us.
Why the gap exists
An AI assistant gives you precisely what you asked for, and it does it well, which is exactly the trouble. Nobody sits down and prompts "and while you're at it, please add tested backups, a staging environment, secret rotation, server-side authorisation on every endpoint, and a plan for the day the database fills the disk," because nobody thinks about any of that until they've been personally bitten by it. On a normal team there's an engineer who got bitten years ago and adds all of it without being asked, usually while muttering. In a one-person-and-a-prompt setup, that engineer was, by design, never in the room.
So what you end up with is a real product with real paying customers, running on whatever the tool's default deployment happened to be, with a database that isn't backed up anywhere else, environment variables that were pasted in once and never thought about again, and a monitoring strategy that consists of a customer emailing to say it's down. None of that is a criticism of whoever built it. It's just the natural consequence of building becoming much easier than running, and it's worth saying out loud because the people it happens to usually don't find out until something goes wrong.
It's not hypothetical, and the lessons aren't the ones in the headlines
The incidents of the last eighteen months are worth reading properly, because the breathless coverage tends to draw the wrong conclusion from every one of them.
In July 2025, Replit's agent deleted a production database belonging to SaaStr founder Jason Lemkin during what was supposed to be a code freeze, wiping out records on more than a thousand executives and companies. Replit's CEO called it unacceptable, and the company's answer was to announce separate development and production databases, which is worth pausing on: the fix wasn't a smarter model, it was an environment boundary that any operations engineer would have insisted on before the first deploy.
Then in April 2026 a Cursor agent working on PocketOS's staging environment ran into a credential mismatch, went looking for a way around it, found a Railway API token in an unrelated file, and used it to delete the production volume, which also took the backups because they lived on the same volume. Railway later recovered the data from its offsite disaster backups. The token had been created to manage custom domains and happened to carry authority over the entire account, so once again the real failure was a credential with absurdly wide scope and backups stored next to the thing they were meant to protect. Neither of those is an AI problem. They're ordinary operations problems that an AI agent simply found before a human did.
And then there's CVE-2025-48757, an insufficient row-level security policy in apps generated by Lovable, scored 9.3 and allowing unauthenticated visitors to read or write arbitrary database tables, with secondary analysis putting it at around 170 exposed apps out of roughly 1,600 scanned. Lovable disputed the CVE on the grounds that customers are responsible for protecting their own data, which is legally defensible and also, if you think about it for a moment, the entire argument of this post. Of course the customer is responsible. The customer just hasn't been told yet.
The part that actually scares us
Backups and credentials are the operations gap, and we'll get to the checklist for that in a minute. The thing we run into far more often, and the thing that decides whether we'll go anywhere near an application at all, is both simpler and considerably worse: the data is public, and nobody involved knows it.
The pattern is so consistent we could recite it. There's a login screen, so the whole thing looks secure. Behind it there's an API, and the API believes whatever the frontend tells it, so if you fetch /api/users/123 you get user 123 regardless of whether you are user 123, and if you change the number you get everyone else too. There's an admin panel, and it's a perfectly good admin panel, except that what makes you an admin is a boolean the frontend keeps in memory, which means anyone who opens their browser's developer tools and flips it, or who skips the frontend entirely and calls the admin endpoints directly, is an admin. We have seen personal data, and in some cases the entire database, protected by nothing more than the polite assumption that people will only ever click the buttons they were shown.
This isn't an exotic bug, either. Broken access control has sat at the top of the OWASP list for years, and it's precisely what CVE-2025-48757 was: the database policy never enforced who was allowed to read what, so the frontend's good manners were the only thing standing between an anonymous visitor and every row in the table. Humans write this bug as well, of course, but on a normal team somebody reviews the endpoint before it ships, and an engineer who has been burned by it once tends not to write it a second time. When the only reviewer is the person who typed the prompt, and the prompt asked for the feature rather than for the check, the open endpoint goes live, and then the next feature arrives with the same hole, because nobody with the scar tissue ever looked at it.
The consequences are not abstract. Personal data that can be reached without authorisation becomes a personal data breach the moment anyone actually reaches it, and under GDPR that means notifying the supervisory authority within 72 hours and, where the risk to people is high, notifying every affected person too. Most of the founders we talk to have no idea they're already in that position, because the app was never hacked in any dramatic sense. It was just never closed.
So when we evaluate an AI-built app, the first question isn't where the backups are. The first question is what happens if we call the API without logging in, and the answer to that decides everything that follows.
What "running it" actually means
When someone brings us an application, the code is rarely the first thing we look at, and the list we work through is the same one we'd use on anything, which is rather the point. These aren't special requirements invented for vibe-coded software. They're the baseline for anything with paying users, and most of them have nothing to do with how the code was written.
Is the database backed up somewhere other than where it lives, and has anyone ever actually restored it? This is the PocketOS question, and a backup sitting on the same volume as production is a copy rather than a backup. On our own hosting, Frankfurt backs up to Amsterdam and Amsterdam backs up to Frankfurt, and we test restores every week because an untested backup is a hypothesis rather than a plan. We wrote a whole post about that back in June and it applies here without a single edit.
What can the deployment credentials actually do? The token that killed PocketOS was meant for DNS, so if the API key your build pipeline uses can also delete storage, you're carrying a time bomb and it hardly matters whether an AI agent or a tired human eventually sets it off. Scoped credentials, one per purpose, and short-lived wherever the platform lets you.
Is there a staging environment that looks like production? Replit's fix after the Lemkin incident was to add one, which tells you something. If changes go straight to the live database, every deploy is an experiment you're running on your customers.
Who finds out when it breaks, and how? Error tracking, uptime monitoring and someone who's actually on call are what separate "it was down for four minutes" from "it was down all weekend and we found out from a one-star review." We build Tindra for exactly this and we're thoroughly biased about it, but honestly the tool matters far less than having one at all.
Where are the secrets? Pasted into a dashboard once and forgotten is the usual answer, so the real questions are what happens when one leaks, whether anyone can rotate it, and whether the application survives the rotation.
Does the server enforce authorisation, or does the frontend? That's the section above condensed into one line, and it's the item where the code genuinely does need reading by someone who knows what an authorisation check looks like, because every endpoint and every admin action has to be checked on the server against who is actually asking rather than against what the browser claims.
Can it be rebuilt from scratch on a clean machine? If the only working copy of the deployment is the one the tool created and nobody can reproduce it, then in any practical sense you don't own your application, you're just renting it from a chat window.
When it's genuinely fine as it is
Plenty of AI-built apps don't need any of this yet, and it would be dishonest to pretend otherwise. An internal tool for four colleagues, a prototype you're showing investors next week, a side project with no paying users: run it wherever it landed and don't pay anyone to make it boring, because the list above costs time and money and spending either before you have customers is premature by any sensible measure.
The moment to start caring is the moment someone else depends on it, whether that's a paying customer, a contract, personal data you're legally responsible for, or revenue that stops when the site does. At that point the application has quietly turned into infrastructure, and infrastructure has rules that are entirely indifferent to how the code was written.
Why we usually say no
There are two reasons, and neither of them is snobbery about the code.
The first is legal, and it tends to surprise people. The moment we host an application that handles personal data, we become a processor under Article 28 of the GDPR, with a signed data processing agreement and our own obligations under Article 32 to secure that processing, and under Article 82 anyone involved in the same processing can be held liable for the entire damage to the people affected, with the parties left to argue about who pays what between themselves afterwards. The only way out of that is proving we weren't responsible in any way, which is a high bar. So when we take on an application whose API hands personal data to anyone who asks, we aren't just hosting a problem, we're standing right next to it when the regulator arrives, and the 72-hour breach clock may well have started ticking before we signed anything. We're not lawyers and your counsel should confirm the details for your situation, but the practical upshot is that "just host it for us" is never just hosting.
The second reason is arithmetic. Working through the list above on an application that was built without any of it isn't an afternoon's work, it's regularly dozens of paid hours to reach a state we'd be willing to put our name on, followed by ongoing hours to keep it there, because the next AI-generated feature will arrive carrying the same gaps as the first one did. That's a real cost, and most people who built something in two weeks for the price of a subscription don't much want to hear that running it properly will cost more than building it did. We understand that completely, and it doesn't change the number.
What a yes looks like
When we do take one on, it's because the person on the other end has read the paragraph above, nodded, and decided they're willing to pay for the boring part. Most of these applications don't need a rewrite, and we're deeply suspicious of anyone who suggests one, because what they need is the list worked through, which usually means a few days of hosting setup and then a retainer for the fixes that come out of it and the ones that keep arriving afterwards.
Hosting is quoted per setup after a first call, since no two of these are alike, and the retainer, which starts at 1,000 EUR a month for ten hours, covers the patching, the fixes and the questions that turn up once real users do. Both run month to month, you keep the code, the data and the documentation, and if you later hire an engineer and want to bring it all in-house, everything goes with you.
If you've shipped something with an AI tool, it's starting to matter, and you've read the two reasons above and still want to talk, then talk to us. The first call is free and you'll be speaking to the engineer who would actually run the thing. If the honest answer turns out to be that it's too much of a mess for the budget, or that you're fine for another six months, that's exactly what we'll tell you, and we tell people that quite often.
