Why Version Two Gets Over-Built
Once a first version works, the plan for version two grows to fit every future anyone can imagine. Three questions keep it to what users need now, and it ships sooner.
Once a first version works, the plan for version two grows to fit every future anyone can imagine. Build it for the users you have, and it ships sooner.
Fred Brooks named this the second-system effect in The Mythical Man-Month (1975): after a successful first system, the team sets out to “do it right this time” and builds for futures that may never arrive. A firm replacing a system that has run for years meets the same pull.
Chronologiq is an AI product our founder, Shan Peiris, built before neesh Inc. The example below is from it, and the numbers are his rather than a client’s.
Chronologiq’s first version shipped in weeks with fourteen service classes, each doing one thing. The plan for version two had 47. It shipped sooner, with 22.
What the Plan Grew Into
The list grew from engineering ambition rather than from user requests. “While we’re in there” became the most expensive phrase in the project.
Of twenty items, seven shipped. The thirteen struck out were reasonable ideas that nobody had asked for yet.
Three Questions Before Anything Goes In
Every item passed a technical review. Only seven passed these three questions.
What Version Two Became
Everything that shipped was there because users hit a wall without it, or because it made the next three features faster to build.
A flat structure. Errors handled differently in every route. No input checks. Database calls everywhere. Credits taken before the AI ran. AI responses taken as given.
A shared base for every service. One set of error types. Input checked on every endpoint. Every threshold in one place. Credits charged after the work succeeds. Three checks on each AI response, with a fallback.
Each of the eight new services removed a category of bugs. Three of them:
CreditChargeService: no double charges, and no charges for work that failedSummarizationService: no long documents overflowing the AI model’s input limitLLMParsingService: one copy of the prompt logic instead of one per route
Where the Time Went
Illustrative: Chronologiq version two. Not a time-tracking record.
About a seventh of the time went to deciding what not to build, and it was the most productive time on the project: every feature left out is maintenance nobody carries.
Applying It to Your Rebuild
The effect comes from good engineers deciding ambitiously at the wrong time, and the cure is sequence. Build what users need now, what makes the next piece faster, and what cannot be added later; everything else goes on a list with a date to look at it again. Chronologiq’s thirteen cut features are on that list, waiting for someone to need them.
What is on your rebuild’s wish list that no user has asked for?
Book Free Assessment