The four-week MVP, defended

Our default engagement is four weeks. People keep asking why.

The short answer is that four weeks is not a constraint, it is a forcing function. The longer answer is below.

The myth of "more time produces better software"

It does not. More time produces more software. Often, more software is exactly the wrong thing. The most expensive bugs we have shipped were features we should not have built.

A four-week MVP forces three good behaviors at once:

1. You cannot build the system you imagine. You can only build the system that fits.
2. You cannot afford speculative design — every screen has to earn its keep.
3. You cannot afford speculative architecture — every abstraction has to pay rent inside the four weeks.

The team that has six months will use the first eight weeks designing for problems they do not have yet. The team that has four weeks ships something a user can touch.

The shape of a four-week engagement

Roughly:

• Week 1. Discovery, scoping, working artifact by Friday.
• Week 2. Real product taking shape. First design partners poking.
• Week 3. Hardening, edge cases, the stuff that nobody likes.
• Week 4. Production, hand-off, runbook.

There is no week zero. There is no "alignment workshop." If we cannot describe a credible shape in 48 hours, we are the wrong shop.

What four weeks is not

• It is not a hackathon. There is real engineering quality at the end.
• It is not a prototype. The thing ships to production traffic.
• It is not an MVP in the depressing investor-deck sense. It is the smallest honest version of the product, built by senior engineers.

What is on the cutting room floor

A four-week project is built by deciding what not to build. We refuse a lot of work — admin UIs, configuration screens, anything that can be a hard-coded constant for the first three months. We also refuse most infrastructure choices. You get one database, one queue, one host. We will add a vector store if the product needs one. We will not add three.

The discipline is what makes the deadline real.

When four weeks is wrong

When the problem is genuinely a platform problem — multi-tenant SaaS, data infrastructure, an SDK that thousands of engineers will use. Those benefit from longer timelines and more time spent in design. We do those projects too. We do not pretend they are MVPs.

The honest version

The reason four weeks works is not because we are fast. We are fast because four weeks works. The constraint produces the speed, not the other way around.

That is the whole defense.