What 400 product launches taught us about the first eight weeks.

The first two months of a software project decide far more than the launch date. They decide whether the team is solving the right problem, whether scope stays understandable, and whether everyone can still explain the product without opening Jira.

The first eight weeks are not a warm-up

Teams often treat the beginning of a project as the quiet part: requirements, wireframes, architecture, setup. The exciting work is supposed to come later, when screens appear and features begin moving. We think the opposite is true. The beginning is where the expensive mistakes are still cheap.

After more than 400 product launches, the pattern is consistent. Projects rarely get into trouble because the team could not write the code. They get into trouble because the product was never made small enough to understand, because nobody wrote the decisions down, or because feedback arrived after too much had already been built.

A good first eight weeks does not produce the maximum number of features. It produces clarity, momentum, and evidence that the team is building the right thing.

Week 1: turn the brief into decisions

A brief is not a specification. It is the beginning of a conversation. In the first week we want to answer a handful of questions that sound simple and are surprisingly difficult:

This is also the week to make assumptions visible. If a payment gateway has not been chosen, say so. If the client expects an ERP integration but no API documentation exists, put that uncertainty on the table. Hidden uncertainty is what later disguises itself as ‘scope creep.’

Weeks 2–3: design the smallest complete journey

An MVP should not be a random subset of features. It should be the smallest complete journey a real customer can use from beginning to end. For a booking product that might be discover → select → pay → confirm. For an internal workflow it might be submit → review → approve → report.

The trick is to remove optional branches without breaking the main journey. We would rather ship one path that works cleanly than five paths that are all 70% finished. Seventy percent finished software has a remarkable ability to look 95% finished in a status meeting.

The beginning is where expensive mistakes are still cheap.

Weeks 3–5: prove the risky parts early

Every project has one or two things that can break the plan. A complex integration, unreliable source data, an app-store rule, a hard AI retrieval problem, or a workflow nobody has tested with real users. Build those first.

Teams naturally prefer visible progress. A polished dashboard feels productive; wrestling with an undocumented API does not. But if the API can sink the schedule, it deserves attention before the dashboard gets its third shade of grey.

Weeks 4–8: demo working software every week

Weekly demos force useful honesty. A ticket can be ‘90% complete’ for days. A demo either works or reveals what is missing. That is why we prefer to show software rather than describe progress.

A good demo is not theatre. It should include rough edges, unanswered questions, and decisions the team needs from the client. The goal is not applause. The goal is to shorten the distance between building something and learning whether it was the right thing to build.

What we protect during those eight weeks

We protect the main user journey, the architecture decisions that are expensive to reverse, and the team’s ability to communicate directly. We are much less protective of nice-to-have features. Features can move. Confusion compounds.

By week eight, the most important question is not ‘How much did we build?’ It is: ‘Do we have a product direction we still believe in after seeing real software?’ If the answer is yes, the project is usually in good shape.

The takeaway

Fast delivery is not the same as rushing. The fastest teams we know spend the start of a project answering open questions, testing the risky parts, and getting working software in front of the people who decide.

The first eight weeks are where you earn the right to move quickly later.