Design & Product
Product Discovery & Prototyping
Validate ideas before you build them
The most expensive software is the software that gets built, launched and then not used. Discovery exists to find that out in weeks instead of quarters — while the only thing you have committed is a small, fixed fee, and while changing your mind still costs nothing.
This is the engagement we recommend to anyone whose idea has not yet been tested on a real user, and it is deliberately structured so that "do not build this" is one of the outcomes it can produce.
What's included
What a discovery sprint produces
A written problem statement
who has the problem, how they solve it today, and what it costs them. If we cannot write that down clearly, nothing else is worth doing.
A prototype
clickable, realistic enough that people react to the product rather than to a description of it, and built to be thrown away.
Evidence from real users.
The prototype tested with people from your actual audience, attempting real tasks, with what they did recorded rather than what they said they would do.
A scope, prioritised.
What belongs in a first release, what waits, and what the research says can be dropped altogether — usually a surprising amount.
A technical assessment.
Architecture, the integrations required, the risks and the constraints, from engineers rather than from a sales estimate.
A costed plan.
Phased, with a price per phase, so you can approve one phase rather than the whole thing.
A recommendation.
Build it, build a smaller version of it, fix the process instead, buy something existing, or stop. In writing, with the reasoning.
Why this saves money rather than costing it
A discovery sprint is a small fraction of a build. It regularly changes the shape of the project enough to pay for itself several times over, in ways that are easy to see afterwards and impossible to see in advance:
- Features that seemed essential turn out not to be, and come out of the first release.
- The real bottleneck turns out to be a process or a data problem, and no software was required for the biggest part of it.
- The technical approach changes once the integration constraints are actually examined.
- An existing product is found that does eighty per cent of it for a subscription fee.
- Occasionally, the idea does not survive contact with users — which is a good outcome discovered at the cheapest possible moment.
How it runs
- Kick-off. Two days with the people who own the problem: the business goal, the constraints, the users, the systems already in place, and what success would look like as a number.
- Research. Interviews with real or representative users, a look at competing and adjacent products, and a review of whatever data you already have.
- Concepting. Flows and structure explored quickly and cheaply, with the options put in front of you rather than one answer presented as inevitable.
- Prototype. Built fast, focused on the two or three journeys that carry the risk.
- Testing. Sessions with real users, and a summary of what actually happened — including the parts that did not work.
- Readout. A written report and a presentation: findings, scope, plan, cost and recommendation, delivered to you and yours to keep.
Where prototyping is worth insisting on
- A new product with no existing users to learn from.
- A large internal system where adoption is the main risk, not the technology.
- A complex flow — onboarding, applications, configurators, checkouts — where each extra step measurably loses people.
- A rebuild of something people already use, where the risk is removing a behaviour they depend on.
- Any project where two stakeholders describe the goal differently. Better to find that on day two than in month four.
On working with Codigoo
The first thing they did was tell us to stop two campaigns we were proud of. That is when I knew they were reading the numbers and not the brief.
Questions we are usually asked
- Can we skip discovery — we know what we want?
You can, and sometimes it is genuinely the right call: a small, well-understood build with a clear precedent does not need it. But when the scope is large or the users are not you, discovery is the cheapest risk reduction available. We will tell you if we think you do not need it, because selling an unnecessary phase is a bad way to start a relationship.
- Do we own what comes out of it?
Entirely — the research, the prototype, the scope and the plan. It is written to be usable by any development team, not just by us, and clients do sometimes take it elsewhere. We would rather that than have you commit to a build you were not ready for.
- Is the prototype the start of the real product?
No, and it should not be. A prototype is built for speed and disposal; production code is built for reliability and change. Reusing throwaway prototype code as a foundation is one of the most common causes of a codebase nobody can maintain a year later.
- What if discovery says don't build it?
Then it has done its job, and it has cost you a fraction of a build to learn it. That answer does happen, and you will get it plainly.
If you have an idea you have not yet put in front of a user, this is the least risky way to find out whether it holds.
Talk to us about Product Discovery & Prototyping
Thirty minutes with an engineer and a strategist who do this work — not a sales team. You will get an honest answer about whether it is the right thing to buy, and what it would realistically cost.