AI Built 80% of My App. Who Builds the Other 20%?

2 hours ago

5 min read

The remaining fifth isn't the leftovers. It's a different kind of work, and knowing what's in it tells you who you actually need.

The 80% figure comes up constantly, and it's roughly right. People describe an app, and within a few weeks they have something that looks and behaves like a real product. Screens, flows, login, a database, a payment form. Four-fifths of the visible product, built by someone who has never written code.

Then it stalls. Not dramatically — there's no wall. It just stops converging. The last fifth takes longer than the first four-fifths did, and nobody can explain why, because from the outside it looks like less work.

The reason is that the remaining 20% isn't more of the same. It's a different category of work entirely, and the reason AI got you the 80% so cheaply is precisely the reason it struggles with what's left.

The 80% is everything you can see

Look at what actually got built. Interface. Navigation. Forms. Database tables. The happy path through every flow. A checkout that completes.

These share a property: you can verify them by looking. You describe it, it appears, you click it, you know whether it worked. That's a tight feedback loop, and AI is extraordinarily good inside tight feedback loops.

The 20% shares the opposite property. Almost none of it is visible from the front end, and almost none of it can be verified by clicking around as yourself. That's why it didn't get built — not because the model couldn't write it, but because nothing in the process asked for it, and nothing in the process would have told you it was missing.

What's actually in the 20%

It breaks into four parts, and they're unequal.

About half of it is the unhappy paths. Your checkout works. What happens when the payment provider retries the webhook and it arrives twice? When the user pays and closes the tab before your app records it? When a renewal fails six months from now? When someone asks for a refund?

Each of these is a state your app needs to know about and currently doesn't. The feature exists; the state machine around it doesn't. Same story across uploads, signups, background jobs, anything that can fail partway.

Maybe a quarter is adversarial thinking. Your app shows each user their own data. The question is whether that's enforced by the database or just reflected by the screens. Whether the admin page rejects a direct URL. Whether a secret key ended up in the browser bundle. Whether anyone can hit your endpoints with a script instead of your interface.

This work is invisible by definition — it's the absence of a way in. You can't see it, and you can't prompt for it, because you'd have to already know what to ask.

Another chunk is what happens at real volume. Built against forty test records, apps get built as though forty is normal. Screens that load everything and filter in the browser, queries with no index, one database call per item in a loop. Fine now, painful at four thousand rows, and it degrades so gradually that nobody connects the dashboard being slow to a decision made months earlier.

And the rest is operations. Error tracking so failures are visible. Alerting so you learn about downtime before a customer tells you. Logs with enough context to reconstruct a bug. A staging environment. A rollback path. A backup you've actually restored from once.

This is the part most often missing entirely, and the part that decides whether a bad day costs you eleven minutes or a day and a half.

Why it's the expensive fifth

Three reasons it costs more than its size suggests.

You can't evaluate it. The prompting loop works because you can judge the output. Once correctness depends on conditions you can't produce on demand — a retry, two users writing at once, a malicious request — you've lost the ability to tell whether the answer was right. You're not directing anymore; you're accepting.

It requires holding the whole system at once. The unhappy paths cross features. A change to checkout touches onboarding, the admin screen and a webhook. AI builders work inside a context window, not a held model of your application, which is why fixes come out local and blind to each other — and why the same bug comes back three times.

Most of it has no visible output. You can spend two weeks on it and the app looks identical. That's psychologically brutal for a founder, which is a real reason it gets deferred past the point where deferring is cheap.

So who does it

The honest answer is: someone who can evaluate code they didn't write, and who has seen these failures before.

That's not necessarily a senior engineer on payroll, and it's usually not a full-time hire. The work is bounded — for a typical AI-built app it's days to a few weeks, not months — and once it's done, it mostly stays done. Hiring a permanent engineer for a fortnight of work is the wrong shape of solution.

It's also not a rewrite. This is the misconception that costs people the most. Almost everything in that 20% is additive — policies, checks, missing states, monitoring, backups. In the projects we take on, the existing build is kept nearly in full. What changes is the parts underneath it that the prompting loop had no reason to produce.

What you need is someone who will read the whole codebase, form a model of it, and close those four categories in order of consequence. That's the shape of AI app rescue: data boundaries first, money second, volume third, operations fourth.

The timing, which matters more than the choice

The same 20% costs three different amounts depending on when you do it.

Do it when you first notice — the same bug returning, a part of the app you've started avoiding, real users about to arrive — and it's mostly addition. Small app, few tangles, localized fixes.

Do it after months of patch-on-patch and a real share of the effort goes to working out what the code currently does and which behaviors are deliberate versus accidental. That archaeology produces nothing visible. It's pure cost, and it scales with how long you kept going.

Do it after an incident and you've added the costs that aren't development costs at all: the refunds, the disclosure, the customers who don't come back.

Same work, three prices, one variable.

The part worth keeping

The 80/20 framing is right but the weighting is misleading. The last fifth isn't the finishing touches. It's the part that determines whether the first four-fifths survives contact with strangers.

That's not an argument against building this way. Getting to a working product in weeks, without a dev team, for the price of a subscription, is a genuine change in what's possible and most of the projects we see should absolutely have started that way.

It just means the finish line is further than it looks, and it's in a different direction than the one you've been running. The good news is that it's a short distance — and unlike the first 80%, you only have to cross it once.