Your Failed MVP Is Probably an Undocumented Asset
The Conversation I've Had Too Many Times This Year
A founder gets in touch. Smart, non-technical, a year and a real budget into their idea. There's a build. An agency delivered it, or a freelancer, or a technical co-founder who has since moved on. It half-works. Nobody currently on the team can explain what's inside it.
And every developer who has glanced at it since has offered the same verdict: probably faster to start over.
I've heard that sentence enough times to script the whole exchange. What bothers me isn't the advice. It's that the advice is almost never based on evidence.
"Rebuild It" Is a Guess Wearing a Verdict's Clothes
Reading someone else's undocumented code is miserable work. It's slow, it's thankless, and it makes a developer look bad for weeks before it makes them look good. Rebuilding, by contrast, feels clean. Green field, own decisions, no archaeology.
So the recommendation tilts toward rebuild — not because the existing code is worthless, but because nobody wants to be the person who has to read it.
The founder can't push back, because they have no independent picture of what they actually own. They're being asked to approve a second full build on the strength of a professional impression they aren't equipped to interrogate. You cannot decide whether to salvage or rebuild until someone tells you, in plain English, what's already there.
That's the gap. Not a technical gap — an information gap. And it's expensive, because the default answer to "we don't know what's in it" is "pay for all of it again."
Running the Flow Backwards
Codalio has always taken founders one direction: idea → PRD → working build. Define the product precisely, then let the spec drive the code. That's our whole argument — vibe coding gets you a prototype, spec-driven work gets you a product.
In July we shipped the feature I'm most excited about, and it runs that flow in reverse. Reverse Engineering the Broken Code starts at the other end: point Codalio at an existing codebase — messy, inherited, abandoned, doesn't matter — and it works backwards to a readable PRD.
Not a dependency graph. Not a file tree. A plain-English specification of the product that was actually built, which is a different document from the one you thought you were paying for. It tells you:
-
What's complete and working as intended
-
What's half-done — started, then stalled mid-feature
-
What was quietly skipped and never mentioned
-
What the code assumes about your business logic, including the assumptions nobody wrote down
-
Where the real gap sits between the product in your head and the product on the server
With that in hand, "salvage or rebuild" stops being a gut call and becomes a decision you can defend — before you spend another dollar. Most of the failed MVPs we've looked at aren't failures at all. They're undocumented assets. The value was there the whole time; nobody could read it.
Studio, also new this month, is the workspace where that whole journey now lives in one place — idea, PRD, build, and reverse-engineered specs — instead of scattered across five tools and a Google Doc nobody has opened since March.
What This Looks Like When the Spec Comes First
The clearest proof we have of the spec-first argument came from Eduai Motors, who build transportation automation for mining — autonomous rail carts deciding which of five mine sites to haul to and where to dump material. Industrial, safety-critical software with real consequences for getting it wrong.
When the project was scoped, the industry-standard estimate was six to seven months. Working with Codalio, it was delivered in two.
I keep returning to that gap, because the explanation is boring in the best way. Nobody worked four times harder. Almost nothing had to be built twice. When the specification is correct before the first line of code, the rework that silently consumes most software budgets simply doesn't occur. That's the entire mechanism.
So here's the practical version, for the founder sitting on a build they don't trust:
Before you approve a rebuild, get the spec of what exists. Ask for it in writing, in language you can read without a developer translating. Then compare it against what you actually need — not against your original wish list, against the product you're trying to sell next quarter. Quantify the delta. That number, not a developer's first impression, is what a rebuild decision should rest on.
If you want to see what the forward version of this feels like, we published our first product demo in July: Prompt to PRD, a start-to-finish walkthrough of turning a raw idea into a development-ready spec. It's the fastest way to understand how we work. And at the end of the month we filmed our first full client-story interview with a director at L-SPARK — one of Canada's best-known SaaS accelerators, and a Codalio client. That one's still in the edit bay. It'll land here first.
Start With the Spec, Not the Rebuild
If you're mid-way through the "should I just start over?" spiral, Codalio can hand you the missing document — a readable spec of the software you already paid for, so the next decision is an informed one instead of an expensive shrug.
If you know a founder about to approve a second build they can't evaluate, forward this to them. It may save them a very costly guess.
References
- Codalio product demo: Prompt to PRD walkthrough (youtu.be/8w5unvzDtPw)