What It Costs to Finish an AI-Built App (in Time)
In time, not money, because time is the part that actually varies.
The question arrives in almost every first call. Someone has an app that works, they've read enough to suspect it isn't ready, and they want a number.
I can't give a useful number without seeing the code. What I can do is explain what drives the number, because the range is enormous and almost all of the variation comes from three things the founder already knows the answer to.
The baseline
For an app built on Lovable, Bolt, Base44 or Replit that has maybe fifteen to twenty-five screens, a database, login and a payment flow, the work of getting it genuinely ready for paying customers runs somewhere between four days and five weeks.
That's a wide spread. Here's what moves you along it.
Driver one: how long you kept prompting after it stopped working
This is the big one and it surprises people.
If you stopped when the trouble started, most of what's left is addition. Nobody has to untangle anything. A developer reads the codebase, adds database policies, closes the gaps in the payment flow, wires up error tracking and backups, and hands it back. That's the four-day end.
If you spent two months prompting the same bug, a real share of the work goes into figuring out what the code currently does and which of its behaviours were deliberate. That work produces nothing you can see. In the story I wrote about last week, the actual fix took under an hour and removing eight rounds of previous attempts took four.
I've seen apps where roughly half the effort was undoing prior fixes. Nobody budgets for that because from the outside it looks like the app is already most of the way there.
Driver two: whether money is involved
An app that doesn't take payments skips an entire category.
Payment work is slow because it's mostly about states that don't exist yet. The checkout already works. What's missing is what happens when the webhook fires twice, when someone pays and closes the tab, when a renewal fails eight months from now, when you need to issue a refund. Each one needs deciding and building, and most of it can't be verified by clicking around, so it needs testing properly.
Budget three to five days for this on top of everything else. It's rarely less. Subscriptions take longer than one-off payments because renewals and cancellations both have to work without anyone watching.
Driver three: how much real data you already have
An app with no live users can be changed freely. Get the schema wrong, change it, redeploy.
An app with four months of customer records can't. Every schema change now needs a migration, migrations need testing, and testing needs a copy of production data that isn't production. If nobody set up migrations while building, which is nearly universal in AI-built apps, that scaffolding has to be built before anything else can move.
This is the one that genuinely doubles timelines, and it's why waiting is expensive in a way that isn't obvious.
What the work itself consists of
Roughly in the order it gets done, with the time each usually takes on a mid-sized app.
Reading the codebase. Half a day to a day. Someone forms a model of how the thing actually fits together, which is the step that makes everything after it faster. It also tends to turn up two or three surprises nobody knew were there.
Database access rules. One to two days. Policies that enforce ownership at the database rather than in the browser's request, then testing with a second account that they hold.
Secrets. A few hours. Finding anything sensitive that reached the frontend, rotating it, moving the calls server-side.
Authorization. One to two days. Server-side role checks on every endpoint that matters, so hiding a link isn't what's protecting an admin page.
Payments. Three to five days if applicable.
Volume. One to three days. Seeding realistic data, finding the queries that fall over, adding indexes, fixing anything that loads everything and filters in the browser.
Rate limiting. Half a day to a day. Login, password reset, signup, anything that sends email or calls a model.
Operations. Two to four days. Error tracking, alerting, a staging environment, a rollback path, a backup someone has restored from at least once.
Untangling. Zero to two weeks, entirely dependent on driver one.
Add it up and a clean case lands around eight to ten working days. A messy one runs past a month.
What it doesn't include
Two things people assume are in scope.
It isn't a rewrite. Nearly all of this is additive. In most of the projects we take on, the code that gets kept is well over ninety percent of what the AI produced. The parts being added are the ones nobody prompted for because they're absences rather than features.
It also isn't new features. Finishing and extending are separate jobs and mixing them is how a two-week piece of work becomes a two-month one. Get the thing safe, ship it, then build.
The cheaper option nobody takes
Almost every project that ends up in the expensive range could have been in the cheap range.
The difference is when someone read the code. Not rebuilt it, read it. An afternoon of somebody competent going through the repository at the point the first strange thing happened would have turned up the cause, and the founder would have known whether to keep prompting or stop.
Instead the usual sequence is months of patching, then a call. By then the app has accumulated a layer of failed attempts that has to come off before anything else can happen, and that layer is often the single largest line item.
If you take one practical thing from this: the audit is cheap and the delay is not. Two or three hours of someone reading your codebase tells you which range you're in — that's the first step of AI app rescue, and the number only goes up from there.
A rough way to place yourself
Count the yes answers.
Did you stop prompting within a week or two of the first bug you couldn't fix?
Are you not taking payments yet, or only one-off payments?
Do you have fewer than about fifty real users' worth of data?
Can you say what your database access policies are without opening the dashboard?
Has nobody ever had to warn the AI not to touch other parts of the app?
Four or five yes answers and you're probably looking at a week to ten days.
Two or three and it's two to three weeks.
One or none and it's a month or more, and roughly half of that is undoing rather than building. That's not a reason to put it off. It's the strongest possible reason not to.
We do the reading part for free. You get a written list of what's actually in your remaining work, with the specific files behind each item, and no obligation to hire anyone for the rest of it.
Comments