weli argues that Eric Ries's original MVP framing as a learning tool — build the smallest thing to test a hypothesis, then discard it — has been quietly replaced by treating the MVP as the first commercial release. The M now stands for 'marketable' and the V for 'venture-fundable,' meaning products get pricing pages and ad campaigns before they're actually complete.
weli catalogs concrete failures engineers actually ship — SaaS dashboards that break the back button, mobile apps with no offline state, AI products that surface raw JSON as error messages, forms that lose data on validation failure. All are sprint-sized fixes that never get done because the roadmap moves on, and the industry has built a vocabulary (MVP, beta, early access, v0.9, 'we're iterating') to hide that fact from itself and its customers.
weli contends the essay resonates now because LLM-assisted development has made it trivially cheap to produce the first 60% of any product, saturating the market with launches that never reach completion. Shipping a half-built product used to require a team and runway; now it requires a weekend and a prompt, which is why HN pushed the piece past 900 points.
weli.dev's essay 'Half-Baked Product' hit 941 points on Hacker News, the kind of number a post only reaches when the comment section stops arguing about the piece and starts arguing about the reader's own last three jobs. The essay's thesis is compact: the industry's default definition of "shipped" has drifted so far that most launched products would have been called *unfinished prototypes* fifteen years ago, and we've built a vocabulary — MVP, beta, early access, v0.9, "we're iterating" — to hide that fact from ourselves and from customers.
The author's core observation, and the one the HN thread latched onto, is that the MVP concept has been quietly inverted. Eric Ries's original framing was a *learning tool*: build the smallest thing that tests a specific hypothesis, then throw most of it away. In practice, the MVP became the *first commercial release* — the thing you charge for, put a pricing page on, run ads against, and then never actually complete. The M in MVP now stands for "marketable," not "minimum," and the V no longer means "viable" — it means "venture-fundable."
The essay's examples aren't the usual straw men. It picks on things engineers actually ship: SaaS dashboards that don't support browser back-button navigation, mobile apps with no offline state whatsoever, AI products where the error message for a rate-limited call is literally the raw JSON, forms that lose data on validation failure, keyboard shortcuts that only work in the demo path. Nothing exotic. All fixable in a sprint. All still broken in production a year later because the roadmap moved on before anyone circled back.
The piece resonates now — and it's why HN pushed it past 900 — because the AI wave has industrialized the pattern. Shipping a half-built product used to require a small team, some conviction, and a runway. LLM tooling collapsed the cost of the *first* 60% of any product to roughly zero, which means the market is now saturated with things that look complete in a screenshot and fall apart on the second click.
The top HN comment thread compares it to the Boeing 737 MAX school of software: the marketing surface is treated as the product, and the engineering underneath is a liability line item. Another highly-voted reply distinguishes between two failure modes the essay somewhat conflates: (1) products that are genuinely small but complete — a text editor that only does five things, but does them without bugs — versus (2) products that *claim* to do fifty things and half of them silently drop your data. The first is a virtue. The second is what the essay is actually attacking, and it's worth keeping the distinction sharp when you're evaluating your own team.
The uncomfortable part, and the reason the piece stings, is that most engineers reading it can name the exact feature on their current product that fits the pattern. It's usually the third-tab-over settings page. Or the export function that only works for accounts with less than 10,000 rows. Or the mobile view that's been "in progress" for two quarters. Half-baked isn't a hypothetical failure mode of some other team — it's the specific TODO comment your PM keeps deprioritizing because no customer has churned over it *yet*.
The business-narrative implication is where this stops being a rant and starts being an argument. For a decade, the operating assumption has been: ship early, capture the market, polish under contract from paying customers. That works in a land-grab. It stops working when the land is grabbed. And there is significant evidence — Basecamp's pricing model, Linear's obsessive craft, Figma's willingness to sit on features for a year before shipping — that in a saturated category, polish is the moat. The essay's implicit business claim is that the industry is about to relearn this the hard way, because the AI-generated slop tier is going to make "actually finished" the new differentiator, the way "actually fast" became one in the era of Electron bloat.
The practical takeaway isn't waterfall, and the essay is careful not to argue for it. Iterating on a shipped product is not the problem. The problem is iterating on a shipped product that never had its edges finished in the first place. Two very different things.
A useful test, and one the HN thread converged on, is: can a new user complete the product's stated primary job without hitting a single "coming soon," broken keyboard interaction, or unhandled error state? If the answer is no, you don't have an MVP. You have a demo you're charging for. The audit that shakes teams isn't "what's on the roadmap" — it's opening the product cold, in an incognito window, and counting how many times you internally think "oh, that's a known one."
For engineering leaders, the specific move is smaller than it sounds: cut the feature list until every remaining feature is genuinely done — offline behavior, error paths, keyboard access, empty states, the boring 40% — and refuse to accept demos of screens that route to placeholder text. This is not a quality initiative. It is a scope discipline. The half-baked pattern is downstream of a product team that would rather ship ten broken things than five complete ones, because ten broken things fills a pricing-page comparison chart and five complete ones does not.
For individual engineers, the essay is permission — the kind that senior devs quietly need — to push back on the ticket that says "ship it, we'll fix in v1.1." v1.1 for that ticket is not coming. It never was. The velocity dashboard doesn't reward it and the sprint after next has three new epics on it. If the fix takes a day now and a week later, the honest move is the day now.
The essay's last-line energy — and the reason it's been passed around Slacks all afternoon — is that the term "MVP" has become a category error. It described a research method, then became a shipping method, then became a shipping *excuse*. The next generation of tools that wins won't out-feature the incumbents; it'll out-finish them. The competitive edge in a market where anyone can prompt their way to a working screenshot in twenty minutes is no longer *what you built* — it's *what you were willing to not ship until it actually worked*. That's not a manifesto. It's just what the market looks like from here.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.