The worst MVP I ever autopsied took eleven months to build and died in nine days. It had multi-tenancy, role-based permissions, a settings page with fourteen toggles, and exactly zero users who had asked for any of it. The founder showed me the codebase the way you'd show someone a very expensive car that doesn't start. It was a museum of MVP mistakes.
Here's the uncomfortable part: nothing about that story is unusual. Forward deployed engineers get called into these wrecks constantly, and the same handful of mistakes show up so reliably you could print them on a checklist. So here's the checklist. These are the MVP mistakes to avoid if you'd like your first version to survive contact with reality.
The MVP mistakes that kill products are almost never technical — they're scope sins and imaginary-user sins committed before the first line of code earns its keep. Build for one real user's actual workflow, cut until it hurts, and defer everything enterprise-shaped until someone is paying. The nine mistakes below cover roughly 90% of the wreckage.
The Graveyard of Great Ideas
MVPs rarely die from bad engineering. They die from good engineering applied to the wrong thing, at impressive length. The pattern is consistent enough that experienced builders can usually predict the failure mode within the first meeting, which is a depressing party trick.
The encouraging news is that every mistake on this list has a known antidote, and most of the antidotes cost nothing except ego. We'll walk the graveyard in order of how often each sin shows up.
One disclaimer before the tour: none of these mistakes mean the team was stupid. Every one of them is what smart, motivated people do when they're anxious about shipping something imperfect. That's exactly what makes them dangerous. They feel like diligence.
MVP Mistakes One to Three: The Imaginary-User Trilogy
First, the big one. Mistake one: building for users who don't exist. "Our market is mid-size logistics firms." Great. Name three. If you can't, you're building for a demographic, and demographics don't log in. The fix is embarrassingly simple: pick one specific company with one specific person who feels the pain weekly, and build for them.
Closely related: mistake two, asking users what they want. Users are lovely people who will confidently describe features they will never use. What they do beats what they say, every time. Watch someone do the task with their current awful workaround: the spreadsheet, the group chat, the sticky notes. Then build the thing that makes that specific ritual disappear. Teams working close to the client get this for free; it's the entire premise behind short onsite feedback loops.
Third sin: the investor demo disguised as an MVP. If the success criterion is "looks great in a pitch deck," you'll build a beautiful facade with no building behind it. Investors fund traction, not toggles. A scrappy tool that one real user refuses to give back beats a polished demo every single time.
Mistakes Four to Six: Scope Sins
On to scope. Mistake four: "just one more field." Scope creep never announces itself as scope creep. It arrives as reasonable requests, each adding a day, until your two-week prototype has a five-month roadmap. The discipline is a written scope line: anything not on it waits for version two, no matter how reasonable it sounds in the meeting.
Number five, my personal nemesis: premature multi-tenancy. You do not need tenant isolation, an org hierarchy, and per-client branding for your first user. You need the thing to work for the first user. Multi-tenancy added later is a refactor; multi-tenancy built first is a mortgage on a house nobody lives in. I once watched a team spend six weeks on white-label theming for a product whose only customer used the default colors. Six weeks. The customer churned anyway, over a missing CSV export.
Mistake six: admin panels before users. I've seen teams build elaborate admin consoles for products with zero humans to administer. If the founder can fix it in the database in two minutes, you don't need a UI for it yet. There's a whole playbook on cutting MVP scope without cutting the value, and rule one is that admin tooling is never the value.
Mistakes Seven to Nine: Technical Theater
Now for the technical theater. Mistake seven: microservices for three users. You are not Netflix. Three users will not notice your monolith, and your future self will not enjoy debugging distributed anything before you've found product-market fit. One deployable unit, one database, ship it.
Mistake eight: the CI/CD cathedral. Automated tests and deployment pipelines are wonderful, for software people depend on. For a prototype that might pivot Thursday, a manual deploy and a prayer is a rational choice. The rule of thumb I give founders: earn the right to infrastructure. When breaking things starts costing someone real money or real sleep, that's the week you harden the pipeline, and not a sprint earlier.
And finally, mistake nine: choosing the stack for the resume. The hottest framework is rarely the fastest path to a working prototype. Boring, well-documented tools you already know will beat exciting tools you don't, and nobody's business ever failed because the MVP used the uncool database. If you're genuinely unsure where the line sits, the rapid prototyping playbook lays out a stack that optimizes for weeks, not fashion.
The Fix: Cut Until It Hurts, Then Cut Again
Notice the pattern across all nine: every mistake is an attempt to skip the scary part, which is showing an imperfect thing to a real person. Scope is a hiding place. Architecture is a hiding place. Settings pages are a hiding place with fourteen toggles.
The FDE scoping move is aggressive to the point of rudeness: one user, one workflow, one week. When that's impossible, shrink the workflow, not the timeline. And when the workflow genuinely can't be built yet, fake it honestly — the Wizard of Oz prototype, where a human quietly powers the "automation" behind the curtain, has validated more real products than most codebases.
That eleven-month MVP didn't fail because the team couldn't build. It failed because nobody was forced to answer, in week two, the only question that matters: who used this today, and did they come back tomorrow?