# What happens before anyone writes code

> The quiet first stage of a project decides most of its outcome. What discovery and definition involve, what you will be asked, and what you should have at the end.

By Odd Birds Studio · 27 Oct 2026 · Process · 2 min read

It is tempting to measure a project by how soon the first screen appears. But the most expensive mistakes are made before that — when a team starts building something nobody fully agreed on. The first stage exists to make those mistakes on paper, where they are cheap.

## Four stages, two before the build

1. **Discover**: Understand the business, the problem and what success looks like.
2. **Define**: Agree the features, architecture, technology and scope before code.
3. **Design**: Shape the flows and interface so the product is clear before it is built.
4. **Develop**: Build with maintainable technology, reviewing and demoing as we go.

This note is about the first two. They are short compared with the build, and they are where a project quietly succeeds or fails.

## Discover: the questions you will be asked

Discovery is mostly conversation. Expect questions that feel more like business than technology — because that is where the requirements actually come from.

- Who is this for, and what are they trying to get done?
- What happens today without this product — and what does that cost you?
- What does success look like six months after launch?
- What are the fixed constraints: budget, deadline, existing systems, regulations?
- Who decides, and who needs to be kept informed?

> **Bring the messy version**
>
> Spreadsheets, screenshots of tools you dislike, a voice note explaining how an order really moves through your team — these are more useful than a polished deck. Real workflows reveal the requirements nobody thinks to write down.

## Define: turning answers into a plan

Definition turns those conversations into decisions. The goal is a shared, written picture of what will be built first — and, just as important, what will not.

- A feature list split into must-have for launch and later.
- A technical outline: how the parts fit together and which technology fits the job.
- Scope and milestones you can hold the team to.
- The open questions that still need an answer, each with an owner.

> A good plan says no to things on purpose, instead of by accident later.

## Three traps worth avoiding

- Treating every feature as a must-have. If everything is essential, nothing can be scheduled — and the first release slips.
- Skipping the people who do the work. A manager describes how a process should run; the person doing it every day knows how it actually runs.
- Agreeing on words instead of examples. “Simple reporting” means something different to everyone until someone sketches the actual report.

Each of these is cheap to fix in a conversation and expensive to fix in code.

## How to prepare as a client

- Gather the documents, spreadsheets and tools you use today — especially the ugly ones.
- Name one person who can make decisions and answer questions quickly.
- Write down what must be true on launch day, and what can wait.
- Be open about budget and deadlines; they shape the plan more than any single feature.

## What you should walk away with

By the end of definition you should be able to explain the project to a colleague in two minutes, point at the first release on a list, and know what each milestone delivers. If you cannot, the plan is not finished yet — and it is far cheaper to keep talking than to start building.