The Handover Problem: Can Anyone Else Run Your AI-Built App?

12 minutes ago

5 min read

Nobody talks about what happens when an AI-built app gets given to someone else. It's the part that decides what your app is worth.

Here's a question that doesn't come up until it's urgent: if you stopped working on your app tomorrow, how long would it take someone else to pick it up?

Not rebuild it. Just understand it well enough to change one thing safely.

It matters in more situations than people expect. You hire your first developer. You bring on a technical co-founder. You go on holiday and something breaks. An investor's technical advisor asks to look at the code. You want to sell. Or, most commonly, you've hit the wall and you're hiring someone to finish the remaining fifth.

In every one of those, the same property is being tested, and it's one that never got tested while you were building: can another person form an accurate model of this system from what exists?

Why AI-built apps are unusually bad at this

Not because the code is bad. In most cases it's perfectly reasonable — conventional patterns, readable components, standard libraries.

It's that a codebase normally carries more than code. A developer building something over months leaves a trail: commit messages explaining why, comments on the parts that look wrong but aren't, a README, a structure reflecting decisions someone made on purpose.

An AI-built app has almost none of that. The commit history is fifty commits that all say the same thing, or one commit from four months ago. There's no README, or there's a generic one describing a framework rather than your app. Nothing explains why that field is nullable, why there are two functions doing nearly the same thing, or which of them is still used.

So the person picking it up has the code and nothing else. They can see what it does. They cannot see what was intended, which means they can't distinguish a deliberate decision from an accident.

That distinction is the whole job. Change something accidental, fine. Change something deliberate, and you break a thing nobody remembers exists.

What "unreadable" actually means here

Specific patterns that make handover slow, all common in AI-built apps:

Duplicate implementations. The same thing solved twice in different places, because the model didn't know the first one existed when it wrote the second. New person can't tell which is live. Changing the wrong one produces a change that appears to do nothing.

Dead code that looks alive. Features half-built, abandoned mid-prompt, never removed. Reads as intentional. Gets maintained, worked around, reasoned about — all for nothing.

Layered fixes. The eight guards from the forty-bug story. Each one an attempt at a problem, none removed. To a newcomer they read as deliberate defensive design and get preserved carefully, which makes the actual cause harder to find.

Naming that drifted. Something called user in one place, account in another, member in a third, all the same thing — because they were written weeks apart from different prompts.

Configuration outside the code. Secrets, scheduled jobs, deployment settings, database rules. All invisible to someone reading the repository, all essential to understanding it.

None of these are defects while you're the only person touching it. You carry the missing context in your head. The moment you stop being the only person, that context is the most valuable thing in the project and it's not written down anywhere.

The commercial version

This gets expensive in two specific ways.

Hiring costs more. The first two days of any engagement go to orientation. On a well-documented project that's genuinely two days. On an undocumented AI-built app it's a week, and you're paying for someone to reconstruct knowledge you already have.

Worse, you pay it again with every new person. The knowledge doesn't accumulate anywhere.

Valuation drops. This one surprises founders. If you ever raise, sell, or bring in a technical partner, someone competent looks at the code. What they're assessing isn't elegance — it's how dependent the asset is on you personally.

An app nobody but you can safely modify isn't really an asset. It's a job you've created for yourself. Technical due diligence exists precisely to find that out, and "the founder built it with AI and it works but nobody else understands it" is a finding, not a footnote.

The fix is smaller than it sounds

This is not a documentation project. Nobody's asking for a wiki.

A real README. One page. What the app does, who uses it, what the main flows are, what the key tables hold, what's deliberately unfinished. An hour, and it's the single highest-return hour available to you.

A configuration inventory. Every setting that lives outside the repository — secrets, scheduled jobs, deployment config, database rules, third-party accounts — listed with where it is. Ten minutes a month. Doubles as your disaster plan.

Delete the dead code. Half a day. If you're not sure something's used, that uncertainty is exactly the cost being described here. Find out and remove it.

Write down the decisions you remember. The five or six things a newcomer would get wrong. That field is nullable because of this. Those two functions exist because of that. Don't touch the login flow without reading this first. A plain text file is fine.

Commit with messages that mean something, from now on. Not retroactively.

Under two days total. It's the difference between a week of onboarding and two days, every time — and it's the cheapest work on any list I've written in this series.

Worth doing even if nobody's coming

The argument that lands with founders who have no plans to hire: you are the future stranger.

Six months from now you'll open a part of this app you haven't touched since spring, and you will not remember why it's built that way. Everyone discovers this. And practically, the handover work is the same work as the audit work. Someone reading the codebase to produce that README finds the open database policies, the dead code, the duplicate implementations — which is why every AI app rescue engagement starts with exactly this read.

And practically, the handover work is the same work as the audit work. Someone reading the codebase to produce that README finds the open database policies, the dead code, the duplicate implementations. You get the documentation and the findings from the same pass.

Which is the argument for doing it now rather than at the moment you urgently need someone else in the code — because that moment always arrives sooner than planned, and it's never a convenient week.