It arrives in our inbox most weeks now, and the wording barely changes. Someone has built an application with AI - a few weekends of prompting, maybe a month of evenings - and it works. They can click through it. They have shown it to a co-founder, or a customer, or an investor, and the reaction was good. Now they would like a development agency to just fix a few things before it goes live.

It is a completely reasonable request, and it deserves a straight answer rather than a sales pitch. The honest answer is that sometimes it is genuinely a few things, and we will tell you so. More often, the phrase "a few things" is describing the half of the work that has not been done yet - and it is now the more expensive half. This article explains why, gives you the diagnostic we use, and shows you how to run most of it yourself before you call anybody.

What "just a few things" usually turns out to mean

When we open one of these codebases, the list the founder brought us is usually accurate. The login screen does glitch on Android. The payment flow does need finishing. The images are slow. Those are real items and they are fixable.

The problem is that the list was written from the outside, by clicking around. It is a list of what a user can see. What it cannot contain is everything that is invisible until conditions change - until there are a thousand users instead of three, until someone enters an apostrophe in a name field, until a payment fails halfway, until a phone loses signal mid-upload, or until the person who prompted the application into existence needs to explain why a particular decision was made and cannot.

So the gap is not between the founder's list and reality. The gap is between what is visible from the front end and what is true about the system underneath. Closing that gap is the actual job, and it is the reason two projects that both look "nearly finished" can be four weeks and four months apart.

Why you are being told this now, and not five years ago

Because the shape of software work changed, and it changed recently. Writing a first draft of code used to absorb most of a project's effort. It no longer does. What did not get cheaper is deciding what should be built and proving that what was built holds up. Those two jobs - problem framing and validation - are now a larger share of the work than they have ever been.

We have written about that shift in detail on our AI software engineering page, including the part most people find counter-intuitive: AI made software faster and better without making it cheaper, because the effort moved rather than disappeared. This article is what that shift looks like when it lands on your desk as a half-finished application.

The practical consequence is uncomfortable. An AI-built application is typically strong in exactly the area that got cheap, and thin in exactly the two areas that did not. It has plenty of code. What it usually lacks is a considered scalable architecture, and any evidence that the code does what it appears to do.

The five things that break after the demo works

Across the platforms we have taken over, the failures cluster. None of these are visible in a working demo, which is precisely why they survive to launch.

1. Architecture that is fine at 100 users and broken at 100,000

AI defaults to the most common pattern in its training data, and the most common pattern is a small application. That usually means queries that read more rows than they need, no caching layer, images served at full size, and work done inside the request that should be handed to a queue. At demo scale none of this is detectable. At real scale it is the whole problem, and it is not a bug you can fix - it is a shape you have to change. This is where load testing earns its keep, because it converts an argument about opinions into a number.

2. Authentication, permissions and data handling that are subtly wrong

The most common serious defect we find is not a missing feature. It is an application where authentication works but authorisation does not - where a logged-in user can reach another user's record by changing a number in a URL. AI produces the login screen readily, because login screens are everywhere in its training data. It is far less reliable at the unglamorous question of which user may see which row. Related items in the same family: data stored without encryption that should not be, secrets committed into the code repository, and no audit trail of who changed what.

3. Edge cases that were never tested, because nothing was tested

Almost every AI-built application we see arrives with no meaningful automated testing. That matters more than it used to. When code was expensive to write, it was written slowly and read carefully. When code is cheap to generate, volume goes up and human attention per line goes down, so the only thing standing between a defect and your users is verification. Without tests there is also no regression testing, which means every fix carries a real chance of breaking something that previously worked - and that is why "just fix these five things" can take longer than expected.

4. Money, personal information, and the obligations attached to them

If your application takes payments or holds personal information, obligations apply to your business regardless of who or what wrote the code. The Privacy Act 1988 and the Australian Privacy Principles do not have an exemption for applications built by a model. Payment handling has its own requirements. These are not things to discover after launch, and they frequently require changes to the data model rather than to a screen - which is another way of saying they are cheap now and expensive later.

5. Everything between "it works on my phone" and "it is in the store"

The last stretch is consistently underestimated. Store submission has its own rules about account deletion, permissions, privacy disclosures and metadata. Beyond that sits the operational layer that a demo never needs: a CI/CD pipeline so releases are repeatable, monitoring and logging so you find out about failures before your users tell you, and a way to roll back when something goes wrong at 11pm.

Why debugging is now the expensive half

Here is the part that surprises people. Asking an agency to "debug it and finish it off" sounds like the cheap option compared with building from scratch. Often it is the opposite, and for a specific reason: understanding an unfamiliar system costs more than writing a familiar one.

When we inherit a platform built by another agency, there is usually a trail. There are commit messages, a previous developer who can be asked a question, some tests, and decisions that were made by someone who could explain them. An AI-built codebase frequently has none of that. There is no author to hand over, no record of why one approach was chosen over another, and no test suite describing intended behaviour. The person who commissioned it can tell us what it should do, which is valuable, but not why it does what it does.

So the first phase is archaeology, not repair. We read the system, establish what it actually does, and separate deliberate decisions from accidental ones. Only then can anybody give you a credible answer about scope. Any provider who quotes a fixed price to "finish" a codebase they have not read is either padding heavily or about to be wrong.

How to tell in an hour whether it is a fix or a rebuild

You can run most of this diagnostic yourself, today, without paying anyone. Work through it honestly and the answer usually declares itself.

Is it in version control, with a history? If the code exists only in a chat window or a single folder, that is the first thing to fix regardless of the path you take.
Can you list every place data is stored? If you cannot describe your own data model in plain language, nobody can safely change it yet.
Are there any tests at all? Not good tests. Any tests. This single answer moves the estimate more than any other.
Try to break your own permissions. Create two accounts. Log in as the first. Change an identifier in the URL to the second user's. If you can see their data, stop reading and treat this as urgent.
Put 50 realistic records in and use it. Not three. Most performance problems appear somewhere between 10 and 100 rows and are invisible below that.
Turn off your network mid-action. Submit a form, then kill the connection. Does the application recover, or does it corrupt the record?
Ask what happens on a failed payment. If the answer is not written down anywhere, the flow is not finished.
Count the third-party services you cannot leave. If the application lives inside a builder platform, moving off it later is a rebuild by another name.

Two or three uncomfortable answers usually means a stabilise-then-extend project. Uncomfortable answers on the data model and permissions together usually means the foundation needs replacing, whatever the front end looks like. We formalise this as a platform assessment, and the longer framework for deciding between the two paths is in our article on when to stabilise an app versus when to rebuild it.

The three honest paths, and what each one is for

Fix and launch. Right when the diagnostic comes back mostly clean: the data model is sound, permissions hold, and the list really is a list of defects. This is the outcome we are happy to confirm, and we do confirm it. It is the cheapest and fastest path and it is a real outcome, not a courtesy.

Stabilise, then extend. Right when the foundation is workable but the operational layer is missing - no tests, no pipeline, no monitoring, some refactoring needed in the parts that will carry load. The work is unglamorous and it is what makes everything afterwards cheaper. Across the 15+ platforms we have rescued in the past 3 years, app ratings recovered from 3.8 to 4.6 stars, crash rates were typically cut 50 to 70 percent within 2 weeks, and feature development ran 60 to 80 percent faster after modernisation. On Train With Cass that meant taking the crash rate down 90 percent and reaching 99 percent uptime while cutting maintenance costs by half, through a handover from the previous developer. On Move With Us, addressing accumulated technical debt cut crash rates 50 percent and improved performance 40 percent with zero business interruption.

Rebuild the core, keep the learning. Right when the data model or the permission model has to change, which is the point at which patching costs more than replacing. This sounds like the worst outcome and frequently is not, because the prototype has already done the expensive part: it told you what the product should be. That is not wasted - it is the specification. Train With Cass is a rebuild we did after having already stabilised the original, and it went ahead because the platform needed to carry a bigger business than it was built for.

When the answer is "keep going, you do not need us yet"

We say this more often than people expect, and it is worth stating plainly because it is the part that makes the rest credible.

If you are still testing whether anyone wants the thing, keep building it yourself with AI. A working prototype in front of real users is worth more than a well-architected application nobody has asked for, and paying an agency to harden something you may abandon is a bad use of your money. The same applies to internal tools with a handful of trusted users, to anything where the worst outcome of a failure is mild embarrassment, and to demos built specifically to raise money before the product is real.

The line worth watching is not technical. It is the first moment a stranger can lose something - their money, their data, or their trust - because your software did the wrong thing. Before that line, speed is the priority. After it, correctness is, and the two require different work.

What to do before you call anyone

Four things, in this order. They cost nothing, they make any conversation cheaper, and they are useful even if you never hire anybody.

First, get the code into version control with a real history, and make sure you hold the account. Second, write down in plain language what the application must do and what it must never do - the second list is the one people skip and it is where the serious defects hide. Third, run the eight checks above and write the answers down honestly. Fourth, decide what your launch is actually for. A product that has to hold a paying customer base is a different engineering problem from one that has to survive a demo day, and pretending otherwise is how budgets get set wrong.

When you do want an outside read, ours is a Tech Audit at $5,000 per platform: we read the system, tell you which of the three paths you are on, and give you the reasoning rather than a verdict. Independent penetration testing and formal compliance audit work is performed by a third party, deliberately - it is not good practice for the same team to audit its own work, and an independent assessor produces a result that stands up to scrutiny.

The short version

AI has made it genuinely possible for a non-engineer to build something that works, and that is a real change worth celebrating. What it has not done is remove the work that turns something that works into something that keeps working for strangers who are paying you. That work moved; it did not vanish.

So when you ask whether we can just fix a few things, the answer is that we will read it and tell you the truth - including "yes, this is a small job", and including "keep going on your own for now". What we will not do is quote a number for finishing a system nobody has read. The platform we built for SWEAT passed Big 4 due diligence at a $400 million acquisition on the same core architecture it launched on. That is the standard the question is really about, and it is decided long before launch day.

If you have built something with AI and you want an honest read on where it stands, start a conversation. You will get one recommendation and the reasoning behind it, even when the recommendation is not us.