Ship half-baked, inherit Hyrum's Law forever

What happened

A post titled *Half-Baked Product* on weli.dev cleared 1,221 points on Hacker News — the kind of number a personal blog only hits when a thousand engineers see themselves in the copy. The visible take, and the one that got most of the airtime in the thread, is the equilibrium argument: incomplete software isn't a moral failure of the founder, it's the rational output of a market that rewards the first credible product and never revisits the decision.

That framing is correct, but it's the surface. The more interesting mechanism sitting underneath it — the one that explains why half-baked products don't get completed even when the team has the time, the money, and the will — is what happens on the *user* side of the gap. The moment you ship a product with a hole in it, users start filling the hole. They script around it. They pipe your CSV export into a Google Sheet. They stand up a Zapier flow. They train a support macro. They tell each other, on Discord, the specific four clicks that get the thing to behave.

Those workarounds are interfaces. They just happen to be interfaces you didn't write, don't own, and can't see.

Why it matters

Every working engineer has met Hyrum's Law: *with a sufficient number of users of an API, it does not matter what you promise in the contract; all observable behaviors of your system will be depended on by somebody.* The lore version comes from Google, where teams learned that even undocumented, obviously-wrong behavior becomes load-bearing the moment it ships.

Half-baked products get the industrial-strength version of this. When your product is *missing* the feature rather than merely quirky about it, users don't just depend on your behavior — they depend on the shape of the *absence*. The exported-CSV column order. The rate limit that lets three sequential writes through before the fourth 429s. The fact that the search box tokenizes on whitespace so they've learned to type quoted phrases. None of that is documented. All of it is now the product.

Then you try to "finish" v1 — and every user who paved the missing road hits a breaking change. The feature you're proud of shipping breaks the Zap. The redesigned search returns better results but fewer of the ones the power user had memorized. The proper import flow deprecates the CSV pipeline three people at three customers spent a quarter tuning. Your changelog says "we shipped the thing you asked for." Their inbox says "why did you break the thing that worked."

This is why the *first credible product wins the category* claim is stronger than it sounds. The category winner isn't defended by superior features — it's defended by the accumulated user-side scar tissue that would have to be rebuilt against any competitor. Airtable's real moat is not the grid; it's the ten million Zapier flows aimed at the grid. Notion's moat is not the block model; it's the fact that every team's onboarding doc now assumes the block model. Half-baked products don't just outlast better ones — they *become* the substrate the better ones would have to migrate off.

The operating-margin corollary: for the incumbent, completing v1 is negative-ROI work. The upside is a marginally happier subset of users. The downside is a public regression event, a support spike, and a bunch of loud customers whose workflows you just voided. Meanwhile the next feature — the one nobody has built a workaround for yet, because it doesn't exist yet — is pure upside. So the roadmap moves forward and the gap stays open. The half-baked bit calcifies into architecture.

What this means for your stack

If you're building: treat every deliberate gap in v1 as an implicit contract the moment it reaches users. That doesn't mean fill every gap — that's the whole point of the equilibrium argument, you can't. It means design gaps you can close *without invalidating the workarounds people built across them*.

Concretely: if you're going to ship a broken thing, ship a broken thing behind a stable seam. Version your CSV exports so the eventual "proper API" is additive. Put the rate limits and pagination behavior in the docs even if the docs read like an apology, because docs make the contract explicit and give you cover to change what isn't documented. Keep the ugly export endpoint alive for two years past the pretty one — the cost is a route handler; the benefit is not breaking the customer who wired their finance team around it.

If you're buying: assume every vendor's v1 has a load-bearing gap you'll end up gluing shut yourself, and price that in. The right question in a procurement demo is not "does it do X" but "when it doesn't do X, what's the escape hatch, and how stable is that escape hatch?" A tool with a documented, versioned, boring CSV export is safer than a tool with a beautiful roadmap slide about the native integration coming in Q3. The CSV export is the contract. The roadmap slide isn't.

If you're operating a mature product: the workarounds your users have built around your gaps are, unromantically, part of your surface area. Inventorying them is a real exercise. Talk to support. Read the community Discord. Search Zapier for your product's name. That list is your undocumented API, and every "cleanup" ticket in your backlog is quietly proposing to break some entry on it.

Looking ahead

The weli.dev post landed because it named something every practitioner had already noticed but wasn't saying out loud: shipping incomplete is the *strategy*, not the failure mode. The follow-on realization — that the gaps get sealed shut by user behavior faster than by engineering work — is what makes the equilibrium stable. The moat of a half-baked product isn't its features; it's the collective muscle memory of everyone who learned to work around its missing ones. Which means the design skill the next decade of tools will actually reward isn't shipping less half-baked v1s. It's shipping half-baked v1s whose gaps are shaped like doors instead of walls.