What It Costs to Turn an AI-Built App Into a Real Product

You searched for a price. You found agency pages that say "contact us", a few posts padded with ranges wide enough to be meaningless, and nothing you could put in front of a co-founder. We are about to do part of the same thing, so let us be honest about it in the first paragraph.

We sell this work (AI Code Cleanup is one of our services) and we publish no rate card. What we can do, and what almost nobody bothers to do, is hand you the structure of the number: the shapes this work gets billed in, what genuinely moves your figure, which findings are cheap and which are not, and how to compare two quotes that look nothing alike. Do that and you can budget this yourself inside a range you trust, and spot the quote that is about to hurt.

Why nobody will quote this from a description

Because the same sentence covers wildly different jobs. "My AI-built app has bugs and I need it production ready" can mean four hours of moving API keys to the server, or it can mean a data model that lets one customer read another's records, discovered after nine months of real signups. Those are not the same purchase, and no page can tell which one you have.

So a published price would be one of two things. Padded for the worst case, in which case the straightforward job subsidises the difficult one and you overpay for the privilege of skipping a conversation. Or a teaser, revised upward once somebody actually looks, which is a sales tactic rather than a price.

Our version: we look first, free, and we only quote work you have told us you want to proceed with.

The three shapes this gets billed in

Whatever a provider calls it, they are using one of these. Knowing which one you are being sold is most of the battle.

One fixed price and one timeline, when the work can be scoped. After somebody has read the code and the scope is clear enough to commit to, you should get one number and one date. Most cleanup work lands here, because once you know what is wrong, fixing it is ordinary engineering.

Hourly, when it genuinely cannot be scoped yet. Deep unknowns, or a scope that will move as everyone learns. Hourly has a bad reputation and it is the honest answer here, because padding a fixed price for unknowns means you pay for that risk whether or not it happens.

A fixed monthly fee, when there is no finish line. Not cleanup at all, but worth naming so you can tell it apart: keeping software shipping, watched and healthy is a recurring scope, not a project. If you are being sold a monthly retainer for what should be a one-off fix, ask which of these three you are actually buying.

One trap. Size alone does not move work into the monthly bucket. A large one-off job that cannot be scoped is still hourly. Only the absence of a finish line makes something monthly.

What actually moves your number

Roughly in order of impact.

Whether real users and real data are already in it. The biggest multiplier, and the one founders underestimate. Fixing a data model before launch is a schema change. Fixing the same model with nine months of live records means a migration, a backfill, a plan for the rows that do not fit the new rules, and a way to do all of it without downtime. Same defect, several times the work.

Whether authorisation is enforced on the server. If what a user can do is decided by which buttons the page renders, none of it is enforced. Retrofitting real permission checks touches every endpoint, and it is slow work because every decision has to be made deliberately: who is allowed to see this, and how do we prove it. This is routinely the single largest line in a cleanup.

Whether customers' data can leak into each other. Related but worse. If the only thing separating customer A from customer B is that every query happens to filter correctly, then the fix is structural and it interacts with everything above. Found before launch it is a design decision. Found after, it is a project with a deadline set by your own risk.

Whether it runs anywhere but production. A surprising number of AI-built apps have no local setup and no staging. Until someone can run the app safely away from your customers, every change is tested on them, and careful work costs more than the change itself. Building that path is usually the first thing worth paying for and it makes everything after it cheaper.

How locked into a platform it is. If the app can be exported and hosted normally, this is a non-issue. If it only exists inside a builder that owns the runtime, your options are bounded by that product, and "make it production ready" may mean "move it first", which is a different and larger job.

How many outside services it touches, and whether any hold money. Every integration is a place where errors, retries, refunds and duplicates have to be handled properly. Payments and anything with a legal obligation attached deserve their own scope line and their own testing.

Whether it has to stay up while you fix it. Working on a live product with paying customers is more expensive than working on one nobody uses yet, because every step needs a safe order, a way back, and someone watching. That is not padding, it is the cost of not breaking your own business mid-repair.

How much you plan to change afterwards. If the app is finished and just needs to be safe, tidying the code is wasted money. If you plan to build on it all year, the tidying pays for itself. This one is a business decision, not a technical one, and it changes what belongs in scope.

The cheap findings and the expensive ones

Real work splits sharply, and the split is not intuitive. Roughly:

Usually cheap, often a day or less each: rotating leaked keys and moving them server side, turning on real backups and testing a restore, adding error tracking so failures stop being invisible, fixing the missing database indexes behind the slow pages, putting basic rate limits on public endpoints, tightening file upload handling.

Usually expensive, and priced as projects: retrofitting authorisation across an app that never had it, introducing separation between customers' data after real data exists, replacing a home-made login system, changing the data model under a live product, migrating off a platform you cannot export from.

The useful consequence: the cheap list is where most of the immediate risk lives, and it is affordable this month regardless of what you decide about the rest. If your budget is small, that is where it should go first, and any provider worth hiring will tell you the same and in the same order.

How to read two quotes that are not comparable

They never are. Normalise them on these, in writing, before you compare a single figure.

1. What is fixed and what is hourly, line by line.
2. What happens when they find something new. A change process agreed up front, or a conversation you have while stressed.
3. What "done" means. A list of specific findings closed, or a feeling.
4. What is explicitly excluded. The absence of this list is the finding.
5. Who owns the code and the accounts afterwards. Yours, in your accounts, or theirs.
6. What happens to your live app during the work, and who is responsible if a fix causes an outage.
7. What you get if you stop after the first phase. Written findings you can hand to anyone, or nothing.

A quote that answers all seven can be more expensive than one that answers none and still be the cheaper purchase.

The one thing that makes every quote better

Knowing what is wrong before you buy. A provider quoting blind has to price the unknown, and you pay for that uncertainty either as padding or as revisions later.

That is why our free AI code audit exists as a fixed-scope deliverable rather than a sales call. Read access is enough, nothing in your code changes, and you get a written verdict in 48 to 72 hours on what is solid, what is fragile and what is dangerous. It is yours to keep, including if you take it to a different developer and ask them to quote against it, which is a genuinely good use of it.

Budget for this in two steps, not one. Find out what is wrong, then price the fix. Doing it the other way round is how you end up paying for somebody else's guess about your own software.