The most-quoted sentence in startup product advice belongs to Reid Hoffman: if you're not embarrassed by the first version of your product, you launched too late. Founders recite it like scripture in every accelerator demo day. It's a decent line about perfectionism, and the industry has spent the better part of fifteen years misreading it as a permit to ship garbage against a calendar date. Embarrassment is the easy part. Anyone can ship something embarrassing. The hard part of an MVP launch is the word everyone sprints past on the way to the launch party — viable.
The lazy consensus: minimum, fast, embarrassing, iterate
Here is the gospel as it's actually practiced. An MVP is the cheapest, ugliest thing you can throw in front of users. Speed is the only virtue. You launch in six weeks, you're embarrassed, the market tells you what to fix, and you iterate your way to product-market fit. The build quality doesn't matter because you'll rewrite it anyway. The whole thing is framed as a race, and the team that ships first wins.
Almost every clause in that paragraph is wrong, or wrong enough to kill the company. The framing has the bottleneck in the wrong place, it treats a disposable prototype and a production system as the same artifact, and it quietly assumes the hard question is 'how fast' when the hard question is 'which thing.' Founders optimize the one variable that was never the constraint.
Speed was never the bottleneck
The post-mortems are unkind to the speed obsession. CB Insights has, for years, kept a running tally of why startups die, and 'no market need' sits at or near the top — on the order of a third of failures. Read that again: the single largest cause of death is building something nobody wanted. Not building it too slowly. Not building it too well. Building the wrong thing, efficiently. Shipping that wrong thing two weeks faster would have changed nothing except the burn rate on the way to the grave.
So when a founder tells me the priority is to launch fast, I hear someone optimizing for a metric that doesn't appear in the cause-of-death column. Velocity feels like progress because it's measurable and it produces a date you can put in a deck. Whether the date attaches to a viable product is a separate, harder question that the speed framing lets you avoid.
The 'V' is load-bearing
Viable doesn't mean feature-complete and it doesn't mean polished. It means there is one workflow — usually exactly one — that a real user can complete, start to finish, and get a real result they'd pay for or come back for. For a claims tool, that's: enter your case, get an answer, get paid. For a marketplace, it's: a buyer finds a thing, pays, and a seller gets the money. That spine has to work flawlessly. Everything hanging off it can be ugly, manual, or absent.
This is where the 'minimum' fetish does its damage. Teams read 'minimum viable' as 'minimum,' with 'viable' as decoration, and they spread their thin effort evenly across twelve half-built features so the demo looks broad. The result is a product that does twelve things badly and zero things well — minimum without viable. The correct move is the opposite: do one thing completely and let the screenshot look narrow. A narrow product that works beats a broad one that doesn't, every single time a user actually tries to do the thing.
The real work is deciding what NOT to build
In eleven years of building software at EltexSoft, the most valuable week of an MVP engagement is almost never a week of coding. It's the week of subtraction. We took on a stalled product — Meal4U — where a previous team had failed to deliver, and the rescue didn't start with a line of code. It started with deconstructing the scope and re-estimating the build roughly ten times in a row, cutting thirty to fifty percent each pass, until what was left was the smallest thing that could actually ship and stand on its own. That is the job. Not 'how do we build this faster,' but 'what is the irreducible product underneath the wish list.'
Cutting is unglamorous and politically expensive — every feature you remove belonged to someone who was sure it was essential. Which is precisely why the speed narrative is so popular: it lets everyone skip the argument. 'We'll add it in v2' is easier to say than 'that was never part of the viable core and here's why.' But the subtraction is the work. A team that won't do it doesn't have a lean MVP. It has a bloated product with an early deadline, which is the worst of both.
"It's just an MVP, we'll rewrite it" is the lie that pays our rescue invoices
The most expensive sentence in this whole genre is 'the code doesn't matter, it's only an MVP.' Here's the part nobody warns you about: if the MVP works, you don't rewrite it. You bolt the next feature onto it, and the one after that, because there's revenue now and a roadmap and no calm quarter to stop and rebuild. The disposable prototype quietly becomes the production system that the entire business runs on, and the shortcuts you took to hit the launch date are now load-bearing.
We know this because picking up that exact mess is a recurring engagement. With Nautical Commerce we inherited a roughly one-year-old codebase and had to deliver a marketplace-as-a-service against a ninety-day go-live — you don't get the clean-slate luxury the 'we'll rewrite it' story promised; you build forward on what exists, under a clock, and the platform we delivered went on to handle 200,000-plus transactions a month. The lesson is the same one the disposable-MVP crowd refuses to absorb: there is rarely a rewrite. The first version is usually the foundation, so the foundation has to be sound even when the building is small. That's also why we keep a non-negotiable rule that survives even a launch crunch — every pull request is reviewed by at least one other senior engineer before it merges. Speed is not an excuse to skip the thing that keeps the foundation honest.
The other failure mode: the MVP that's actually everything
If under-viable is one ditch, over-built is the other, and plenty of founders drive straight into it. They call it an MVP, but the spec describes the full vision — every persona, every edge case, every integration — and the 'minimum' launch is eighteen months out. This isn't discipline either; it's the same failure wearing a longer timeline. You're still spreading effort across things you haven't validated, just slowly and at greater cost.
Sometimes the right move genuinely is to expand the spec, but only because the viable core demanded it. With HeyTutor we took a founders' one-page concept and pushed it to a roughly forty-page specification before building a marketplace that became one of the larger US education-tech platforms — and the expansion was the point: a two-sided tutoring marketplace has real complexity in matching, scheduling and payments that a one-pager hand-waves away. Detailing it was scoping the viable core, not gold-plating. The discipline isn't 'always smaller.' It's 'exactly as large as viable requires, and not one feature larger.' Knowing the difference is the entire skill.
What a serious MVP launch actually looks like
Strip the theater and an MVP launch is three honest decisions. First, name the single workflow that has to work and define 'works' concretely enough that you'd bet money on it. Second, build that spine properly — not polished, but sound — because it's probably the foundation you'll live on, not a sketch you'll bin. Third, cut everything that isn't the spine, and keep cutting until the people who love the product are slightly nervous about how little is in it. The launch date is an output of those decisions, not the input that overrides them.
We don't call ourselves an MVP factory, and the distinction matters here: a factory optimizes for shipping the most artifacts fastest, which is exactly the speed trap that kills products. The built-from-scratch V1s that actually went the distance — a passenger-claims platform that has since processed over a million claims, a deals app that reached around two million installs and a number-two ranking in its App Store category — weren't the fastest things anyone could have shipped. They were the smallest things worth shipping, built well enough to become the thing they grew into.
The position, stated plainly
An MVP launch is not a speed contest and it is not a permit to ship something broken on a deadline. It is a scope decision under pressure: find the one thing that makes the product viable, build that part like it's permanent because it usually is, and have the spine to cut everything else. Founders who obsess over launching fast are tuning the one knob that was never the constraint, and many of them will ship a forgettable product on time and wonder why 'iterate' never saved it. The ones who win treat 'minimum' as a discipline and 'viable' as the whole point. Be embarrassed by the polish if you must. Never be embarrassed by whether the thing actually works.
Last updated June 28, 2026