Project Discovery: A Founder's Guide to Doing It Right

Why Fora Soft wrote this playbook

Fora Soft has been shipping video, AI and multimedia software since 2005: 250+ projects, 50 in-house engineers. We have run hundreds of project discoveries, including the ones behind Scholarly (an Australian learning platform that now runs live classes of up to 2,000 participants), Alve Live (a WebRTC streaming platform), and Vodeo (a native iOS streaming app). We have also inherited projects where discovery was skipped, and spent the first month just re-doing it.

This is the short version of what we walk founders through when they ask "why do I need a discovery, and how do I know I’m not buying theatre?" It covers what a good discovery produces, what a bad one looks like, what you should pay, and how to spot a vendor using discovery as a sales gate instead of a planning tool.

What project discovery actually is (and isn’t)

Project discovery is the 1–3 week phase between "I have an idea" and "we’re building it." The goal is to answer five questions precisely enough that a developer can write an honest estimate and a non-technical founder can make a go / no-go call:

• What are we actually building? Not the pitch-deck version. The feature-level version: every screen, every role, every third-party integration.
• Who is it for? Which users pay, which use it free, and which behaviours separate a power user from a churning one.
• What’s the cheapest version that still proves the thesis? The walking skeleton, or MVP. Cutting 40% of planned features here is typical and healthy.
• Where are the biggest risks? Technical (can this work?), regulatory (GDPR, HIPAA, COPPA, app-store rules), market (does anyone want it?), commercial (can you reach break-even?).
• What does it cost, roughly? A range with explicit assumptions, not a single number dressed up as precision.

Discovery is not a detailed technical specification, a full design system, or a commitment to a fixed feature set. It is the thin, honest plan that lets everything after it move fast. Get it right and the build feels boring in the best way. Get it wrong, or skip it, and you pay for the missing thinking later, at a much worse exchange rate.

Why skipping discovery is the most expensive mistake in software

The Standish Group’s CHAOS reports have tracked software outcomes for three decades, and the numbers have barely moved: roughly 31% of projects succeed, about half are "challenged" (late, over budget, or short on features), and the rest fail outright. Unclear requirements is the reason it names first, ahead of technical complexity and team problems. The CHAOS methodology has fair critics: Jorgensen and Molokken-Ostvold questioned its definitions back in 2006, so treat the exact percentages as directional. The direction is not in dispute.

CB Insights reached the same place from the business side. In its analysis of startup post-mortems, "no market need" is the top root cause (around 42%), and "not the right team" sits high on the list too (around 23%). Both are discoverable, emphasis on discoverable, inside a two-week discovery, long before you have burned a build budget finding out.

Then there is the cost of catching a mistake late. Boehm and Basili’s "Software Defect Reduction Top 10 List" (IEEE, 2001) found the cost of fixing a problem climbs the later you catch it: often around 5× for smaller, non-severe defects, and up to roughly 100× for severe ones caught after release. It is not a fixed law, and anyone quoting a precise "1:10:100" as gospel is overselling it. What holds is the shape: a vague brief you fix in a discovery call is cheap; the same gap discovered in production, with live users and real data, is not. You can’t out-engineer a vague brief, and pretending otherwise is why so many founders feel they are overpaying their developers.

Figure 1. Catch it in discovery or catch it in production: the same defect, a very different bill. Magnitude is directional (Boehm & Basili, 2001), the direction is not.

The three stages of a Fora Soft discovery

Every team runs discovery a little differently. Ours has three stages because each answers a different set of questions and leaves a different artifact.

Figure 2. Three stages, three artifacts, 2–3 weeks end to end. The first consultation is always free.

The whole thing normally takes 2–3 calendar weeks. If a vendor pitches you a three-month discovery, ask exactly what they are producing. The honest answer is usually that they are running design sprints and calling them discovery, which is a different service at three-to-five times the price.

Why the first call is live, not a form

Nothing replaces a real conversation for the first stage. Forms make founders guess what matters; a live call lets a senior engineer react to a constraint the moment it surfaces ("you need on-prem? that changes the whole hosting story"). Half of the value of discovery is in the questions you didn’t know to ask, and a form can’t ask them back.

Discovery for an existing product is a different animal

If you already have a working product, discovery is less about deciding what to build and more about diagnosing what you have. We swap the ideation stage for a code audit:

• Code review. Architecture, test coverage, dependency health, known CVEs, deployment pipeline, observability.
• UX review. Major flows walked end to end; dead ends, confusing states and broken accessibility flagged.
• Infrastructure review. Cost model, scaling ceiling, vendor lock-in, data-residency and compliance posture.
• Legacy triage. What needs rewriting now, what can be left alone, and what can be fenced off behind a new service.

The scoping output looks similar to a new-product discovery — a prioritised list of improvements with rough estimates — but the numbers are usually more reliable, because we are measuring instead of guessing. If a previous vendor is still involved, we also handle the practical mechanics of safely sharing source code between teams.

What you should walk out of discovery with

A useful discovery output is thin enough to read in one sitting and concrete enough to hand to a second vendor for a competing bid. Anything heavier is usually marketing material dressed up as a plan.

MoSCoW (Must, Should, Could, Won’t; Dai Clegg, 1994) is the workhorse here because it forces the "Won’t (this release)" column that founders skip and later wish they hadn’t.

Some shops also hand you user-flow maps, use-case diagrams, and a full software requirements specification. Those are useful once you are building; they are rarely worth the discovery clock, which is why our default output stays deliberately thin. If your project genuinely needs them (regulated domains often do), we add them on purpose, not by reflex.

What discovery should cost and how long it should take

Because Fora Soft uses agent-assisted engineering (senior engineers plus LLM-based code and analysis tools), our discoveries tend to be shorter and cheaper than typical agency quotes. The ranges below reflect recent projects, not industry benchmarks. For external context, most agencies quote roughly $5,000–$25,000 for small-to-mid discoveries and $40,000+ for enterprise ones.

The payoff, in plain arithmetic

A mid-size product to first release is roughly 2,000 build hours. Left unscoped, requirement churn commonly adds a fifth on top: call it 400 hours of rework (PMI’s 2018 Pulse of the Profession put scope creep at 52% of projects). A discovery that costs 20–40 hours to run, and halves that churn, saves around 200 hours. Thirty hours in, two hundred out: better than a 6:1 return, before you count the projects a good discovery talks you out of building at all.

The first consultation is always free. Paid discovery kicks in only once both sides agree the project is real and the scope justifies the work. Anyone charging four figures for an hour-long sales call is running a different business.

How AI is changing discovery in 2026

AI has genuinely compressed parts of discovery. A competitor teardown that took a day is now a couple of hours; first-draft user stories, wireframes and clickable prototypes come out of tools like v0, Uizard and Visily fast enough to react to in the same session. We lean on agent-assisted workflows for exactly this, which is part of why our discoveries run lean.

What AI has not changed is judgment. It will happily generate a confident feature list and a tidy estimate that both quietly assume the wrong architecture. It can draft a competitor teardown in an hour; it cannot tell you your live-video stack will fall over at 500 concurrent users — that comes from having shipped it (the sort of hard-won specifics we collect in our streaming engineering notes). Worth remembering, too, that METR’s 2025 study found AI tools can actually slow experienced engineers by about 19% on code they know well. AI accelerates the typing in discovery. It does not replace the senior engineer deciding what is worth building and what will break.

The practical takeaway: use AI to go faster through the mechanical parts, and spend the hours it frees up on the judgment calls — scope cuts, risk, and the honest range. That is where a discovery earns its keep.

Red flags: how to spot a discovery that’s really a sales pitch

Not every "discovery workshop" is a planning exercise. Some are extended sales calls with a consulting invoice attached. Five signals that the discovery you are buying is more theatre than substance:

1. No technical person on the call. If a sales lead with a deck is running your discovery, push back. A good discovery needs a senior engineer who can react to constraints live. Sales-led discoveries produce feature lists that are optimistic on effort and shy on risk.

2. Single-number estimates. "$142,000" as a deliverable is not an estimate, it is a sales target. A legitimate discovery produces a range with explicit assumptions.

3. A discovery that takes longer than the MVP. A three-month discovery for a two-month build means you are funding someone else’s design exercise. Discovery should be rocket fuel for the build, not a substitute for it.

4. No risk register in the output. If the deliverables don’t include the top five-to-ten things that could go wrong, the team hasn’t thought hard enough — or doesn’t want you to.

5. The output is locked to the vendor. If you can’t take the plan and get a competing bid with it, it wasn’t a plan. It was a leash.

How to prepare for your discovery as a founder

A good discovery gets the vendor 80% of the way. The founder brings the other 20% — the stuff that lives in your head and nowhere else. Four short documents save real time and money on both sides:

1. A one-page "what and why". Not a deck. A page. What you’re building, who it’s for, and why you think they’ll pay. If you can’t write it in a page, you don’t know the product yet.

2. A list of 3–5 competitors. Names and URLs. Which are closest, which you want to out-feature, and which you explicitly don’t want to copy.

3. A short list of non-negotiables. Regulatory (HIPAA, GDPR, COPPA), technical (must run on-prem; must integrate with Salesforce), commercial (must ship before a funding round).

4. A ceiling budget. Not the final number — the number past which you won’t go. Knowing it lets the vendor design the right MVP instead of pricing the wrong one.

Mini case: a discovery that cut scope by 45%

An EdTech founder came to us wanting "a learning platform with AI tutors, video classrooms, homework generation, a parent portal, analytics, and a marketplace." Their quote from another vendor was eight months and well into six figures. They wanted a second opinion.

Our two-week discovery produced a feature spreadsheet with MoSCoW priorities. Roughly 45% of the original scope moved to "later" — not because it was bad, but because it wouldn’t prove the core thesis: will paying parents actually sign up for AI-assisted tutoring? We proposed an MVP with video classrooms, a single AI-tutor flow, and Stripe checkout; everything else queued.

The cut MVP shipped in twelve weeks at about half the original budget. When the founder came back nine months later to build the rest, they did it with real usage data instead of assumptions — which quietly turned two of the original "must-haves" into "don’t build." Want a similar exercise? Book a 30-minute call and we’ll walk your scope live.

Discovery vs. design sprint vs. tech spec: pick the right tool

Several engagements get confused constantly. They answer different questions and cost very different amounts of money. Line them up before you buy one:

Figure 3. The five engagements on one axis: problem space on the left, solution space on the right. For most founders, project discovery is the right first stop.

The design sprint is the five-day format Jake Knapp built at Google Ventures; it validates a solution, not a plan. For most founders, project discovery is the right starting point. Full technical specs are usually premature — they belong after discovery, once scope is locked, or for regulated and contractual handoffs.

Five pitfalls that make discovery worthless

1. Discovery without a real build conversation. If the team running discovery won’t be building the product, the numbers and risks are speculative. Commit to the team, then run discovery.

2. Starting with pixel-perfect mockups. Polished UI is expensive and locks scope prematurely. Wireframes and flow diagrams are enough to estimate against; hi-fi design belongs in the build phase.

3. Skipping the "cut 40%" conversation. If scoping doesn’t cut aggressively, the founder cuts later at ten times the cost, when the budget runs out. Cut early and often.

4. No explicit assumptions. Every estimate rests on assumptions ("three user roles," "Stripe only," "English only"). Write them into the output. When reality differs, the gap is visible and renegotiable instead of a fight.

5. Ignoring cost-to-run. A discovery that costs out build hours but skips hosting, third-party APIs, compliance and support can be off by 30–50% on year-one total cost. Scope the run-rate, not just the build — here are ten ways to cut cost without cutting quality.

A decision framework: do you need a discovery, and how deep?

Five questions decide whether you need a discovery and how heavy it should be. Follow the trunk; each "yes" changes what the discovery has to include.

Q1. Are you signing a fixed-price build contract? Yes: discovery is mandatory — nobody can price fixed without one. No: still recommended, but lighter.

Q2. Is this a regulated domain (health, finance, education, under-13 users)? Yes: a formal discovery with a compliance review is non-negotiable. No: a lean discovery may be enough.

Q3. Do you have an existing codebase? Yes: replace ideation with a code audit. No: run the full new-product flow.

Q4. Is your budget ceiling under $25k? Yes: a one-week lean discovery is enough; longer eats the build budget. No: invest 2–3 weeks — the return is there.

Q5. Has another vendor already quoted you? Yes: a second-opinion discovery is the cheapest insurance you’ll buy. No: a baseline discovery is fine.

Figure 4. Five questions, one path. Most founders land on a standard 2–3 week discovery; the branches show what changes.

KPIs: how to tell your discovery was any good

Accuracy KPIs. Did the final build land inside the discovery’s high estimate? Did mid-build scope change stay under 20%? Did any risk in the register actually fire, and did the mitigation work?

Decision KPIs. Did you make a clear go / no-go the same week you read the output? Did you use it to get at least one competing bid (a healthy sign)? Did you feel you understood the tradeoffs? If not, the discovery missed.

Reliability KPIs. Did development start within 2–4 weeks of discovery closing? Did the first working increment ship inside the phase-1 timeline? Did the team avoid re-litigating discovery questions after week two of the build? If it kept reopening them, the discovery was too shallow.

When to skip a full discovery

Discovery is a tool, not a religion. Skip or shrink it when:

• The build is tiny. A two-week landing page doesn’t need a three-week discovery. A 30-minute call and a one-page brief is enough.
• You’re on time-and-materials with a team you trust. Discovery outputs matter less when you can steer in flight.
• It’s a throwaway prototype. Investor demo, spike, design validation. Ship first, discover later if it survives.
• You already have a validated spec and just need hands. Rare, but it happens. Skip to statement-of-work.

When you do need speed but still want rigour, there is a middle path: our 7-day scoping pass compresses the same thinking into a single week. Either way, our output is portable on purpose — if you want to compare bids, you’ll have everything you need to do it fairly, including a candid recommendation on whether we should be one of them.

What happens after discovery

A finished discovery feeds straight into the analytical stage of development: user stories, acceptance criteria, design system, API contracts, sprint plan. Each artifact is expanded, not reinvented. The feature list becomes the backlog; the architecture sketch becomes the system design; the risk register becomes the sprint-zero checklist.

Founders who treat discovery as the end of planning and the start of executing tend to make the investment back several times over in the first build phase. Founders who treat it as a box to tick before signing a fixed-price SoW usually end up renegotiating it halfway through. You avoid that by addressing slippage early rather than at the sprint review.

FAQ

How long does a project discovery take?

A typical new-product discovery runs 1–3 weeks end to end. Small MVPs land in 5–8 days, mid-size products in 8–12 days, and complex or regulated products in 2–4 weeks. Anything much longer is usually a different engagement, like a design sprint or a full technical specification.

How much should a project discovery cost?

At Fora Soft, paid discoveries usually run 8–80 billable hours depending on scope, and the first consultation is free. Across the wider agency market, discoveries commonly cost $5,000–$25,000 for small-to-mid projects and $40,000+ for enterprise ones. Be wary of anyone quoting a big flat fee who can’t describe the deliverables in detail.

What is the difference between project discovery and product discovery?

Product discovery is a continuous, problem-space activity: is there real demand, and for what? Project discovery is a time-boxed phase right before a build: what is the cheapest useful version, what will it cost, and where are the risks? You often do product discovery for months and project discovery in the two weeks before you commit engineers.

What deliverables should I expect from a discovery?

Six things: a MoSCoW-prioritised feature list, a one-page architecture sketch with 2–3 tradeoffs, a low/likely/high budget range, a phased timeline, a top-5-to-10 risk register, and 2–3 tech-stack recommendations. If the output is heavier than that but says less, it is probably a sales artifact.

Can I skip discovery if I already have a detailed spec?

You can, but you usually shouldn’t. Even a detailed spec hides implicit assumptions that only surface in conversation: expected user load, data residency, third-party contract terms. A one-week lean discovery is cheap insurance against them.

Do I have to keep building with the vendor who ran the discovery?

No, and that is the point. A good discovery output is portable: you should be able to hand it to any vendor for a competing bid. If a discovery is locked to one vendor’s tools or templates, treat that as a red flag.

What comes after the discovery phase?

The discovery feeds the analytical stage: user stories, acceptance criteria, a design system, API contracts and a sprint plan. Nothing is reinvented — the feature list becomes the backlog, the architecture sketch becomes the system design, and the risk register becomes the sprint-zero checklist.

Does a discovery guarantee a fixed-price quote?

It makes an honest fixed price possible, but a good discovery still hands you a low/likely/high range, not a single number. If a vendor turns a two-week discovery into one precise figure with no assumptions attached, that number is a sales target, not an estimate.

What to read next

Ready to start your project the right way?

Project discovery isn’t overhead. It is the cheapest insurance you’ll ever buy against a six-figure mistake. The right output is thin, portable and makes the build predictable; the wrong output is a glossy deck that hides the risks. We’ll always tell you which one you’re looking at — even when the answer is "you don’t need a discovery yet, you need to talk to five users."

If you want an honest 30-minute conversation about your idea or your existing product, the call is free and the advice is real.