When a business evaluates development proposals, the comparison is almost entirely on build cost and timeline. Both are easy to quantify and easy to compare across quotes. Neither is where most of the money goes.
Over a typical five-year life, the initial build is usually the minority of total cost. The majority is everything after: changes, fixes, infrastructure, integrations, and the labour of every person who has to work with the system.
What year two actually costs
- Change requests, which arrive continuously because the business does not stand still.
- Defects, at a rate largely determined by whether the code was tested.
- Infrastructure, at a cost largely determined by architecture decisions made in month one.
- Onboarding, every time a new person has to understand the system.
- Security and dependency maintenance, which is not optional and is not free.
- The exit cost, if you ever want to move — a cost that is set entirely during the build.
A build that is 30% cheaper and produces a system that is twice as expensive to change is not a saving. It is a deferred invoice.
Which build decisions set the year-two number
A small number of decisions do most of the work here, and all of them are visible during the build if you know to ask:
- Is the code typed and tested? This is the largest single driver of future change cost.
- Is the data model coherent, or does it encode a specific screen layout that will be redesigned?
- Can the environment be recreated from the repository, or does it live on somebody's machine?
- Is there monitoring, so a failure is detected rather than reported by a customer?
- Are the decisions documented, so the next engineer does not have to reverse-engineer the intent?
- Do you own the repository, the cloud account and the data?
Questions worth asking any development partner
These four questions separate proposals more reliably than the price does:
- What is the support arrangement after launch, and what does it cost?
- Who owns the repository and the infrastructure accounts on day one?
- What is the test coverage strategy, and what is deliberately not covered?
- If we wanted to move this to another team in eighteen months, what would that involve?
A partner who has thought about the second year will have direct answers. One who is optimising for winning the build will find these questions uncomfortable — which is, in itself, the answer.