Before you build

What is a software discovery phase and why does it come before code?

A discovery phase is the work you do before any code to turn a rough idea into a buildable plan. You leave with clear requirements, a proposed architecture, a scoped roadmap, and a test of your riskiest assumption. It is the cheapest place to find out you are about to build the wrong thing. Skipping it is the most expensive shortcut in software, because every wrong assumption gets baked into code and paid for later.

Book a thirty-minute call

Short answer

A discovery phase converts an idea into a clear scope, architecture, and roadmap, and tests your riskiest assumption before a line of production code is written.

Best for

  • Founders with an idea but no firm spec yet
  • Teams about to commit a real budget to a build
  • Products with one assumption that could sink the whole thing
  • Anyone who wants a fixed price they can trust
  • Stakeholders who need a plan to align on

Not for

  • A tiny change to an existing, well-understood system
  • Work where the scope is already fully defined and validated
  • Buyers who want code on day one regardless of risk
  • Throwaway experiments with no path to production
// 01

Compare the options

What changes when you run discovery first.

Dimension With discovery Without discovery
Scope

Defined and agreed before building.

Discovered mid-build, when changes are expensive.

Pricing

A fixed price can be quoted with confidence.

Estimates are guesses that drift upward.

Riskiest assumption

Tested early, while it is cheap to be wrong.

Tested in production, where being wrong is costly.

Architecture

Chosen deliberately for the real requirements.

Chosen on day one, then fought against later.

Stakeholder alignment

Everyone signs off on the same plan.

Disagreements surface after code exists.

Typical outcome

A build that matches the need.

Rework, scope creep, and surprise cost.

// 02

Where Wavect lands on this

Most software is not killed by bad code. It is killed by building the wrong thing well.

Discovery is where we find that out before it gets expensive. We pin down requirements, propose an architecture, scope a roadmap, and test the one assumption that, if wrong, would sink the project. A few weeks here routinely saves months later.

It also makes the rest of the engagement honest. With a clear scope on the table, we can quote a fixed price as a Werkvertrag and stand behind it. Without discovery, any fixed number is a guess. Discovery starts from EUR 3,500, and it is the cheapest insurance you will buy on the whole project.

// 03

Cost, risk and timeline

Cost From EUR 3,500A fraction of a full build, and the input that makes a fixed price possible.
Risk Front-loaded, on purposeYou find the wrong assumptions while they are still cheap to fix.
Timeline Weeks, not monthsShort and focused. It shortens the build that follows.
// 04

Where this usually goes wrong

  • Skipping discovery to save a few weeks, then losing months to rework.
  • Treating discovery as a document exercise instead of testing the riskiest assumption.
  • Choosing architecture on day one and fighting it for the rest of the build.
  • Letting stakeholders stay misaligned until code already exists.
  • Quoting a fixed price on an undiscovered scope, then watching it drift.
  • Building features nobody validated because the idea was never pressure-tested.
// 05

The checklist

A discovery phase should leave you with all of these.

  • Clear, written requirements you and the team agree on.
  • A proposed architecture chosen for your real needs, not defaults.
  • A scoped roadmap with sequence and rough effort.
  • A test of your riskiest assumption, run early.
  • A scope clear enough to quote a fixed price against.
  • Documented stakeholder alignment on what gets built.
  • An honest read on what is uncertain and what is not.
// 06

What this looks like in our work

Where a clear plan up front made a fast build possible.

// 07

When this fits, and when it does not

// 01

When Wavect is the right fit

  • You have an idea but not yet a spec you would bet a budget on.
  • You want a fixed price you can actually trust afterward.
  • You have a risky assumption that should be tested before code.
  • You want founders who challenge the plan, not just take the order.
// 02

When we are not the fit

  • Your scope is already fully defined and validated.
  • You are making a small change to a system you understand well.
  • You want code on day one and accept the risk that comes with it.
  • You see planning as overhead rather than insurance.

A few weeks of discovery is the cheapest way to find out you are building the right thing.

// 08
// 09

FAQs

No. Requirements are part of it, but the point is to test your riskiest assumption and propose an architecture, not just write things down. A document that no one pressure-tested is not discovery.
Weeks, not months. It is deliberately short and focused. The output is a plan clear enough to build and price against.
Discovery starts from EUR 3,500. It is a fraction of a full build, and it is what makes a trustworthy fixed price possible.
You can, but it is usually the most expensive shortcut available. Wrong assumptions get baked into code and paid for in rework. Discovery normally shortens the overall timeline rather than lengthening it.
The requirements, the proposed architecture, the roadmap, and the findings from testing your riskiest assumption. It is yours to take forward, with us or not.
Last reviewed: byKevin Riedl wiki ↗
Book a thirty-minute call