Why two weeks
Two weeks is long enough to talk to real users, argue about scope and produce something you can click. It is short enough that nobody falls in love with a plan before it has met reality. Every project we run — a fintech portal, a telehealth app, a brokerage platform — starts with the same fortnight, and it has saved more budgets than any technology choice we have ever made.
Week one: the problem, the people, the one job
The first week is almost entirely conversation. We interview the founder or product owner, then five to eight of the people who will actually use the product. We are listening for the moment they describe a workaround — the spreadsheet, the WhatsApp group, the sticky note — because that is where the product has to earn its place.
By Friday we can write one sentence: who uses it, what they get done, and how we will know it worked. If we cannot write that sentence, we are not ready to design anything, and we say so.
Week two: flows, prototype, plan
Week two turns the sentence into screens. We map the core flows — usually three or four, never twelve — and build a clickable prototype in Figma. Stakeholders test it on their own phones. Two or three users test it too, and the things they stumble on get fixed before they become code.
In parallel, engineering sizes the flows, chooses the stack and writes a build plan: sprints, milestones, integrations and the launch date. Not “Q4”. A date.
What you walk away with
- A one-page brief with the problem statement, the users and the success metric.
- A clickable prototype of the MVP’s core flows.
- A build plan with a fixed price for the MVP and a launch date.
- A list of everything we deliberately left out — and when it might come back.
What we deliberately leave out
Admin dashboards, settings screens, edge-case flows, the second user type, the integration “we will definitely need later”. Every one of these is real, and every one of them is cheaper to build once the core flow has met real users. An MVP is not a small version of the whole product; it is the smallest thing that proves the product should exist.
“The best thing about the discovery sprint was the list of what we weren’t building. It made every later conversation shorter.” — a founder we worked with this spring
When it is not the right fit
If you already have a validated product, a backlog and a team, you do not need our two weeks — you need a sprint plan. And if the idea is still a napkin sketch, a lighter one-week version is enough to decide whether to invest further. The point is never the ritual. The point is to know what you are building, for whom, and when it ships.
