What four weeks of software development actually buys you

When we say a project ships in four weeks, the reasonable reaction is suspicion. Software has a long history of taking three times as long as promised, and a short timeline usually means a short list of things that were quietly left out.

So here is the honest version: what four weeks contains, what it does not, and the conditions that have to hold.

What fits

• One process, done properly, end to end
• Six to twelve screens, two or three user roles
• A real database, real permissions, real validation
• One integration, if the far end has a working API
• A dashboard over the data the tool itself collects
• Mobile friendly, because half the people will use it on a phone
• Deployment, training and handover

What does not fit

• Several processes at once. Each one is its own four weeks.
• Integrations with systems where access has not been arranged yet. That clock is not ours to control.
• Migration of years of messy historical data. That is its own piece of work and it deserves its own estimate.
• Anything needing formal certification or validation.
• A feature list assembled by asking twenty people what they would like.

The conditions

Four weeks is not a property of the studio. It is a property of the project, and it holds when three things are true.

First, one person can make decisions. Not a committee, not a steering group, one person who can look at a screen and say yes or change it. The single biggest cause of overrun in small projects is not technical, it is waiting for an answer.

Second, the scope was cut before it started. Everything we have shipped on time had a scoping call where things were removed. That conversation is uncomfortable for about ten minutes and it saves a month.

Third, the client sees it weekly. A link every Friday means a wrong assumption is corrected in week two instead of discovered in week four. It is not a progress report, it is a correction mechanism, and it is why fixed price is survivable at all.

What happens when it slips

Sometimes it does. The usual reasons are an integration we were told was available and was not, a decision maker who went quiet, or something genuinely harder than it looked. The first two are about access and availability, which is why we write down what we need from the client at the start. The third one is ours, and on a fixed price it costs us rather than you. That is the entire point of quoting fixed price: the risk sits with the party who can estimate.

A four week project is not fast because people work faster. It is fast because less was attempted and nothing waited.