What Decides the Cost of Finishing a Half-Built AI App
Two apps that look identical in the browser can be a weekend apart or a month apart in work. The difference is rarely the features. Here is what actually moves the number.
By NinjaNext TechnologiesPublished 4 min read
Key takeaways
- What you see on screen tells you almost nothing about what the work will cost.
- The expensive problems are structural: data shape, authorisation and payments.
- Anyone quoting before reading your code is guessing, and the guess protects them, not you.
- A cheap audit first is the one reliable way to turn an unknown into a fixed number.
This is the first question everyone asks, and the honest answer is that nobody can tell you from a screenshot. Two apps that behave identically in a demo can be a weekend apart or a month apart in work, and the difference is almost never the number of features.
What follows is what we actually look for, in roughly the order it affects the price. You can assess most of it yourself before you talk to anyone.
The shape of the data
This is the single biggest factor, and the least visible. AI builders generate a database structure from the screens you asked for, which means the structure fits the screens rather than the business.
If that structure is roughly right, everything else is contained work. If it is wrong in a fundamental way, say a record that should belong to an organisation belongs to a single user, then every screen, every query and every permission rule downstream inherits the problem. That is the kind of fix that turns a week into a month, because it cannot be done in one place.
Whether anything checks who is allowed
Login almost always works. What is usually missing is the layer below it, deciding which records each signed-in person may read or change. We have written separately about row-level security and about the key that bypasses it.
Cost-wise the distinction is simple. If the rules are missing but the data knows who owns what, adding them is predictable work. If the data does not know who owns what, you are back to the first problem, and this is why the two are so often quoted together.
How far the payments actually got
Taking a card is the easy part and usually works. What tends not to exist is everything after: a declined card an hour later, a subscription that lapses, a refund, a customer who closes the tab on the success page.
Going from a checkout that looks finished to one you can take real money through is well-understood work with few surprises, which makes it one of the more predictable lines in a quote. It is rarely cheap, and it is rarely a shock.
Whether anything catches a regression
Most AI-built apps have no automated tests, which costs you twice. Once to add them, and once in the slower, more careful pace of every change made before they exist, because nobody can tell what a fix might have broken.
This is the line people are most tempted to cut, and the one that most reliably costs more later. Tests around sign-up, login and checkout are also what let you keep using your AI builder afterwards without holding your breath.
One more thing moves the number in a way founders rarely expect: how much of the app you can still explain. If you can say what each screen is for and who uses it, scoping is quick. If the product grew by prompting until nobody is sure what half of it does, somebody has to work that out before anything can be fixed, and that archaeology is billable time that produces no visible change.
Signals it will be cheaper than you fear
- The app does one thing for one kind of user, rather than several things for several roles.
- You can describe what a record is and who owns it in a single sentence.
- Money is not involved yet, or payments are one-off rather than recurring.
- Nobody has shipped yet, so there is no live data to migrate and no users to avoid disrupting.
- The code is in your own repository, with a history, rather than only inside a builder.
Signals it will cost more
- Several user types with genuinely different permissions.
- Real customers already using it, so every fix has to be done without losing their data.
- Subscriptions, especially with trials, proration or refunds already taken.
- A feature list that grew by prompting, where nobody can now say what the app is supposed to do.
- Anything regulated: health records, financial data, children's data.
How to get a real number
Be wary of anyone who quotes a fixed price for a rescue before reading the code. They are either padding heavily to cover what they cannot see, which you pay for, or they will discover the real scope later and come back to renegotiate, which costs you more and later.
The alternative is to pay a small amount to remove the uncertainty first. We offer a free first look, and a paid audit that reads the code properly and ends in a written report plus a fixed quote, with fixes starting from $500. The audit is useful even if you then go elsewhere: you own the report, and it is the thing that lets any developer quote you honestly instead of defensively.
If you want that done on your app, send it over. If you are earlier than that and still deciding what to build, tell us what you are building.