Die Understanding Why: A Failure Postmortem Playbook for Vibe Projects

This series already has three pieces touching on "failure" — but note the distinction: side-project-kill-list is about the decision of when to kill a project; vibe-project-feature-sunset-guide covers the shutdown SOP for a single feature; agent-failure-modes-guide is a field guide to Agent technical failures. This piece is about after the kill: the project is dead, or you have decided to let it die — now how do you run a real failure postmortem, turning this death into fuel for the next run?

First, admit it: failure hurts, but dying confused hurts more

What does it feel like to shut down a project? Michal Bohanes, founder of Dinnr, wrote a passage in his postmortem that goes roughly like this: every day he sat 9 hours a day, 6 days a week, in a cold warehouse in West Acton, hot-air blowers creating 25-degree bubbles around parts of his body in an otherwise 14–15 degree room. The large industrial fridges stood empty — when an order came in, he would jump on his bike and buy fresh ingredients at a nearby supermarket. After 15 months of operations: about one order per day, £26 in average revenue, supposedly 30% gross margin, but with volumes that low, they were losing money on every single order. In the end he turned down a small funding round he had already secured and pulled the plug outright. His own words: "Dinnr simply didn't have legs (never had them to begin with)."

This passage is worth quoting in full because it tears off a layer of self-deception: most failures are not "almost made it" — they are "there never was an opportunity" from day one. The founder admitted it himself. That takes courage, and it is exactly where a postmortem's value lies — failure itself is not an asset; an honest postmortem is.

First, some data, from CB Insights' Why Startups Fail: Top 9 Reasons, published March 5, 2026. They analyzed 431 VC-backed companies that shut down since 2023 (385 of which had enough public record to attribute a cause):

• 70% cited "ran out of capital" — but CB Insights is explicit that this is almost always the final cause of death, not the root problem. Like a coroner's report that says "blunt force trauma": technically accurate, useless for avoiding the crash.
• The telling causes sit underneath: 43% poor product-market fit, 29% bad timing, 19% unsustainable unit economics. Companies frequently cited more than one cause, so the numbers add up to well over 100%.
• These 431 companies burned a combined $17.5 billion before dying — median raise $11M, average $48M; the median time from last fundraise to death was 22 months. Olive (healthcare AI, once valued at $4B) and Convoy (digital freight, raised over $1B) shut down within two weeks of each other in October 2023. Money, even lots of it, cannot save a wrong direction.

The conclusion is especially stinging for vibe developers: the cause of death is almost always upstream. Running out of money is the outcome; what actually killed the project was an earlier decision — picking a direction nobody wanted, picking a channel that never reached users, or a unit-economics equation that never balanced. A postmortem means going back upstream and finding that decision.

Chapter 1 · The Five Questions: Where exactly did it die?

The biggest enemy of a postmortem is not emotion — it is self-flattery. We instinctively attribute failure to externals (bad market, bad luck, bad investors) and success to ourselves. The five questions exist to force each dimension open, one honest answer at a time. Save the framework diagram below, and on the night you shut the project down, write against it:

Question 1 · Demand: did users actually hurt?

The question is not "is this a good idea" but "does anyone hurt enough from this problem to pay for a solution." The test comes from Dinnr's founder's hard-won lesson, and it is the core of Rob Fitzpatrick's The Mom Test: never pitch your product to a user and then ask for feedback — ask about their past behavior instead. When was the last time they took action on this problem? If the answer is "never," this is not a problem waiting for a solution.

One danger signal: users hear your pitch and say "what a great idea" — but never use it themselves. Dinnr's founder called this the "Such-A-Good-Idea Delusion": after the shutdown, people genuinely mourned "such a good idea, what a shame," and he couldn't help asking, "well, if it was such a good idea, why didn't you use it?" The answer: "too busy to cook." Likes are not demand. Only behavior with real cost — money, time, data — counts.

Question 2 · Acquisition: where was traffic supposed to come from?

Many vibe projects die on this question: the product ships, and then… what? How would anyone ever hear about it? In your postmortem, list every acquisition channel you tried and the real conversion numbers for each. If the answer is "mostly posted once and hoped," the cause of death was not a bad product — it was the absence of a repeatable acquisition engine. Be honest: did you ever invest energy into acquisition comparable to what you put into code? Most indie developers' answer is no.

Question 3 · Monetization: does the math work?

Lay the unit economics bare: what is customer acquisition cost, and can price × conversion cover it? RethinkDB founder Slava Akhmechet admitted in his postmortem that they picked the wrong market from the start — users treated RethinkDB as an open-source tool and almost nobody wanted to pay for it; set a real price barrier and users would simply walk to one of the many free alternatives. With the market wrong, every optimization afterward was wrong too. Same for your project: if nobody was ever going to pay for this category of thing, that is not a pricing-strategy problem — it is a the-market-doesn't-pay problem.

Question 4 · Execution: did you misplay a good hand?

This is the hardest question to answer honestly, because the finger points at you. Kiko's postmortem is this question's textbook: the team wanted to work on several ideas at once, attention scattered from the main project; the CEO himself admitted "we were too slow at times and wasted time on unnecessary things and neglected what was crucial"; they hired the wrong person — someone who completed no tasks and disappeared for months. And one that will hit many indie developers: they never involved investors from the beginning — nobody external to pour cold water or give guidance.

An execution postmortem must be specific about people, events, and timing: which decision was wrong? Which code or feature was waste? Which delay was fatal? Write it down — don't paper it over with correct-but-empty phrases like "insufficient execution."

Question 5 · Timing: too early, or too late?

In CB Insights' data, 29% of failures trace to timing. Timing is the hardest to postmortem because it looks most like "luck." But you can ask a sharper question: would doing this a year earlier or later have changed the outcome? If the answer is "no, the problem itself never held up," then it was never a timing problem — it was a demand problem, and timing is just a fig leaf. If the answer is "yes," write down your judgment about timing — that is the single most valuable intelligence for your next run.

After the five questions, you should be able to point at one or two dimensions and say: "it mainly died here." If you can't answer any of them, the postmortem isn't honest enough yet. Start over.

Chapter 2 · The Failed-Asset Recovery Checklist: turning the corpse into ammunition

A dead project does not mean the investment evaporated. Kiko's most legendary move: the team put Kiko's software up for auction on eBay, and it sold for $258,100. A failed project's code, sold for a quarter of a million dollars. That is "failed-asset recovery" — inside every dead project hides seed funding for the next one.

Go through this checklist item by item:

Asset class	What you may be holding	How to recover it
Code & components	Auth modules, payment integrations, admin panels, scrapers/data pipelines, UI component libraries	Extract into a reusable private template library; open-source it for stars and reputation; or, like Kiko, sell it outright
Domains	The project domain (especially one with authority or memorability)	Keep it for the next project; list it on a domain marketplace; or 301-redirect it to your personal site to catch residual traffic
User list & community	Registered-user emails, Discord/WeChat group members, social followers	The most valuable asset of all. In the shutdown email, explain honestly why — and tease the next project, migrating the trust over
Content & trust	Tutorials you wrote, postmortems, technical posts, your build-in-public record	One honest failure postmortem often earns more trust dividends than the project itself ever did (see Chapter 3)
Data & insights	User interview notes, funnel data, pricing-test results, every pitfall hit	Compile into an internal memo; your next project's idea selection will draw on it directly — you now understand this niche's failure modes better than anyone
Relationships	Developers you worked with, users who gave feedback, investors you talked to	Send each a sincere farewell note at shutdown; many will come back for your next project

Watch for one mindset trap: after shutting down, many people's first instinct is to delete the repo, drop the domain, and pretend it never happened — "the fewer traces of failure, the better." The opposite is true: deleting destroys evidence; keeping preserves assets. Months after RethinkDB shut down, its technology was taken over by the Linux Foundation (CNCF) and lives on as a community open-source project; its founder later joined Stripe, and his postmortem became a developer-community classic. That is asset recovery in its ultimate form: the project died, the influence didn't.

Chapter 3 · The Public Postmortem Writing Guide: how to write it without it blowing up

The trust dividend of building in public is real. An honest failure postmortem routinely gets more reads, more respect, and more next chances than the project itself ever did. But a public postmortem is also high-risk: done well it reads as candor; done badly it reads as a blame game. Here are the boundaries — what to say and what not to say:

Say this: four required parts

• Timeline and numbers. When it started, when you decided to shut down, how much money burned, the real user/revenue curve. Numbers are the foundation of a postmortem's credibility. Dinnr's postmortem includes even the embarrassing figures — "3 orders on day one, 12 in the first week" — which is precisely why it is still shared years later.
• The one or two dimensions you believe were the real cause. Organize with the Chapter 1 five-question framework. Listing ten causes is the same as listing none.
• What you were thinking at the time. The information, assumptions, and emotions behind each decision. Readers don't want a god's-eye correct postmortem — they want to see why a smart person made that call with what they knew then.
• What you would do differently. The single most valuable section, and your direct handoff to the next run.

Don't say this: four red lines

• Don't blame specific people. You can write "we hired the wrong person" (Kiko's founder did), but no naming, no humiliating detail. A postmortem faces the future; it is not a tribunal.
• Don't attack investors or partners. Even if you believe they were at fault. The short-term thrill of public execution costs you the entire circle's trust at a discount.
• Don't publish unverified accusations. "I suspect a competitor was faking orders" — without evidence, don't write it. Once a suspicion is public, it becomes your position.
• Don't beautify or fabricate numbers. Postmortem figures get quoted and screenshotted. Dinnr's founder would rather write "losing money on every order" than pretty it up — honesty is the only moat.

A structure you can copy directly

1. One sentence: what the project was, when it shut down.
2. Three to five key numbers (time, money, users, revenue).
3. The cause: use the five-question framework, cover only the top one or two.
4. Why you decided the way you did back then (information, assumptions, emotions — all of it).
5. If you did it again, what you would do (no more than 3 items, concrete).
6. Thank-yous: users, collaborators, investors — written sincerely. This is the key step in migrating trust.

One last thing: before publishing, show the draft to your co-founders/core members. Not to ask permission, but to catch factual discrepancies. What blows up public postmortems most often is not the opinions — it is the factual errors the people involved point out.

Chapter 4 · Three real failure cases, dissected

All three cases below come from Failory's Startup Cemetery (cause-of-death analyses of 120+ shut-down companies) and the founders' own first-hand postmortems. Facts and figures are quoted from the originals, no embellishment. Each case ends with a commentary: viewed through the Chapter 1 five-question framework.

Case 1 · Dinnr: the classic anti-pattern on demand

Background: Dinnr was a same-day ingredient-delivery service in London: pick a recipe on the website, and pre-measured ingredients with printed instructions arrive the same day; all you needed at home was oil, salt, and pepper. Launched September 2012, shut down January 12, 2014 — about 15 months of operation.

Key facts from the original (founder Michal Bohanes' August 17, 2014 Medium postmortem, Seven lessons I learned from the failure of my first startup, Dinnr):

• Pre-launch research looked fantastic: 70% of 250 target-market respondents said they would buy; the alpha group gave thumbs up; 1-on-1 interviews all said "you're onto something."
• Day one: 3 orders; week one: 12 orders. The founder described it as being "knocked out of La-La land back into reality."
• Fifteen months in: about one order per day, £26 average revenue, supposedly 30% gross margin — but at that volume, losing money on every order.
• The founder sank tens of thousands of pounds of personal money into it. At shutdown he had already secured a small second round — and turned it down: "the only thing I would do with this money would be to try to acquire more infrequent customers and keep the lights on for another few months" — taking it would not have been fair to investors.
• His core conclusion: "we were not solving anyone's problem." The research mistake was pitching the product to people and asking for feedback — what users meant by "I would buy" was really "under extreme hypothetical conditions I might not exclude buying once," and he heard "I'll buy when you launch."

Commentary (against the five questions): This is a textbook Question 1 (demand) failure. The single sentence every vibe developer should copy down is his diagnosis: don't ask users what they would do in the future ("would you buy this?") — ask what they did in the past. He also proposed a brutally practical test: ask for commitment on the spot — "fine, give me £20 and I'll deliver you a prototype next Tuesday." In hindsight, of 10 interviewees 7 liked the idea, but only 2 became customers, weeks or months after launch. Same for your project: before writing another line of code, find someone willing to pay £20 (or an equivalent real cost) for a prototype. Can't find them? Don't write the code yet.

Case 2 · RethinkDB: wrong market + wrong metrics

Background: RethinkDB was an open-source distributed NoSQL database built for the real-time web, in development since 2009; the company shut down in October 2016. Months later, the technology was taken over by the Linux Foundation (CNCF) and survives as a community project.

Key facts from the original (founder Slava Akhmechet's January 18, 2017 postmortem RethinkDB — Why we failed, ~2,600 words; also covered in Failory's cemetery analysis):

• The founder's self-diagnosis is a single sentence, quoted ever since: "We picked a terrible market and optimized the product for the wrong metrics of goodness."
• "Terrible market": users treated RethinkDB as an open-source tool from day one and almost nobody wanted to pay for it; with any substantial price barrier, users would have walked to the ocean of free alternatives.
• "Wrong metrics": the team's definition of "good" was shipping a flawless product, designing a simple interface, guaranteeing consistency. What users actually wanted: availability ASAP (they waited almost 3 years), speed, and a proven way to store JSON documents and build reports. Ironically, MongoDB won big with an initially buggy product — because it delivered what users actually wanted first.
• He left one line for every developer-tools founder: "If you do set out to build a developer tools company, tread carefully. The market is filled with good alternatives. User expectations are high and prices are low."

Commentary (against the five questions): A compound failure of Question 3 (monetization) and Question 4 (execution), rooted in Question 3. The trap vibe developers fall into is identical to RethinkDB's: mistaking "users think it's cool" for "users will pay." GitHub stars, a Hacker News front page, Twitter reshares — those are "cool" metrics, not willingness to pay. Translated into vibe terms: while you're polishing the "perfect architecture" in month three, first answer one question — are there 10 people willing to pay monthly for this half-finished thing right now? If not, the direction you're optimizing, like RethinkDB's, may be wrong.

Case 3 · Kiko: the execution-failure specimen

Background: Kiko was an Ajax-era online calendar app with API integrations — friendly UI, accessible from any computer, shareable calendars. It ran about 3 years before shutting down. Its ending is the famous part: the team auctioned the software on eBay, and it sold for $258,100 — possibly the most dignified "asset sale" in startup history.

Key facts from the original (Failory's cemetery analysis of Kiko, synthesizing the founders' postmortem):

• Cause one: the team wanted to work on several ideas and plans at the same time, diverting attention from the main project and causing delays.
• Cause two: the CEO himself admitted they were too slow at times, wasted time on unnecessary things, and neglected what was crucial.
• Cause three: they hired the wrong person — someone who completed no tasks and disappeared for months, directly dragging team output down.
• Cause four: they never involved investors from the beginning or sought their guidance. Failory categorizes Kiko under "Bad Management."

Commentary (against the five questions): A pure Question 4 (execution) specimen, and every line hits an indie developer's common cause of death. "Working on several ideas at once" — that's the vibe developer running three side projects simultaneously; "wasting time on unimportant things" — two weeks tuning landing-page colors while the core feature still doesn't run; "no external accountability" — solo development's biggest risk is that nobody ever tells you "this direction is wrong." Kiko's case also carries a positive message: it proves Chapter 2's asset recovery is not motivational fluff — if even a failed project's code can sell for $258,100, your domain, your user list, your postmortem are worth more. Don't delete the repo. List it.

Finally: a postmortem is written for the next run

Back to the opening line: failure itself is not an asset; an honest postmortem is. CB Insights' data says 43% of deaths trace to poor PMF — translated: nearly half of all projects "never had an opportunity from the start." Dinnr's founder spent 18 months and 12 days and tens of thousands of pounds to buy that understanding. Your postmortem buys the same lesson for a few hours of honesty.

On the night you shut the project down, do three things: first, write a one-page postmortem against the five-question framework, for your eyes only — the harsher the better; second, go through the asset checklist and recover everything recoverable; third, decide whether to write it publicly — if yes, use Chapter 3's structure, and show the people involved before publishing.

Then take that page into the next run. Die — but die understanding why. Once understood, it was never in vain.