# What is a software discovery phase, and what should you get from it?

*Web page: https://kweepa.com/insights/software-discovery-phase-explained · Published 2026-11-01 · Updated 2026-11-01 · 7 min read*

> The work that comes before building, and why it is the cheapest place to find out what is wrong with an idea. What you should hold in your hands when it ends.

**Who it is for:** anyone planning a new system

## What a discovery phase is

Discovery, also called product discovery, is the work done before a system is built: finding out what problem it solves, for whom, within which limits, and what to build first. It is the cheapest place to learn that an idea is wrong, or half right.

- **Requirements**: What the system must do, written so that a person who was not in the room can build and test it.
- **User journey**: The steps a kind of user takes to get something done, from the start to the result, including where they get stuck.
- **Wireframe**: A plain sketch of a screen: what is on it and where. No colour, no brand.
- **Prototype**: Screens you can click through, as if it worked, before anything is built behind them.

> **It is not a sales call** A call where a company asks what you want and sends a quote is not discovery. Discovery changes what is built.

## What you should be handed at the end

A discovery phase that ends in a feeling that you understand each other has not finished. It ends in documents and screens that you own.

**What a discovery phase should produce**

| Output | What it is | Why it matters |
|---|---|---|
| The problem and the goals | A short statement of what is wrong now and how you will know it is better. | Every later decision can be tested against it. |
| The people and their journeys | Who uses the system, what each of them does and where it hurts. | It stops the system being built around the person who commissioned it. |
| The scope, in phases | What goes in the first release, what comes next and what is left out. | You can start small and see it work. |
| A prototype | Clickable screens for the main journeys, tried with real users. | Mistakes are cheap to correct on a screen. |
| A technical outline | What it must connect to, where the data lives and the risks. | The estimate depends on it. |
| An estimate and a plan | A price or a range for each phase, with the assumptions behind it. | You can compare companies and choose. |
| A list of open questions | What nobody knows yet, and who will find out. | Unknowns written down are cheaper than unknowns discovered late. |

## How it runs

What to expect is the same whatever the size of the system. UX and UI design, the work of deciding how a system works and how it looks, is one part of a process with these steps.

### Step 1: Agree the goal and who decides

One person who can say yes, and a short statement of what success looks like.

### Step 2: Talk to the people who will use it

Staff, customers, managers. Watch the work if you can, not only hear about it.

### Step 3: Map how it is done today

Every step, including the workarounds. A system's real rules are often in the workarounds.

### Step 4: Sketch and then prototype

Wireframes first, then clickable screens for the journeys that matter most.

### Step 5: Try it with real users

Put the prototype in front of the people who will use it and watch where they hesitate.

### Step 6: Decide the order and estimate

Choose what comes first, and price it, with the assumptions written beside the price.

## What to bring, and how to write a brief

You do not need technical words. Use this list as a template for your brief: you need answers to these.

- **The problem:** what is slow, wrong or impossible today, and who feels it.
- **The people:** who will use it, how many, and what each of them does.
- **The connections:** the systems, payments and records it must work with.
- **What must never go wrong:** money, personal data, double bookings, lost records.
- **What exists:** forms, spreadsheets, screenshots and reports that show how the work is done now.
- **The limits:** a date it must be ready by, a budget you cannot pass, rules you must follow.
- **Access:** people you can talk to, and someone who can decide.

## Is it worth it?

Discovery costs money and time, and it is not always needed.

- **It is worth it** when the system is large, when several kinds of people use it, when it touches money or personal data, or when you cannot yet describe what it should do.
- **It may not be** when you are changing a small thing in a system that already exists, or when a product you can buy already does the job.
- **Agree its end and its price before it starts,** and what you will be handed. You should be free to take the results to another company.

## Red flags

Any one of these is a reason to ask more questions.

- It is free, and ends with a quote that is hard to compare.
- No one talks to the people who will use the system.
- It produces a long document and no screens.
- You cannot keep what it produced unless you hire the same company.
- It has no end date.

> **A prototype that nobody has tried is a guess** Ask when real users will see it, and what will change if they stumble.

## Keep reading

- [Discovery and UX/UI design](https://kweepa.com/services/discovery-and-design): What to build, and how it should work, found out and designed before any code is written.
- [How much does custom software or an app cost in Kenya?](https://kweepa.com/insights/software-development-cost-kenya): What decides the price of custom software and apps in Kenya, three ways projects are priced, and how to get quotes you can compare. No made-up figures.
- [How to choose a software company in Nakuru, Kenya](https://kweepa.com/insights/choose-software-company-nakuru): How to choose a software development company in Nakuru or anywhere in Kenya: what to check, contract terms, questions to ask and red flags.
- [Talk to us about your project](https://kweepa.com/contact?service=discovery-and-design)

## Questions people ask

### What is a discovery phase in software development?

A discovery phase is the work done before a system is built. It finds out the problem, the people who will use the system, the limits and the risks, decides what to build first and ends with a scope, a prototype and an estimate.

### What should I get at the end of a discovery phase?

A statement of the problem and the goals, the users and their journeys, a scope in phases, a clickable prototype tried with real users, a technical outline, an estimate with its assumptions and a list of open questions.

### How do I write a brief for a software company?

Write in plain sentences: the problem, the people who will use it, what it must connect to, what must never go wrong, what exists today and the limits of time and money. Add forms and screenshots of how the work is done now.

### What is the difference between a wireframe and a prototype?

A wireframe is a plain sketch of a screen that shows what is on it and where. A prototype is a set of screens you can click through as if it worked, so that users can try it before anything is built.

### Is a discovery phase worth it?

It is worth it for a large system, one with several kinds of users, or one that touches money or personal data, or when you cannot yet say what it should do. It may not be for a small change to a system that exists.

### Who owns the documents from a discovery phase?

Agree it before you start. You should own what it produces and be free to take it to another company. Ask for that in writing.

### What happens in a discovery workshop?

The people who will use the system and the people who decide meet the team, map how the work is done now, mark where it hurts and agree what the first release should do.

## Next step

Talk to us: https://kweepa.com/contact?service=discovery-and-design · Email: ops@kweepa.com
Publisher: Kweepa Technologies, Nakuru, Kenya (https://kweepa.com/)