The project that died in a one-day sprint (and what I extracted from it)

I have a project that lived for one day. A single sprint, morning to evening: born, raised, shipped. And then, just as quickly, parked forever.

The temptation was to bury it quietly, the way you do with projects that didn't make it and with balcony plants. Instead I performed an autopsy. It turned out to be the working day with the best lessons-per-hour ratio of my career.

One day of life

The project was an app for organizing parties and events — signup forms, payments, emails, the usual liturgy. Built in a single sprint day with the agents: me directing traffic, them writing. By evening it worked. Actually worked: deployed, full flow, test payment cleared.

And there, in front of the working thing, the uncomfortable question nobody ever asks at the demo: now who uses it?

The honest answer was: nobody, for now, and not because of the software. The project went into mothballs the same day it was born — at the company we elegantly call it the "incubator", which sounds better than "limbo".

The autopsy

That same evening, an agent wrote the post-mortem. Diligent, tidy, full of "patterns extracted from the experience": thirteen things that worked, eleven "emergent" ones. Twenty-four lessons. From one day of work. Twenty-four. And at the bottom, already formatted, a table of twelve actions to put into practice right away, plus a quarantine section titled, in capitals and without mercy, WHAT IS SPECIFIC TO MYFESTAPP — DO NOT GENERALIZE: eleven entries.

Here comes the part that taught me the most, because the temptation was real: take those twelve actions and promote them to company rules immediately. Look how much we learned! Such productivity! Instead, the next day, the review — done by the human, red pencil in hand — started from an awkward observation: every "pattern" in that document had been seen once, twice at most. And it ran every entry through three filters:

• Would it hold at a second company, even an imaginary one?
• What does it cost to extract it, right now?
• Does it sit at the right layer — a rule for everyone, or a trick for a single technology?

Every entry landed in one of four boxes: extract now, extract but only for that technology, wait for the second company, no action. Out of the first box came the templates — the decision document, the project diary — which that very day became the first version of the framework later companies start from. The third box kept, aging with dignity, the things that looked like laws and might have been coincidences. And the lint rule, the cleverest of the lot on paper, is still sitting there waiting for someone to switch it on. Statistics with n=1 isn't statistics: it's an anecdote in a nice suit.

What remains of a dead project

The back-of-the-napkin numbers, obituary edition:

• Days of development: 1
• Real users: 0
• Revenue: €0
• Lessons proposed by the autopsy: 24
• Actions proposed by the agent: 12
• Entries quarantined as "do not generalize": 11
• Days between the autopsy and the framework's first version: 1
• Lint rules actually switched on: 0

Because this is what makes the autopsy the day's best investment: the project died, but its skeleton — the document templates, the database permission rules, even the habit of waiting for the second company before writing a law — became the scaffolding of what was built since. Nobody uses the app; its post-mortem became the framework's first brick.

In my old blog I would have closed with a reflection about the journey mattering more than the destination. Twenty years later, I'll rephrase it as a founder: the destination was wrong, the journey was the product.

The project is dead. Long live the post-mortem.