Project Discovery: A Founder's 2026 Guide to Starting Software Projects Without Overpaying

Why Fora Soft wrote this playbook

Fora Soft has been shipping video, AI and multimedia software since 2005. We’ve run hundreds of project discoveries, including ones that led to Scholarly (an all-in-one Australian learning platform now hosting live classes of up to 2,000 participants), Alve Live (a WebRTC streaming platform), and Vodeo (a native iOS streaming app). We’ve also inherited several projects from other vendors where discovery was skipped — and spent the first month just re-doing it.

This article 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 actually produces, what a bad one looks like, what you should pay for it, and how to spot a vendor who’s 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 decision:

1. What are we actually building? Not the pitch deck version — the feature-level version. Every screen, every role, every third-party integration.

2. Who is it for? Which users pay, which ones use it for free, and which behaviours distinguish a power user from a churning one.

3. What’s the cheapest version that still proves the thesis? The “walking skeleton” or MVP. Cutting 40% of planned features at this stage is typical and healthy.

4. Where are the biggest risks? Technical (can this actually work?), regulatory (GDPR, HIPAA, COPPA, app-store rules), market (does anyone want this?), and commercial (can we reach break-even?).

5. What does it cost, roughly? A ballpark 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 final price. Vendors who sell it as any of those things are either misnaming a different engagement or padding a sales funnel.

Why skipping discovery is the most expensive mistake in software

The Standish Group’s CHAOS reports have tracked software project outcomes for three decades. The numbers have barely moved: only about 31% of projects are delivered successfully, 50% are “challenged” (late, over budget, or short on features), and 19% are outright failures. Unclear requirements is the #1 cited reason, ahead of technical complexity and team problems.

CB Insights’ post-mortem study of 100+ failed startups reaches the same conclusion from the business side: “no market need” and “wrong team” are the top two causes. Both are discoverable — emphasis on discoverable — in a two-week discovery.

The cost math is brutal. An error caught at discovery costs roughly 1x to fix. The same error caught during development costs 10x. Caught after launch, with live users and real data, it usually costs 100x or more. This is IBM’s cost-of-defects model, and it holds for everything from auth flows to whole-feature pivots. You can’t out-engineer a vague brief, and pretending otherwise is why so many founders feel they’re overpaying their developers.

The three stages of a Fora Soft discovery

Every team does discovery slightly differently. Ours has three stages because each one answers a different set of questions and produces a different artifact.

The whole thing normally takes 2–3 calendar weeks end-to-end. If a vendor pitches you a three-month discovery, ask exactly what they’re producing — the honest answer is probably that they’re running design sprints and calling them discovery, which is a very different service at 3–5x the price.

Why the first call is live, not a form

Nothing replaces a real conversation for the personal consultation. Forms force founders to guess what information matters; live calls let a senior engineer ask follow-up questions and catch the invisible constraints. Half of the most important facts about a project — regulatory limits, investor deadlines, technical debts from a previous vendor — surface only because someone asked the right follow-up question.

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 replace the ideation stage with a code audit:

• Code review. Architecture, test coverage, dependency health, known CVEs, deployment pipeline, observability.

• UX review. Major flows walked end-to-end. Flag dead ends, confusing states, broken accessibility.

• Infrastructure review. Cost model, scaling ceiling, vendor lock-in, data-residency posture, 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’re measuring, not 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.

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 are typically shorter and cheaper than typical agency quotes. Ranges below reflect recent projects, not industry benchmarks.

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

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 consulting invoices attached. Five signals that the discovery you’re buying is more theatre than substance:

1. No technical person on the call. If the person running your discovery is a sales lead with a deck, 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’s a sales target. A legitimate discovery produces a range with explicit assumptions. See why developer time estimates fail.

3. Discovery that takes longer than the MVP. A 3-month discovery for a 2-month build means you’re funding someone else’s design exercise. Discoveries 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 5–10 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. A good discovery can be handed to any competent vendor for a second quote. If the artifacts require proprietary tooling or private access to run, you’re being locked in.

How to prepare for your discovery as a founder

A good discovery gets the vendor 80% of the way. The founder’s job is to bring the other 20% — the stuff that lives in their head and nowhere else. Four specific documents save 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 this in a page, you don’t know the product yet.

2. A list of 3–5 competitors. Names and URLs. Which ones are closest, which ones you want to out-feature, which ones 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 necessarily the final number — but the number beyond which you won’t go. Knowing this lets the vendor design the right MVP instead of pricing the wrong one.

Mini case — discovery that cut scope by 45%

An EdTech founder came to us wanting to build “a learning platform with AI tutors, video classrooms, homework generation, a parent portal, analytics, and a marketplace.” Their initial 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 returned nine months later to build the rest, they did so with real usage data instead of assumptions — which changed two of the original “must-haves” into “don’t build.” Want a similar exercise? Book a 30-minute call and we’ll walk through your scope live.

Discovery vs. design sprint vs. full tech spec — pick the right tool

Three engagements get confused constantly. They answer different questions and cost very different amounts of money.

For most founders, a discovery is the right starting point. Design sprints help when you’re unsure whether the idea itself works. Full technical specs are usually premature — they’re appropriate after discovery, when scope is locked, or for regulated / contractually-required 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, numbers and risk 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 for estimation. Hi-fi design belongs in the build phase.

3. Skipping the “cut 40%” conversation. If the scoping doesn’t cut features aggressively, the founder will cut them later at 10x the cost when they run out of budget. Cut early and often.

4. No explicit assumptions. Every estimate rests on assumptions (“3 user roles”, “Stripe only”, “English only”). Write them down in the output. When reality differs, the gap is visible and renegotiable.

5. Ignoring cost-to-run. Discovery that only costs out build hours and skips hosting, third-party APIs, compliance, and support can be off by 30–50% on year-one total cost. Always scope run-rate, not just build cost. See cost-cutting on software projects.

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

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

Q2. Is this a regulated domain (healthcare, finance, education, under-13 users)? Yes → formal discovery with 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 → full new-product discovery flow.

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

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

KPIs — how to tell your discovery was any good

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

Decision KPIs. Did the founder make a clear go / no-go after reading the output (target same week)? Did they use the output to get at least one competing bid (healthy sign)? Did they feel they understood the tradeoffs (if no, the discovery missed)?

Velocity KPIs. Did dev start within 2–4 weeks of discovery close (target yes)? Did first working increment ship within the phase-1 timeline (target within 10%)? Did the team avoid revisiting discovery questions after week 2 of build (target yes — if no, 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 running a time-and-materials contract with a team you trust. Discovery outputs matter less because 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. This is rare, but it happens. Skip to statement-of-work.

What happens after discovery

A finished discovery feeds directly into the analytical stage of development: user stories, acceptance criteria, design system, API contracts, sprint plan. Each artifact is expanded, not re-invented. 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 the planning and the start of executing make it back 3–5x on the investment within 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. Avoid that by addressing slippage early rather than at the sprint review.

FAQ

What to read next

Ready to start your project the right way?

Discovery isn’t overhead — it’s 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.

Fora Soft will always tell you which kind you’re looking at — even when the answer is “you don’t need a discovery, you need to talk to five potential users first.” If you want an honest 30-minute conversation about your idea or your existing product, the call is free and the advice is real.