Four months is short for building a product and long to wait for an answer. Here is how the calendar actually fills up, week by week, and at which moments the decisions fall.
The question we are asked before signing is almost never “what are you going to build”. It is “what is going to happen during these four months, and what do I have to do”. Here is the answer, without the vocabulary of method.
Weeks 1 to 3: writing the question, not the specification
A project that starts with a feature list has already taken its first turn in the wrong place. The list answers “what do we want to build”, whereas the only question that counts at this stage is “what do we not yet know”.
So these three weeks serve to write one sentence, always of the same form: will people like X do Y often enough for Z to become viable? Until that sentence has real names, a real behaviour and a real threshold, it is not finished.
It is the most uncomfortable part of the project. It forces you to admit that some features you are attached to do not serve the demonstration, and so will wait. At the end, two lists exist: what will be built, and what will not. The second is the one that protects the timetable.
Weeks 4 to 7: something you can handle, even if it is ugly
The aim of this phase is not to build fast, it is to make the idea criticisable. As long as a product exists only in a conversation, everybody agrees, because each person is picturing something different.
For this prototyping stage, we set out the AI-assisted generators in Bolt or Lovable.
So we quickly put out a clickable journey on the screens that carry the stakes. It does not do everything, it is not beautiful, and that is deliberate. What we are trying to provoke are sentences of the kind “ah, but I thought that”. Each one is worth a week saved later.
It is also the moment when the platform is settled, once the scope is known and not before. The criterion is real use: a tool handled sitting in front of a screen does not live in the same place as a tool taken out of a pocket on a site. We set out that judgement call on the application development page.
Weeks 8 to 13: building, in fortnightly cycles
It is the longest and calmest phase. It runs in two-week cycles, with something you can handle at the end of each.
That rhythm is not a preference of method, it is a protection. A project that shows nothing for two months has no way of knowing it is drifting, and discovers the gap at the moment it costs most to correct. The corollary is that you will see imperfect versions early: that is normal operation, not an alarm signal.
Three things are decided here, and none of them is visible on screen. The data model, because it is the only element that cannot be corrected without starting over. Permissions, handled at the data level and not at the display level, because a hidden button is not a protection. And the naming scheme, so that whoever picks the product up in a year understands what they are looking at.
Weeks 14 to 16: in real hands
Going live is not the end of the project, it is the beginning of measurement. The last weeks serve to put the product in front of users who owe you nothing, and to watch them use it without helping them.
It is the most revealing and most unpleasant exercise in the trade. It shows live what was defended in a meeting. When three people out of five cannot find the button, the discussion about its colour becomes moot.
In parallel comes the handover: your team learning the product, documentation of what each part does, and the appointment of the person who will carry the product after us.
The three decisions that always fall at the same moment
- End of week 3: what gets cut? It is the decision that determines whether the deadline will hold. It is taken once, in writing, and is reopened only along with the deadline.
- End of week 7: is the journey the right one? It is the last moment when changing your mind costs days rather than weeks.
- End of week 13: who tests it, concretely? That decision is prepared from the start, because rounding up ten real users takes longer than people think.
What makes the timetable slip
Three causes come up, and none of them is technical.
A decision waiting on a meeting that never gets scheduled. A project that waits two weeks has lost two weeks, whatever the build rhythm.
A scope reopened without the deadline being reopened with it. Every new idea is reasonable taken on its own; together they exhaust the budget before launch.
Test users who never get rounded up, so that the product ends up being judged on internal opinions. It is the most discreet way of failing a first version: it is delivered on time and it has demonstrated nothing.
What never goes into a first version
The list of what gets cut is more instructive than the list of what gets built, because the same items come up from one project to the next.
Settings. A settings screen assumes you already know what users will want to change. At this stage, you do not. A value fixed in the code, that you change yourself when somebody asks, teaches more and costs a hundred times less.
Multiple roles. A product distinguishing five user profiles multiplies the journeys to design, build and test, before even knowing whether one of them stands up. You start with one role, possibly two when the relationship between the two is the very subject of the product.
Dashboards. They are asked for very early and serve very late. As long as there is no volume, you read the data by hand in three minutes, and that manual reading teaches things a chart would have hidden.
Payment, often. It is the point that surprises most. Agreeing to pay and agreeing to pay that price are two distinct questions, and the second cannot be tested on ten users from your own network. Taking payment by hand from the first customers tells you more than a checkout flow built in advance.
None of these items is set aside for good. They go into the next batch, which is decided with the data from the first rather than with the assumptions from the start.
What you have at the end
A product online, used by real people with real data. An answer to the question written in week 1, which may perfectly well be negative. A data model validated by use, journeys that have been proven and business rules written down.
That last point is the one people underestimate. If the product takes off and has one day to be redeveloped, what transfers is not the code: it is that knowledge. A technical team starting with it does not build the same thing as a team starting with a specification. That is where the first version takes its real economic value, by reducing the risk rather than by replacing the development.
