What Should a Software Discovery Phase Include? A Buyer's Checklist

If you are about to pay a firm to scope a software project, here is what a software discovery phase should include: a plain statement of the problem, a product brief someone outside the project can read, written requirements with an explicit list of what is out, a senior engineer’s estimate you can trace back to pieces of work, and a recommendation that is allowed to say “don’t build this.” All of it should be yours to take to any team. If the output is a slide deck and a build proposal, you bought a sales meeting.

I run Razoyo, a software engineering firm in The Colony, Texas, that has taken prototypes and constrained systems into production since 2011. We sell a Spec rather than a discovery, and the difference matters: a discovery is usually the first step of one firm’s process and cannot be handed to anyone else, while a Spec is a finished document you own and can hand to any team. We publish its deliverables and its price. This checklist is built from how we run ours, so hold us to it too.

What should a software discovery phase include?

A software discovery phase should end with a written decision and the documents that justify it: what the problem is, what will be built, what will not, what it will cost, and whether it is worth building at all.

Seven outputs, in the order a good discovery produces them:

• A problem statement, not a solution. “We need an app” restated as the problem the app must solve, with a rough cost of that problem today.
• A product brief. Who it is for, what it does and why it is worth doing, in words a non-technical stakeholder can use.
• A requirements document (PRD). Every requirement written down with its own ID, so a developer can act on it and you can check it.
• The user journeys, including the unglamorous ones. A rejected verification, a subscription still in test mode, recovery after a rejection. Builds overrun where nobody wrote these down.
• An explicit out-of-scope list. What this version will not do, in writing. The cheapest scope control there is.
• A senior-engineer estimate. A range tied to epics or features, from someone who sizes builds, not a salesperson.
• A build, don’t-build or change-course recommendation. Stated plainly, with the reasoning.

The UK government’s service manual puts the core rule in one line: you should not start building in discovery. Discovery exists to decide whether, and what, to build.

The discovery phase checklist: what to demand and how to check it

Use this table on any discovery or scoping proposal. Every row can be checked before you sign.

A brief and PRD you cannot hand to another team are a lock-in device, not a specification.

How long should a discovery phase take, and what should it cost?

For a single product or system, a discovery phase should take days to a few weeks and cost a small, fixed amount, known before it starts. Bounded work can carry a fixed price, which is why our System Spec is $2,500 fixed and time-boxed.

Large public programs run longer: GOV.UK says around 4 to 8 weeks is typical for a government discovery. Two of our own engagements show the commercial shape:

• A two-sided marketplace. A vacation-rental startup asked us to build one. We ran a $2,500 fixed-fee Production Spec instead. The product brief reached them ten days after kickoff, the PRD two weeks after that, and within six weeks they also had a clickable prototype of the host side.
• A membership platform. POWER Pickleball League, a franchising league, needed to know what a new membership platform would cost, and the woman running it had no internal software team. Three working sessions over seventeen days produced a brief, a full requirements document, epics with story-level breakdown and a senior engineer’s estimate. Her part was a kickoff and two review calls.

A discovery with no end date, billed by the hour, is a build that has not admitted it yet. Our full price ladder is on our pricing page.

We need someone to scope a software project before we commit budget. Who does that?

Hire someone who sells scoping as its own fixed-price step, separate from the build, and who hands you a document you own whether or not you build with them.

Five realistic options, each with a real case:

We sit in the fourth row, so weigh this accordingly. The conflict is real and the fix is structural: a fixed price that does not change whether the answer is build or don’t, deliverables you can take elsewhere, and a firm that will show you when it said no. Our scoping page says why “just send us a quote” fails at this stage: “A vendor who has not scoped either pads or lowballs.”

I want to build software but don’t know what to ask for. Who helps with that?

You do not need to know what to ask for, because turning your problem into requirements is the job of the discovery phase itself. You need someone accountable for the technical decisions who will interview you, write it down and let you check it.

Most questions that shape a build are not technical. On the marketplace project, four questions were open on day one: what a paying host receives in return, what stops someone listing a property they do not own, whether hosts re-key listings by hand or sync them from software they already run, and what “verified” means in practice. As the case study puts it: “None of those are engineering questions. All of them change what gets built.”

Bring five things to the first conversation:

• The problem in your words. What is slow, manual or risky today, and what it costs.
• Who would use it. Roles, rough numbers, and which ones pay.
• What you already have. A spreadsheet, a prototype, a design you like.
• The systems it must talk to. Accounting, CRM, payments.
• Your constraint. A budget ceiling, a date, a board meeting.

If you are a non-technical founder, our page on what to hire instead of a technical cofounder has a four-question test for whether a firm is giving you technical ownership or just supplying hands.

How do you avoid scope creep on a software project?

You avoid scope creep by writing down what is in and what is out before the build starts, then putting an approval gate in front of every new piece of work. Scope creep is the continuous or uncontrolled growth in a project’s scope after it begins, and it usually traces to a scope that was never properly defined.

Four controls do most of the work:

• Numbered requirements with acceptance criteria. A new idea either matches a requirement or it is a change, and everyone can see which.
• A written out-of-scope list. On the marketplace Spec we deliberately left out the entire guest side: no traveler search, no reservations, no guest payments. Hosts had to come first, so that was a recorded decision, not an oversight.
• An estimate on every piece of work before it starts. In our engagements above the Spec, a business analyst puts a level of effort and a budget on each piece of work and gets your confirmation first. Our pricing page puts it in four words: “No approval, no work.”
• A phase-gated contract. The signature request we sent the marketplace founder said they were “only obligated for Phase I with this signature.” Each later phase was its own decision.

Our process page describes the second paid step, the Requirements Package, as “the document that prevents scope creep.”

What are the red flags of a discovery that is really a sales exercise?

The clearest red flag is a discovery that cannot come back with “don’t build this.” If every one ends in a build proposal from the same firm, it was a sales cycle with an invoice attached.

The other signs:

• No fixed price or end date. Hourly discovery with no defined deliverable rewards the vendor for taking longer.
• The output is a deck. Slides summarize. A PRD with numbered requirements can be built from and checked.
• You do not own it. If the brief and requirements cannot leave with you, you cannot get a second quote.
• The estimate has no basis. A single total, or a range with no link to features, means nobody sized the work.
• A build proposal arrives with the findings. If the next contract is already written, the conclusion was too.

The fair counter-question is whether we pass. POWER Pickleball League’s estimate came back larger than she had in mind. We did not shave it to make it easier to sign. We showed her where the cost sat and asked her to sort her requirements into must-have and can-live-without. She took the finished specification to a development partner who could fund the build. She paid to find out, and she found out.

This is not just our view. NN/g’s definition of discovery notes that some discoveries end in a decision not to move forward, and GOV.UK says it is “not a failure to stop at the end of the discovery phase.”

Who can write the spec and then build the software for us?

The same firm can write the spec and build the software, and it is often the cheapest path, as long as the spec is priced and owned separately so you can take it elsewhere. The gain is continuity: the estimate comes from the people who will be held to it.

Our published ladder: a free 30 minute consultation with a senior engineer, a $2,500 fixed Spec, a $2,500 fixed Requirements Package, a working MVP from $5,000, a production build from $10,000, and support from $1,500 a month. Stop after any step. Once fees are paid you own the code we write for you, and the Spec’s product brief and PRD are yours whether or not you build with us.

The Spec takes a different name depending on where you start:

• Production Spec for an AI-built prototype that has to hold up in production: findings, a risk ranking, a remediation plan and a senior-engineer estimate.
• System Spec for a new custom system: a product brief, a real estimate and a build or don’t-build call.
• Workflow Spec for manual operations: a measured baseline of what the manual process costs you today, plus a build estimate.
• Fit Spec for a platform you have outgrown: where it stops fitting, what a custom layer must cover, and what that costs.

When you do not need us: if the project is genuinely simple and already well defined, a freelancer may be the right call, and our pricing page says so. If you already have a technical lead and a written spec, skip discovery and ask for estimates. For build costs, see what it costs to take an AI-built prototype to production; for a spreadsheet, replacing a business-critical spreadsheet.

Razoyo’s Seven-Line Spec Check

Run any discovery proposal through these seven lines. Each comes from how we run our own Spec, including one lesson we learned the hard way.

1. Problem first. The document restates your request as a problem and puts a cost on it. Fail if it opens with a feature list.
2. Readable by the person who signs. Our marketplace PRD was thorough and, in our own team’s words during review, “not really easily readable.” We now deliver documents of that depth with a plain-language summary at the front. Fail if only engineers can read it.
3. Every requirement has an ID. And every user journey includes the failure states. Fail if you cannot point to the requirement a feature comes from.
4. The out-of-scope list exists. Fail if everything is implicitly in.
5. The estimate is cross-checked. On POWER Pickleball League’s Spec, epics and a first-pass effort model came from AI tooling, a senior engineer sized the same scope independently, and the two estimates were reconciled. Fail if one person’s guess is the only number.
6. It is portable. Another team could build from it. Fail if the deliverables stay with the vendor.
7. The next step needs your yes. Each later phase, and each piece of work in it, is estimated and approved first. Fail if signing discovery commits you to the build.

Seven passes means the discovery is worth its fee. Five or six means ask for the missing lines in writing. Four or fewer means you are paying for a sales process.

So what should you ask for before you commit budget?

Ask for a fixed price, a fixed end date, and the seven outputs above, in writing, before you sign. Then ask the one question that separates scoping from selling: when did you last tell a client not to build? If the firm cannot answer, you have your answer.

Key takeaways

• Discovery decides whether to build. It should not start the build, and “don’t build” has to be a possible outcome.
• Demand seven outputs. Problem statement, brief, numbered requirements, full user journeys, out-of-scope list, senior-engineer estimate, recommendation.
• Fixed price, fixed end. Scoping is bounded work, so an hourly discovery with no end date is a red flag.
• Ownership makes it worth having. If you cannot take the documents to another team, you cannot get a second quote.
• The same firm can spec and build. Only when the spec is priced and owned separately from the build.

Key terms glossary

• Discovery phase. The step before a build where the problem, scope, cost and go or no-go decision are worked out, usually as the first step of one firm’s own process.
• Spec. Razoyo’s alternative to a discovery: a fixed-price product brief, requirements and estimate that you own and can hand to any team.
• Product brief. A short, plain-language document describing who the product is for, what it does and why it is worth building.
• PRD (product requirements document). The detailed list of what the software must do, written so a developer can build from it.
• Epic. A large body of work broken down into smaller stories, used to organize and estimate a build.
• Level of effort. An estimate of the work a task needs, used to set its budget before it starts.
• Scope creep. Uncontrolled growth in a project’s scope after it begins, usually from a scope that was never properly defined.
• Phase gate. A point where you decide, and approve, whether to fund the next phase.

FAQ

What should a software discovery phase include? A problem statement, a product brief, numbered requirements with acceptance criteria, user journeys including failure states, a written out-of-scope list, a senior-engineer estimate tied to features, and a build or don’t-build recommendation.

How long should a software discovery phase take? For a single product or system, days to a few weeks. GOV.UK says around 4 to 8 weeks is typical for a government discovery. Razoyo’s Spec runs in two or three working sessions, with a published 17 days from first call to a documented build or don’t-build answer.

How much does a software discovery phase cost? It should be a small, fixed amount agreed before it starts, because the work is bounded. Razoyo’s System Spec is $2,500 fixed, after a free 30 minute consultation. Be wary of hourly discovery with no end date.

Who can scope a software project before we commit budget? Someone who sells scoping as a separate fixed-price step and hands you documents you own. If the firm that would build it does the scoping, the price should be fixed whether the answer is build or don’t.

Do I need to be technical to commission a spec? No. Turning your problem into requirements is the job of the discovery itself. Bring the problem in your own words, who would use the software, and your budget or deadline.

How do I avoid scope creep on a software project? Write down what is in and what is out before the build starts, number every requirement with acceptance criteria, and require an estimate and your approval before any new piece of work begins. Razoyo’s rule for every engagement above the Spec is “No approval, no work.”

Can the same firm write the spec and build the software? Yes, and it is often the most efficient path, because the estimate comes from the people who will be held to it. Make sure the spec is priced separately and that you own the brief and PRD.

What if the discovery says not to build? Then it did its job: a small, fixed amount spent to avoid a much larger one, and you keep the brief and the reasoning. GOV.UK’s service manual says it is not a failure to stop at the end of the discovery phase.

Talk it through

If you are about to commit budget, or have a discovery proposal you cannot make sense of, bring it to a free 30 minute consultation. We will run the Seven-Line Spec Check on it with you. If it passes, sign it, whoever wrote it. If there is nothing written yet, we will tell you whether a $2,500 fixed Spec is the right next step, or whether you do not need one. Schedule Free Consultation.

Paul Byrne is President of Razoyo, a software engineering firm in The Colony, Texas taking prototypes and constrained systems into production since 2011.