SERF: four years of unfinished software, and the honest answer about it

A project management tool for events had been started twelve times over four years and never shipped. We were asked to work out how to finish it. The recommendation was to keep the hard-won understanding of the problem and abandon every line of the code, and then we wrote down what the thing actually needed to be so the next attempt would be the last.

The situation

Twelve project folders spanning four years, each one a restart, none in anyone's hands. The instinct in that situation is always to rescue the most complete attempt, because throwing away that much effort feels irresponsible. It is usually the wrong instinct, and it is very hard to say so from inside.

What we built

We read all of it and separated two things that had got tangled: the accumulated understanding of the problem, which was genuinely valuable and had improved with every attempt, and the code, which was twelve partial answers to a question that had changed each time. The understanding was worth keeping. The code was not, and continuing to carry it was the reason each restart began further behind than the last. Then we wrote the product down properly: what it is for, who it is for, what it must do when there is no signal in the basement of a venue, and — the part that distinguishes it — that venues, vendors and crew are long-lived records that accumulate history, so the next production in the same theatre starts from what was learned in the last one. That went out as a plan and as materials the stakeholders could actually read.

• Full review of four years of prior attempts
• A clear split between what was worth keeping and what was not
• A written product definition, scoped to ship
• Stakeholder materials in plain language, not a technical document
• An offline-first requirement stated up front, where it belongs

Interface illustrations. Abstracted representations with placeholder content — never client data.

What changed

A defensible decision replaced a four-year loop. The next build starts from a written specification and a clear differentiator rather than from someone else's abandoned attempt.