Every client who asks for a six-week build is really asking two questions: can this exist, and can it exist before the money or the patience runs out. The timeline is not the hard part. Deciding what is not in it is.
Scope is a subtraction problem
I start by writing the one sentence the product has to prove. For an aesthetics clinic it was: a patient can book a consultation with a verified clinician and pay for it. Everything that does not move that sentence forward goes on a second list, and the second list is not part of the build.
That list usually includes analytics dashboards, notification preferences, bulk import tools, and every settings screen anyone has ever asked for. None of them are wrong. They are just not what the first six weeks are for.
If a feature cannot change whether you launch, it cannot be in the launch.
The data model comes first
Before a single screen exists I write the schema, because the schema is the thing that is expensive to change later. Roles, states, and the transitions between them get modelled up front — verified, pending, restricted — so that the UI is reading a decision rather than making one.
This is the step people skip when they are in a hurry, and it is the step that decides whether week five is spent building or untangling. A front end can be rewritten in an afternoon. A data model with three months of production rows in it cannot.
Ship the boring path completely
One flow that works end to end beats four flows that half work. I take the primary path — sign up, book, pay, confirm — and make it genuinely complete, including the failure cases, before starting anything else. Failure cases are not polish; a payment that silently does not clear is a broken product.
What you get at the end of six weeks is not a small product. It is a narrow one, finished. That is a much better thing to hand a first customer.