Discovery Sprint
A clear scope and a written quote before any build money is spent.
- How long2 weeks
- How we workFixed package
What you receive
In two weeks you go from an idea to a scope you can trust, a prototype you can click and a price you can plan around.
Are we solving a problem people actually have?
You receiveInterviews with the people who will use it
You hear the problem in their words before you spend on a solution.
What it is. We talk to five to eight people who would use it, such as your customers or your staff, for about 45 minutes each. We ask what they do today, where it hurts and what they have already tried.
Why it matters. You hear the problem in their words before you spend on a solution. It is the cheapest way to avoid building the wrong thing.
How will we know if it worked?
You receiveProblem statement and success measures
Everyone agrees what "done" means before work starts.
What it is. One page that names the problem, who has it and what it costs today, with three to five measures that will show it is solved, such as hours saved, orders completed or calls answered.
Why it matters. Everyone agrees what "done" means before work starts. The result is then judged on numbers, not opinions.
What will people actually do, step by step?
You receiveUser journeys
You see where the product must be simple and what can wait.
What it is. Maps of the main paths people take, from the first visit to the job done, with the points where they get stuck marked on them.
Why it matters. You see where the product must be simple and what can wait. That keeps the first version small and the cost down.
Will people understand it?
You receiveA clickable prototype of the riskiest flow
You can see and use the product before any code exists.
What it is. A realistic, clickable mock-up of the one flow most likely to go wrong, tried with a few real users while we watch.
Why it matters. You can see and use the product before any code exists. Changing a screen now costs far less than changing software later.
Will it hold up, and what will it cost to run?
You receiveArchitecture and hosting outline
No surprises later about speed, security or hosting bills.
What it is. A diagram of the main parts, what each one does, where it is hosted and how it connects to the systems you already use, with an estimate of the monthly running cost.
Why it matters. No surprises later about speed, security or hosting bills. Any competent team can build from it.
What could go wrong?
You receiveRisks and how to reduce them
Problems are cheapest to solve before they happen.
What it is. A ranked list of the risks we found in the technology, the law, the data and the team. Each one comes with a way to reduce it and the person responsible for it.
Why it matters. Problems are cheapest to solve before they happen. You decide which risks to accept, with your eyes open.
What do we build first?
You receiveA prioritised backlog
The first release stays focused on what matters most.
What it is. Every feature written as a short story from the user's side, sorted into must have, should have and later.
Why it matters. The first release stays focused on what matters most. You can see exactly what has been left out, and why.
When will I have something I can use?
You receiveA phased roadmap
You can plan launches, budgets and hiring around real dates.
What it is. The work split into phases of a few weeks each, with what you will be able to use at the end of every one.
Why it matters. You can plan launches, budgets and hiring around real dates. Each phase ends in something people can use.
What will it cost?
You receiveA written quote for the build
You decide with real numbers.
What it is. An itemised quote for the first phase: what it covers, what it does not, how long it takes, the price and the date it is good until.
Why it matters. You decide with real numbers. You can also take the brief to anyone else and compare like for like.
What if I choose someone else to build it?
You receiveEverything yours to keep, whoever builds it
Discovery is never a trap.
What it is. Every document, diagram and prototype, and the backlog, handed over in files you own.
Why it matters. Discovery is never a trap. Whoever builds next starts from a clear brief, and nothing you paid for is lost.
From brief to done
- 1
Day 1
Kick-off
Two hours together on the goal, the people and the systems. We agree who to interview.
- 2
Days 2 to 5
Listen and map
Interviews, then the problem statement and the journeys. You see the findings as they come in.
- 3
Days 6 to 8
Sketch and test
The clickable prototype, tried with real users. The architecture takes shape alongside.
- 4
Days 9 and 10
Decide
Risks, backlog, roadmap and the quote, walked through with you in a final session.
Is this idea worth building, and where do we start?
Idea to first step. A one-page brief for your idea: the problem, who it is for, the smallest useful first release and the risks.
- A 30-minute call about the idea and the people it is for
- A one-page brief you can share with a co-founder, a board or another supplier
- It is free. There is nothing to pay and nothing to sign.
- The report is yours to keep and share, whatever you decide.
- No sales call unless you ask for one.
Questions people ask
How much does it cost?
We send a written quote after your request: what it covers and what it does not. The tier, scope and timing set the price.
Could I just use AI for this?
AI drafts code and prototypes quickly, and we use it every day. It cannot decide what to build, prove that it is secure, or answer for it when real people rely on it. That is the part you are hiring us for.
Who owns the work?
You do. Code, designs, files and documents are yours, and the quote says so in writing.
Can we change the scope?
Yes. If something needs adding or removing, we agree it in writing before we do it.
What happens after?
Most people go on to MVP Build, but there is no obligation. You keep everything we made.