What happens in a discovery phase, and why it saves money

Most software projects that run over budget don't fail in development. They fail before it starts, when a team begins building from a one-page brief and fills the gaps with guesses. A discovery phase is a short, focused stretch of work, usually one to four weeks, that replaces those guesses with decisions.

What you get out of it

A good discovery phase ends with things you can hold, not just a slide deck:

• A clear scope: what is in the first release, and what is deliberately left for later
• User flows and a clickable prototype: so you can see and test the product before anyone writes production code
• A technical plan: architecture, key integrations and the risks that could slow the build down
• A realistic estimate and timeline: based on the agreed scope, not on a guess

What happens during it

1. Understand the business

We start with why the product exists: who uses it, what problem it solves and how you'll know it's working. This is where vague goals become measurable ones, such as "cut support response time" or "take bookings without phone calls".

2. Map the users and their journeys

We walk through what each type of user needs to do, step by step. Gaps show up quickly here: who approves a refund, what happens when a payment fails, what an admin needs to see.

3. Check the technical ground

Existing systems, data and integrations often decide how hard a project really is. We check APIs, data quality and hosting constraints early, while changing course is still cheap.

4. Prototype and test

A clickable prototype lets you and a few real users try the main flows. It's much cheaper to move a button in a prototype than to rebuild a finished screen.

5. Prioritise and estimate

With the full picture, we split features into "must have for launch" and "next". The estimate covers the first release, with clear assumptions written down.

Why it saves money

• Fewer surprises. Most expensive changes come from requirements nobody wrote down. Discovery finds them early.
• A smaller first release. Prioritising often shows that a leaner launch can go live sooner and start earning or saving money.
• Better estimates. An estimate built on a prototype and a technical plan is far more reliable than one built on a brief.
• A low-risk way to test a partner. You see how a team thinks and communicates before committing to the full build.

Is it always needed?

Not always. If you're adding one well-defined feature to a system the team already knows, a short planning session is enough. Discovery earns its cost on new products, large rebuilds and projects with several systems or many types of users.

---

Have an idea that needs shaping? Tell us what you're building and we'll suggest how much discovery it needs.