Software Discovery and Requirements

A real scope and a real price before you commit to the build.

This is the Discovery + Roadmap phase already shown in our software journey: a paid, fixed-scope engagement that turns an agreed product direction into architecture, milestones and a fixed-price build offer.

THE OFFER IN ONE SENTENCE

Discovery + Roadmap is Wavect’s existing paid planning phase for a software build. You leave with architecture, a milestone plan and a fixed-price build offer; the discovery fee is deducted in full if you continue with the build.

A useful starting point

  • You have an agreed product direction but the build scope is unresolved.
  • You need stakeholders to agree priorities and implementation constraints.

A different next step

  • Demand is still untested and you first need product validation.
  • Your accepted specification is already ready for an implementation quote.
// 01

The Discovery phase in our journey, explained properly

Discovery + Roadmap is the same offer you see in the software development journey and MVP pricing . The live offer card above shows its fixed fee, published duration and build credit from that existing pricing source. There is no second discovery package to choose between.

Use it when the product direction is sufficiently clear to plan delivery, but assumptions about users, workflows, integrations or architecture still prevent a credible build quote. We turn those open questions into explicit decisions. If you still need to establish whether people want the product, Fractional Co-Founder is the earlier validation conversation.

// 02

What the roadmap has to make clear

The core outputs are architecture, milestones and a fixed-price build offer. The working detail below explains how those outputs support a build decision. Agree the depth and any additional research in the signed scope, rather than treating every possible artifact as a separate guaranteed deliverable.

A release boundary

Identify the user, the job they need to complete and the smallest release that completes it. Record what is excluded, which dependencies can block it and who accepts the outcome.

An architecture with reasons

Map the application boundary, data ownership, integrations, access model and deployment responsibilities. Explain the tradeoffs and the assumptions that would change a technology choice.

A milestone plan

Order work around demonstrable outcomes. Name acceptance decisions, customer inputs and dependencies so a milestone can be reviewed as working behavior instead of a percentage complete.

A build offer you can assess

Tie the fixed-price offer to the agreed scope. Keep unknowns and exclusions visible, and explain how a change to requirements is evaluated before additional work is commissioned.

// 03

Bring decisions and constraints. You do not need a finished spec.

Bring the business goal, primary users, current workflow and the people who can choose between competing priorities. Existing sketches, a prototype and earlier specifications are useful inputs, even when they are incomplete. For inherited software, bring a description of the current system and the people who understand its constraints.

List integrations, required access, data sensitivity, hosting constraints and any genuine deadline. Show which assumptions are facts and which are still guesses. Use representative or synthetic examples for early discussion; credentials and private customer data do not belong in the enquiry form.

A prototype can answer a navigation question without proving demand. Expert review is different from observed user research. If interviews, recruitment, usability sessions or specialist assessments are needed, agree their method and scope explicitly. Discovery should expose that need rather than hide it inside a design workshop.

// 04

From an ambiguous feature to something a team can test

Illustrative example, not a customer specification: “Customers should be able to download invoices.” That sentence leaves identity, company membership, the billing source, failure behavior and acceptance unresolved. A useful specification makes those decisions reviewable.
Decision Proposed scope Acceptance evidence
User and business task

An authorized company user downloads an invoice for their own company.

The intended invoice can be found and retrieved through the complete journey.

Access boundary

Company membership is checked on every document request.

A direct request for another company invoice is denied without exposing invoice data.

Source of truth

The billing system owns the invoice and account mapping.

A missing mapping or unavailable source produces an explicit recoverable state.

Performance assumption

Agree document size and concurrent use before setting a response target.

Measure the agreed percentile in a named environment with representative load.

Release boundary

Start with one agreed invoice format and authorized account role.

Deferred formats and administration features are explicitly excluded from the first milestone.

// 05

How we get from questions to a build offer

The offer card shows the current published duration. The work needs timely access to decision-makers and the information required to resolve the scope. A calendar slot alone cannot resolve an unavailable vendor API or a disputed product priority.
  1. Establish the decision

    Agree the user, desired outcome and constraints. Identify what prevents a build commitment and which assumptions carry the greatest delivery risk.
  2. Resolve the consequential unknowns

    Work through the critical flows, data boundaries and architecture. Use a focused prototype or technical check where it answers a specific question, with any additional scope agreed.
  3. Review the roadmap and offer

    Walk through architecture, milestone outcomes and the fixed-price build offer. Check exclusions, responsibilities and remaining assumptions with the person who will accept the build.
// 06

You can commission the build, change direction or stop

If Wavect builds the product, the Discovery fee is credited in full against the build invoice. You can also keep the roadmap and have another team implement it; the published offer does not require you to buy the build. Discuss required handover formats and access before starting so the result is useful to that team.

A credible discovery can recommend a smaller release, a standard product or stopping an idea that cannot be supported by the evidence. The purpose is to make the build decision better. It should not make a larger build feel inevitable.

Use Software Development for implementation, compare fixed price and time and materials , or read what a discovery phase covers for the wider buying checklist.

// proof

From product decisions to delivered software

PromptID provides public product-delivery context. The example specification on this page is illustrative; the actual discovery scope follows your users, constraints and build decision.

These are selected projects, not our full portfolio. We have shipped 75+ products since 2018.

Questions before you start

No. This page explains the same Discovery + Roadmap offer. The card above reads the current fee, duration and credit directly from the existing offer data, so this is not an extra planning package.
The existing offer includes architecture, milestones and a fixed-price build offer. You keep the roadmap and can build elsewhere. Agree the detail, formats and any additional research or documentation in the scope before starting.
Yes. The published Discovery + Roadmap fee is deducted in full from the build invoice if you continue with Wavect. Implementation is commissioned separately against the agreed scope.

Discuss your Discovery + Roadmap

Tell us what you want to build, which decisions remain open and who can agree the scope. We will check whether the existing Discovery + Roadmap offer fits.