Six weeks is enough to ship something real — but only if you're honest about the four things that always eat the time.
"Can you build it in six weeks?" is the most common question we get, and the honest answer is almost always: yes, a version of it. The disagreement is never about engineering speed. It's about what the word "it" is doing in that sentence.
The four things that always eat the budget
In nearly every over-running project we've inherited, the time went to the same four places — and none of them are the feature list.
1. Authentication and permissions
"Users can log in" is a day. "Users belong to organisations, can be invited, have roles, and admins can see a subset of other people's data" is two weeks, and it is what almost everyone actually means. Decide which one you need in week one, because retrofitting a permissions model into a shipped product is one of the genuinely expensive refactors.
2. The admin side
Every product needs a back office — someone has to refund the payment, fix the typo, unban the user. Teams routinely forget to scope it and then discover in week five that they can't operate the thing they built. Budget for it, or deliberately decide that for the first six weeks operations happen in the database with a senior engineer present.
3. Edge cases in the money path
Payments are easy to integrate and hard to finish. Failed cards, partial refunds, currency rounding, the webhook that arrives twice, the webhook that never arrives. The happy path is an afternoon. Everything else is a fortnight.
4. Email
Transactional email looks trivial until you count them: verification, password reset, invitation, receipt, notification digest — each needs a template, a plain-text fallback, deliverability setup and a way to test it. Ten emails is a week of work nobody put on the board.
What we cut instead
When six weeks is genuinely fixed, these are the first things we take out — and they're rarely missed in v1:
- Settings screens. Pick sensible defaults. Add preferences when a user asks.
- Onboarding flows. A five-step wizard is something you build once you know which step people get stuck on.
- Search. Filtering and sorting cover most cases. Real search is its own project.
- Native mobile apps. A responsive web app validates the idea.
- Anything with "dashboard" in the name. Analytics are what you build after you have data worth looking at.
The test we apply
For every feature in a six-week scope we ask one question: if this is missing on launch day, does the product still do its single most important job? If it does, the feature goes to the v2 list. Not deleted — listed, visibly, so nobody thinks it was forgotten.
The uncomfortable part is that this usually cuts 40–60% of an initial brief. The reassuring part is that in the projects we've shipped this way, most of that list never comes back. Real usage reorders priorities more ruthlessly than any planning session.