The end of the 12-month software project?

Take a typical internal application: a planning tool, an approval workflow, a portal for a few hundred partners. Ask where the twelve months went and the answer is almost never twelve months of engineering. It is three months of requirements, two months of procurement, a month of mobilisation, a design phase that runs parallel to a contract negotiation, then development, then a test cycle timed around a release window.

Each of those layers exists for a reason. Specification exists because the people who understand the problem and the people who will build it are different groups, often in different companies. Procurement exists because the build is expensive enough to require it. Handover exists because the builders leave.

What changes when building gets fast

When a credible working version of an application can exist in days, the economics behind those layers change. A specification written to protect a fixed-price contract is less useful than a prototype the business can click through. A procurement cycle scaled to a seven-figure programme is disproportionate to a six-week sprint.

The document existed because the software could not arrive early enough to argue with.

This is the quiet shift. Requirements documents were never the goal; they were a substitute for seeing the thing. Once the thing arrives in week two, the document becomes a record of decisions rather than a prediction of them.

What still takes real time

It would be dishonest to claim everything compresses. Some work is irreducible, and pretending otherwise is how AI-era projects fail in a new and embarrassing way.

• Integration with systems that were never designed to be integrated with, especially where data ownership is contested.
• Getting agreement on a process that is genuinely ambiguous — no tool resolves a disagreement between two business units.
• Data quality work, which is usually discovered rather than planned.
• Security review, access model design and whatever your organisation requires before something touches production.
• Change: people adopting a new way of working, at the pace people actually adopt things.

Notice that none of these are coding tasks. That is the point. When construction stops being the constraint, the remaining constraints become visible — and they are organisational.

A more useful question

Instead of asking how long a project takes, ask how quickly the business can see something real and react to it. In our engagements the meaningful metric is time to first honest reaction: the moment someone who does the work every day opens the application and says what is wrong with it.

If that moment arrives in week two, the remaining weeks are spent on the right problem. If it arrives in month nine, the project is already a negotiation about scope.