Taking Over an AI-Built Codebase: Our Assessment Checklist

A new and legitimate starting point

Two years ago, a non-developer founder arrived with a pitch deck. Today they increasingly arrive with a running app: built with AI assistance, functional enough to demo, sometimes already in users' hands. This is a genuinely new category of starting point, and the worst way to treat it is with engineering condescension. The founder did something valuable — they validated an idea and encoded months of product thinking into working software.

They also, almost always, built something that can't grow. The pattern is consistent enough that we now run the same assessment every time, looking for four specific problems — the same four we found when Invoice Guru came to us as an AI-built Flutter app.

The four things we check first

AI-assisted codebases fail in characteristic ways, because an AI assistant optimizes for making the current request work — not for the shape of the whole system:

• —Architecture: is there any separation between UI, business logic, and data — or does every screen do everything? Tangled layers mean no change is ever local.
• —State management: is state handled through one deliberate mechanism, or ad-hoc in every screen? Ad-hoc state is where the unreproducible bugs live.
• —Data layer: how safe is user data? Fragile local storage with no migration path is a time bomb in any app users trust with real information.
• —Duplication: how many times is the same problem solved differently? An assistant with no memory of the whole codebase happily reinvents what already exists.

Keep the product, replace the foundations

The tempting engineering answer is a clean rewrite. We rarely recommend it. The prototype's code may be disposable, but the prototype itself is not: it encodes validated flows, screens users already understand, and edge cases the founder discovered the hard way. Throwing all of that away means paying for the same lessons twice.

Our default is the partial rewrite: preserve the product behaviour, rebuild what's underneath. Tests come first — pinning down the behaviour that must not change — then the foundations are replaced layer by layer while the product keeps moving. On Invoice Guru this meant a layered architecture, Riverpod for state, a reliable local data layer, and automated tests, under an app whose users never saw the surgery.

What founders should take from this

Building your first version with AI is not a mistake — it may be the cheapest product validation ever available. The mistake is expecting that version to carry you to scale, or waiting until the codebase is fully stuck before bringing in engineering. The earlier an assessment happens, the more of the AI-built work survives.

And if you're a founder currently in the slowing-down phase — where every feature takes longer than the last and every fix breaks something else — that's not a sign you failed. It's the 60% mark. The remaining 40% is a known, solvable engineering problem.