Articles · Hiring

2027-02-25 11 min EN / FR

What a discovery workshop is, and why it saves money

Most budget overruns on software projects do not come from bad developers. They come from starting to build before anyone has clearly understood the problem. A discovery workshop is a short, paid, structured phase that happens before the build. Its output is a clear picture of what to build, what it will cost and what could go wrong.

It can feel like paying to not get anything yet. In practice it is often the cheapest part of the project, because it prevents the most expensive mistakes.

What it is

A discovery workshop (also called scoping, framing or a discovery phase) is a short engagement, typically one to a few days of work spread over one or two weeks, where the provider and the client:

  • Map the current situation, processes and pain points
  • Identify the real problem behind the request
  • Review existing systems, data and constraints
  • Define scope and priorities
  • Identify risks and unknowns
  • Produce a document that the build can be based on

It is not a free sales meeting, and it is not the start of the build. It is a piece of work with its own deliverable, and you should be free to take that deliverable elsewhere.

Why it saves money

It finds the real problem. The request is often a solution ("we need an app") rather than a problem ("our technicians lose two hours a day re-entering reports"). The cheapest fix is sometimes not the one first proposed.

It exposes hidden complexity. Business rules, exceptions, legacy data, integrations with systems nobody documented. Finding these on day two costs a conversation. Finding them in month three costs a redesign.

It turns vague quotes into reliable ones. Providers add large margins to price uncertainty. Once the unknowns are reduced, a fixed price becomes realistic and lower.

It makes quotes comparable. With a written specification, you can ask several providers to price the same thing (see reading a quote: what's missing).

It aligns people. Disagreements inside your own company surface early: sales wants one thing, operations another. It is much cheaper to settle this on paper.

It lets you decide not to proceed. Sometimes the answer is "this isn't worth building", or "a simpler tool will do". That is a good result, and it saved you the budget.

When it's worth it

  • The project costs more than a few thousand euros
  • Several systems or teams are involved
  • The process is complex or poorly documented
  • You're replacing an existing system and migrating data
  • You can't clearly describe the end result yet
  • Previous projects went over budget or missed the mark

When it's not

  • A small, well-defined task (a landing page, a simple integration, a bug fix)
  • You already have a precise specification from a previous phase
  • The cost of discovery would be a large share of the whole project

For small work, a 30-minute call and a written summary of the scope is usually enough.

Before: preparation

  • A short questionnaire or brief from you (see how to brief a developer)
  • Access to existing documents, screenshots, sample data and the tools involved
  • A list of the people who should attend: decision-maker, daily users, whoever manages the current systems

Need a clear scope before you build?

We run paid discovery workshops that produce a specification you can keep, share or take elsewhere.

Describe your project Custom solutions

During: sessions

Typical topics, in order:

  • Goals and context. What are we trying to achieve, and how will we measure it?
  • Current process. Walk through how work really happens, with the people who do it. Ask about exceptions: "what happens when it doesn't go as planned?"
  • Systems and data. What exists, where, in what state, and who owns it? Includes accounts and access (see who really owns your accounts).
  • Pain points and priorities. Sorting needs into must, should and nice to have.
  • Constraints. Budget, deadline, regulation, hosting, internal skills.
  • Options. Standard tool, configured platform, custom build, or a mix (see Odoo or custom software).
  • Risks and unknowns. What could go wrong, and what needs a test before committing?

Good workshops involve real examples: actual orders, actual spreadsheets, actual emails. Abstract descriptions hide the details that matter.

After: deliverables

You should receive a written document, usually 10 to 30 pages, containing:

  • Problem statement and goals, with success criteria
  • Current process map and pain points
  • Scope: prioritised list of features, with what's out of scope
  • Recommended approach and the alternatives considered, with reasons
  • High-level architecture: the main components and how they connect
  • Integrations and data: what connects to what, migration approach and data quality issues
  • Risks and open questions, with proposals to resolve them
  • Phased plan: what to build first, and why
  • Estimate: a range or fixed prices per phase, with assumptions and exclusions
  • Ownership and hosting recommendations: accounts in your name, who runs what (see the exit plan to require and contract clauses to demand)

Optionally: wireframes or a clickable mockup, a small technical test (a proof of concept for a risky integration), or a prioritised backlog ready for the build.

How to judge a good discovery

  • Questions outnumber answers. If the provider just nods and agrees, they aren't discovering.
  • They challenge your assumptions, politely, and suggest simpler alternatives where they exist.
  • They talk to the people who do the work, not only managers.
  • They put unknowns in writing, instead of hiding them behind a confident price.
  • The deliverable stands on its own. You could hand it to another provider and they could price it.
  • They're willing to say "don't build this" or "build less".

Red flags

  • It's "free", and then the proposal arrives immediately, with a price and no document
  • The deliverable is a slide deck of generalities
  • No contact with end users
  • The estimate is a single number with no assumptions
  • The provider refuses to let you use the specification with others
  • The workshop is a disguised sales pitch for a pre-chosen solution

A free discovery isn't always bad, but ask what you will actually receive, and whether you're free to leave with it.

What it costs

Cost depends on the size and complexity of the project and on the provider's rates. As a rule of thumb, discovery typically represents a small percentage of the overall project budget, often in the range of a few percent up to around ten percent for large projects. Ask for a fixed price for the workshop and a clear description of the deliverables.

Many providers credit part or all of the fee against the build if you continue with them. That is a fair arrangement, as long as you aren't forced to continue.

How to prepare, as a client

  • Name a decision-maker who will attend and who has the authority to prioritise.
  • Gather material: current documents, screenshots, spreadsheets, sample data, existing contracts and logins for tools.
  • List the people who use the current process daily, and make them available.
  • Write down your doubts. What worries you? What failed before?
  • Be honest about budget and deadline. It lets the provider recommend something that fits.
  • Keep an open mind. The best outcome is sometimes a smaller project than you expected.

After the workshop: three possible decisions

  • Go ahead with the same provider, phase one first.
  • Take the specification to other providers for competitive quotes.
  • Stop or reduce. You've spent a small sum and avoided a larger mistake.

All three are legitimate. Make sure the contract for the workshop allows any of them.

Common mistakes

  • Skipping discovery on a complex project to "save money"
  • Treating it as a formality, with no real users involved
  • Sending only managers, who know the official process but not the real one
  • Not preparing material
  • Expecting a fixed final price without discussing assumptions
  • Not reading the deliverable carefully before signing the build contract
  • Keeping the specification locked with one provider

Checklist

  • Project size and complexity justify a discovery phase
  • Workshop is paid, with a fixed price and defined deliverables
  • Decision-maker and daily users attend
  • Current documents, data samples and tool access prepared
  • Deliverable includes scope, risks, approach, plan and estimate
  • You are free to use the specification with other providers
  • Fee credit against the build, if any, is stated in writing
  • You've reviewed the document and challenged what's unclear

Related

From a vague idea to a scope you can price

If you have a project that needs clarifying before the build, write us. Discovery first, then a quote you can trust.

Start a conversation All articles