When a software project disappoints, the post-mortem usually looks at delivery. Estimates, velocity, scope creep, the team. Occasionally that is the real story.
More often the project was decided months earlier, in a few conversations that nobody thought of as technical.
Scope written as features, not as outcomes
A specification that lists what the system will contain cannot be used to decide what to cut. And every project eventually has to cut something.
A specification written as outcomes can. "Reduce the time from enquiry to quote" tells a team what to protect when the schedule tightens. "A quote builder with templates and PDF export" does not.
The riskiest assumption scheduled last
Every project rests on something nobody has verified. The data is cleaner than anyone has checked. The third-party API does what its documentation says. Users will accept the new flow. Migration is a week.
The natural instinct is to build the familiar parts first, because they produce visible progress. The consequence is that the assumption that can sink the project is tested at the point where there is no budget left to react to the answer.
Find the assumption that would hurt most if it were wrong, and test it in week one — even crudely.
Architecture chosen from familiarity
Some decisions are cheap to change and some are not. Which database, which rendering model, where the boundaries between services sit, how tenancy works, how identity works: these are the expensive ones.
They deserve an hour of deliberate argument and a paragraph of written reasoning. They usually get neither, because the answer felt obvious to whoever was in the room.
No agreed definition of success
If nobody wrote down what version one has to achieve, then version one cannot succeed. It can only be delivered, and then judged against whatever each stakeholder privately expected.
One sentence, agreed before the build starts, prevents an enormous amount of disappointment later. It is also the cheapest artefact in the entire project.
The pattern
None of these are engineering failures. They are decisions made quickly, by reasonable people, at a moment when they did not feel consequential.
That is exactly why a short, deliberate phase before development pays for itself — not as a deliverable, but as the moment those four questions get asked out loud.
