You spent three months and a few hundred hours building something that mostly works. It demos well. Then you tried to make it production-ready, and everything stopped: you are not sure whether the data is safe, payments are half-connected, it slowed down when a few people used it at once, and every fix you prompt for breaks something you fixed last week.
This is now one of the most common situations we are asked about, and the first thing worth saying is that you have not wasted your time. What you have is a working specification that happens to run, and that is genuinely valuable: every screen is a decision you have already made and proven. What it is not yet is a product, because the parts an AI builder produces fastest are the visible ones, and the parts it leaves out are the ones that decide whether you can safely have customers.
What it takes to make an AI-built app production-ready: the seven gaps
In roughly the order that they will hurt you.
- Anyone can read your database. This is the big one, and it is close to universal. Modern builders pair the app with a hosted database whose security depends entirely on rules you have to write per table, and those rules are frequently absent or wrong. Independent security researchers who scanned large numbers of AI-built applications during 2025 and 2026 reported flaws in the overwhelming majority, including live apps whose customer tables could be read, and in some cases emptied, by anyone who asked politely. One popular builder was found in 2025 to be creating databases with those protections switched off by default. If you take one thing from this article: before you launch, have someone confirm that every table has rules and that they are the rules you think.
- Your keys are in the browser. Anything a visitor's browser can load, a visitor can read, including the payment key, the AI provider key and the database's administrator key if they were placed in the front end. Keys with a name suggesting they are public usually are; the dangerous ones are the ones that bypass every other protection. Rotating them afterwards is easy. Discovering it after a bill arrives is not.
- Accounts that only look like accounts. Sign-up and sign-in are the easy half. The half that gets skipped: verifying an email address, resetting a forgotten password safely, ending a session, stopping one customer from loading another customer's record by changing a number in the address, and deleting an account when someone asks, which the app stores now expect.
- A data structure that fits demonstrations rather than businesses. Duplicated records, no relationship between the things that should be related, no history of what changed. This is the one that produces the symptom people describe as "it kind of worked, and then integrations started breaking, search slowed down and data kept duplicating". It is also the most expensive to fix late, because everything built on top has to move with it.
- Nothing happens when something fails. No retry when a payment webhook does not arrive, no queue when an email provider is briefly down, no logging you can search when a customer says it did not work, no alert to tell you before they do. Software that only has a happy path is a demonstration.
- It has never been run by more than one person at a time. Queries that read the entire table, images served at full size, work done while the customer waits that should happen afterwards. Fine at three users, visibly bad at fifty, and this is usually what people mean when they say it slowed to a crawl.
- No way to release a change safely. One environment, no copy to test on, no version history you can go back to, no way to undo. This is why every prompt-driven fix seems to break something else: you are editing production with no net, and nobody could work that way.
Read that list looking for how many apply to you. One or two is a fortnight of work. Five or more is not a repair, it is a rebuild wearing your screens as a specification, which is still a much better position than a blank page.
What a developer actually does with what you have
Not, in most cases, throw it away. A sensible sequence looks like this, and it is worth knowing so you can tell whether the person you hire is doing it.
- Read it and write down what it does, screen by screen, because your app is now the requirements document and nobody has ever written those down.
- Close the [security holes](/services/care/security-updates) first, before any feature: database rules, keys moved to the server, the account gaps above. This is the part that is genuinely urgent.
- Fix the data structure, if it needs it, while the amount of data is small and the migration is cheap. Every week of real customers makes this dearer.
- Put it on rails: version control, a copy to test on, a scripted release, a way to roll back. Boring, quick, and the thing that makes everything afterwards affordable.
- Add what fails gracefully: retries, queues, logs, alerts, an error page that is not a blank screen.
- Then, and only then, the features you actually wanted.
A common and reasonable shape for this is one experienced developer for four to eight weeks, rather than a team. Illustratively $8,000 to $35,000 for a straightforward finish, and $35,000 to $90,000 where the data structure has to be rebuilt underneath a live product. Compare that honestly with what a first version costs from scratch, in our guide to what it costs to build an app: finishing is usually cheaper, and it is much faster, because the arguing has already happened.
Keep it or start again: the test
Four questions. Two or more yeses point at a restart of the parts underneath, keeping your screens and your decisions.
- Does the way the data is organised match how the business actually works? Not the screens, the underlying records. If the app thinks a customer and an order are the same thing, that will not survive.
- Can anyone explain what the code does? Ask whoever looks at it to describe one feature end to end. If it takes them an hour and they are unsure, that is a signal about every future change.
- Does one change break unrelated things? If yes, the pieces are tangled, and tangling gets worse with size, never better.
- Is it built on something that will still exist in three years? A generated app that only runs inside one vendor's environment is a business risk regardless of how good it is.
What is not a reason to restart: the code is untidy, it is not the framework your new developer prefers, or it was written by AI. Plenty of perfectly good production software is unglamorous inside, and "an amateur coded it" is a description of most first versions of most successful products.
How to brief someone on it without wasting a month
The single biggest cost in these projects is the developer working out what you meant. You can remove most of that in an afternoon.
- Give them access rather than descriptions: the builder account, the repository, the database, the hosting. Read-only is fine to start.
- Record a walkthrough. Twenty minutes of you using your own app, out loud, explaining what each screen is for and which parts you know are broken. It is worth more than any document.
- Write down the three things it must do, and be ruthless. Everything else is version two.
- Say plainly what is fake. Almost all of these have something stubbed: payments that do not really charge, emails that do not really send, an admin screen that does nothing. Nobody will judge you, and finding it out in week three is expensive.
- Gather the scattered thinking. If your specification currently lives across text messages, an email thread and a forty-page document, an hour spent consolidating it will save several days.
- Ask for a written assessment first, before any building. A fixed, small piece of work that tells you which of the seven gaps you have. If it is honest, it will also tell you which ones do not matter yet. That is exactly the health check we run when adopting software we did not build, and it is the same discipline described in our guide to taking over a codebase.
Not for you if
The decision you are actually making
You are not deciding whether what you built was any good. You built a working model of your idea without being able to code, which was not possible three years ago, and it has taken you further than most people get. What you are deciding is whether the next stretch, the unglamorous part where software becomes something you can safely charge for, is work you want to keep doing at a few hours a night with prompts, or work you want to hand to someone who has done it before. Both are legitimate. Only one of them gets you to launch this quarter.