Argues that products shipping without offline mode, keyboard shortcuts, working exports, or stable APIs would once have been called unfinished, but are now labeled MVPs or v1s. The vocabulary evolved to normalize the practice, so the practice never had to change.
Defends the incomplete-shipping pattern as a rational response to funding realities. In winner-take-most markets, the first credible demo captures distribution, so investing in completeness before product-market fit is a way to lose the category entirely.
Agrees that products are shipping half-baked, but rejects the economic determinism. Argues that leadership and product management chose this path — engineers repeatedly flag missing fundamentals like offline mode, exports, and keyboard support, and are overruled in favor of feature velocity.
Argues the essay romanticizes the past. Photoshop 3.0, early Office, and other canonical 'complete' products shipped with bugs, missing features, and broken workflows — we just remember them fondly because the survivors got polished over decades.
Notes that Hoffman's famous line was specifically about a first version, but somewhere between 2012 and now it quietly got stretched to justify shipping every subsequent version half-finished. The distribution-wins logic (Slack vs HipChat, Notion vs Evernote, Figma vs Sketch) then locked the pattern in as defensible strategy.
A post titled Half-Baked Product on weli.dev cleared 1,072 points on Hacker News, one of the highest scores this month for a non-launch essay. The thesis is blunt: the software you use every day is deliberately incomplete, and the incentive structure that produces it isn't going to change because the incomplete version is the one that wins.
The author's core observation — the thing that made the comment thread ignite — is that we've stopped calling this failure. Twenty years ago, a product that shipped without offline mode, without keyboard shortcuts, without a working export, without a stable API, would have been reviewed as unfinished. Today it's called an MVP, a v1, or "we're iterating." The vocabulary caught up to the practice, and the practice never had to change.
The HN comments split roughly three ways: founders defending the economics ("you ship what gets funded"), engineers agreeing with the diagnosis but blaming leadership rather than the market, and a smaller camp arguing the whole framing is nostalgia — that Photoshop 3.0 was also half-baked, we just don't remember it that way.
The piece landed because it names something senior engineers have felt for a decade but haven't had clean language for. The industry defense of shipping incomplete work has always been Reid Hoffman's line — "if you're not embarrassed by your first version, you shipped too late." That quote was about a first version. Somewhere between 2012 and now, it quietly got applied to every version.
The economic reality the essay refuses to sugarcoat: in a winner-take-most category, the first product that's credible enough to demo captures the distribution, and everything after is defensive. Slack didn't beat HipChat by being more complete — it beat it by being credible enough, faster. Notion didn't beat Evernote on features; it beat it on the smell of momentum. Figma versus Sketch is the cleanest case: Figma shipped with real gaps for years, and Sketch's completeness became irrelevant the moment Figma's collaboration story was good enough.
Once you internalize that, "half-baked" stops being a moral failing and becomes a strategy. The competitor who waits to fully bake gets to enjoy their thorough product with a small user base while the half-baked one absorbs the category and uses the revenue to bake in public. This is not a hypothetical — it's the last fifteen years of SaaS.
What the essay adds, and what the HN thread missed in its rush to argue economics, is the second-order cost. The users of half-baked products don't just tolerate the gaps — they build workflows around them, and those workarounds become switching costs the vendor didn't have to pay for. Every Zapier integration is scar tissue. Every "here's the CSV export hack" thread on Stack Overflow is free retention. The unfinished product isn't just cheaper to build; it's stickier, because users have already invested in routing around it.
The part of the argument that doesn't quite hold up: the essay implies this is new. It isn't. Windows 95 shipped with a networking stack you had to patch to make usable. Early Rails apps had no test coverage and worked fine. What's actually new is the scale of the incompleteness relative to the price. A $200/seat/month tool with no audit log, no SSO on the standard plan, no working search, and a status page that lies — that's a different kind of half-baked than an early-90s desktop app that crashed twice a day but cost $49 once.
If you're evaluating tools, the essay is a useful reframe: stop asking "is this product finished" and start asking "which specific 20% is finished, and is it the 20% I need?" Every SaaS you're paying for is a bet on which subset of the problem the vendor decided was load-bearing. If your critical path overlaps with theirs, you're fine. If it doesn't, no roadmap promise will save you — the roadmap exists to keep you paying, not to complete the product.
The practical move is auditing what your team has actually built on top of vendor gaps. Every Zap, every internal wrapper, every "we wrote a script for that," every browser extension your ops team installed — those are receipts for features the vendor didn't ship. Add them up. If the number is large, you're not a customer, you're an unpaid co-developer, and switching costs are higher than the contract implies.
If you're shipping rather than buying, the honest version of the essay's advice isn't "ship less half-baked" — that argument has lost. It's: be deliberate about which half you're baking. The half-baked products that survived their launch weren't randomly incomplete; they nailed one workflow so completely that the missing pieces read as focus rather than absence. Linear at launch had no mobile app worth using and a laughable roadmap for permissions — but the keyboard-driven core loop was tighter than anything else on the market. That's the version of half-baked that wins. Randomly-half-baked is just unfinished.
The essay's real contribution isn't the diagnosis — engineers already knew — it's the concession that the equilibrium is stable. Half-baked products win, users build around them, switching gets harder, and the next generation of tools will be half-baked in exactly the same way for exactly the same reasons. The interesting question the piece doesn't answer, and that the HN thread only circled, is whether AI-assisted development changes the math. If the marginal cost of shipping the missing 80% collapses, does the strategic advantage of shipping the first 20% collapse with it? Probably not — distribution beats completeness even when completeness is free. But it's the first thing in twenty years that might.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.