What You Actually Get From a Platform Discovery Sprint

At concept stage, software estimates carry a 16× spread between the low and high end. By the time you have detailed requirements and an architecture, that spread compresses to roughly 1.2×. The entire purpose of a discovery engagement is to move you from the first number to the second — before you commit real money.

That is the only claim that matters. Everything else in this article is about how the deliverable achieves it.

We have written separately about why quotes from different agencies vary by a factor of four on the same brief, about how to write a brief that produces comparable quotes, and about what funded founders get wrong about their first platform build. This article covers different ground: the deliverable itself. What each component is, what it contains, why it exists, and what the research says about its value. If you are considering a discovery engagement — with us or with anyone — this is the article that tells you what to expect and what to demand.

The estimation problem discovery exists to solve

Barry Boehm's original research in Software Engineering Economics (1981), later refined by Steve McConnell in Software Estimation: Demystifying the Black Art (2006), established what practitioners now call the Cone of Uncertainty. At the initial concept stage — when a founder has an idea and a budget but no detailed specification — estimation accuracy ranges from 0.25× to 4×. A project estimated at £50,000 might genuinely cost anywhere from £12,500 to £200,000. That is not imprecision. It is the measured reality of estimating work that has not been defined.

By the time requirements are documented and architecture is designed, the spread compresses to roughly 0.67× to 1.5×. By detailed design, it narrows further to 0.9× to 1.1×. The Cone does not narrow itself — it narrows only through decisions that eliminate variability. A discovery sprint is the structured process of making those decisions.

The scale of the problem is not academic. Flyvbjerg, Budzier and colleagues at Oxford studied 5,392 IT projects completed between 2002 and 2014, totalling $56.5 billion across 66 countries (Journal of Management Information Systems, 2022). The mean cost-overrun ratio was 1.8 — roughly 80% average overrun. The distribution follows a power law with a fat tail, meaning extreme overruns are not rare outliers but a structural feature of the data. One in six projects in an earlier study by the same team experienced cost overruns averaging 200%.

The PMI's 2014 Pulse of the Profession report (n=2,066) found that inaccurate requirements management was the primary cause of unsuccessful outcomes 47% of the time — with an estimated 5.1 cents of every project dollar wasted on poor requirements. IAG Consulting's Business Analysis Benchmark (n=437) found that poor requirements definition consumed over one dollar in three of the application development budget in rework.

These are not arguments for discovery as a concept. They are the measured cost of skipping it.

The report: 15–20 pages of decisions, not descriptions

The Platform Discovery Report is the core deliverable. It runs 15–20 pages, written in plain English with technical detail where it matters. It is not a proposal — it is not designed to sell you on working with us. It is designed to give you the clearest possible picture of what you are building, what it will cost, and whether you should build it at all.

The report is yours. You can take it to any developer. It is designed to be portable — which is the single most important structural decision in how we built this product. Among the UK agencies I researched when designing the Sprint, only a handful publish a price, and fewer still make the deliverable explicitly standalone. Most tie discovery to a build engagement, which means the incentive is to recommend building. Ours includes a "don't build, use off-the-shelf" recommendation where that is the honest answer.

The report contains seven components. Each one exists because the research says it matters.

MoSCoW requirements: the 80% you should not build first

The first section of the report is a prioritised requirements list using MoSCoW classification: Must-Have, Should-Have, Could-Have, Won't-Have. The method was created by Dai Clegg at Oracle UK in 1994 and later formalised by the DSDM Consortium (now the Agile Business Consortium). The standard rule, documented in the DSDM Project Framework Handbook, is that Must-Have requirements should not exceed 60% of total effort — leaving 40% as contingency that protects the project when reality diverges from the plan.

The reason this matters is not theoretical. Pendo's 2019 Feature Adoption Report analysed usage data across 615 SaaS products and found that 80% of features were rarely or never used — 56% never used at all, 24% rarely used, with just 12% driving the majority of daily engagement. Their rolling benchmark puts the median feature adoption rate at 6.4%. The implication is brutal: for every twelve features you build, roughly ten will not earn their keep.

The Standish Group's older figure — 64% of features rarely or never used — is weaker. Mike Cohn at Mountain Goat Software confirmed by direct contact with Standish that the underlying study was based on just four internal applications at four companies. The Pendo dataset, at 615 products, is the stronger citation.

MoSCoW prioritisation in the report is on effort, not feature count. A Must-Have feature that takes three weeks and a Could-Have feature that takes two days look similar on a feature list but are fundamentally different commitments. The prioritisation forces a conversation about what you would cut if you ran out of time or money — because on a long enough timeline, you will.

The requirements section also serves a second purpose. A study by Engprax and J.L. Partners (n=600, 250 UK) found that projects with documented requirements before development started were 97% more likely to succeed. The study was commissioned to support a book launch and the full methodology has not been published — treat the figure as directional rather than definitive. But the direction is consistent with every other source in this space: documented requirements reduce failure rates. The report gives you documented requirements.

Architecture diagram: the map your next developer needs

The report includes a one-page architecture diagram showing how the system fits together — the components, the data flows, the integrations, the boundaries between what is custom-built and what is off-the-shelf.

This is a system-level diagram, not a detailed UI mockup — the lo-fi screen layouts that show individual user flows sit alongside it in the report, but the architecture diagram focuses on how the components fit together. The architecture diagram shows system-level structure: how each user type moves through the application, where data is stored, how third-party services connect, and which components depend on which. For projects involving multiple user roles — an applicant, a reviewer, an admin, a reporting dashboard user — the diagram shows how each role's journey maps through the system differently.

The value of architecture documentation is one of the most robustly measured findings in software engineering. The DORA programme at Google Cloud (cumulative n≈36,000 across seven years) found in their 2021 report that teams with high-quality documentation are 2.4 times more likely to see better software delivery and operational performance. The same research found documentation amplifies the effectiveness of continuous integration by 2.4× and continuous delivery by 2.7×. Only about 25% of respondents reported having good-quality documentation — which means the other 75% are paying a tax on every subsequent change.

Stack Overflow's 2024 Developer Survey (n=65,437 across 185 countries) found that 61% of professional developers spend more than 30 minutes every day searching for answers or solutions, with 30% hitting knowledge silos ten or more times per week. GitHub's 2021 State of the Octoverse (4M+ repositories, 12,000+ developers surveyed) found that repositories with proper documentation make developers 55% more productive.

An architecture diagram produced during discovery becomes the single most referenced document in the entire build. It is the thing your next developer reads first, the thing your investor asks to see, and the thing that prevents the question "why was it built this way?" from consuming weeks of someone's time six months from now.

Technology recommendation: the decision that compounds for years

The report includes a technology recommendation — what to use, what to avoid, and why. This is not a sales pitch for our preferred stack. It is an assessment of which technology choices serve the project's constraints: team size, budget, hiring pool, performance requirements, and the realistic trajectory over three to five years.

The research on getting this wrong is well-documented through case studies rather than surveys. Segment, a data infrastructure company, described their retreat from microservices in a 2018 engineering blog post: three full-time engineers were spending most of their time just keeping the microservice mesh alive, and the team consolidated 140 microservices into a single service. Productivity rose from 32 shared-library improvements pre-consolidation to 46 the following year. Amazon Prime Video's video-quality monitoring tool reduced infrastructure costs by over 90% by moving from a serverless microservice architecture to a monolith — though the authors explicitly noted the decision was case-specific. Shopify processes billions in transactions on a 2.8-million-line Ruby monolith with 400,000 unit tests on every build.

Martin Fowler's argument in "MonolithFirst" (2015) remains the clearest articulation: almost all successful microservice stories started with a monolith that got too big and was broken up, and almost all systems built as microservices from scratch ended in serious trouble.

For a UK SME commissioning a £25,000–£75,000 platform build, the technology recommendation is less about microservices versus monoliths and more about practical constraints: which framework has the deepest UK hiring pool, which hosting approach matches the budget, which third-party services are worth integrating versus building, and where AI adds genuine leverage versus unnecessary complexity. The recommendation in the report is specific to the project, not generic advice.

Phased roadmap: budget ranges, not fiction

The report includes a phased roadmap covering three to four phases across a six-to-eighteen-month horizon, with timeline and budget ranges per phase. The closer the phase, the tighter the range. Phase one — typically the MVP — comes with the most accurate figure, often tight enough to quote as a fixed fee. Later phases carry broader ranges because their scope depends on what you learn from the earlier ones.

This structure exists because the alternative — a single fixed price for the entire vision — is fiction at concept stage. The Flyvbjerg and Budzier Oxford data on 5,392 projects confirms that IT cost overruns follow a power-law distribution, not a normal one. The tail risk is real. A phased roadmap with budget ranges per phase is more honest than a single headline number, and it gives you the data to make capital-allocation decisions phase by phase rather than committing everything upfront.

The roadmap also serves a practical purpose for grant applications. Innovate UK and similar funders look for a costed technical plan with phases, risks, and a named UK technical partner. The report is structured with that in mind — the phased roadmap, risk assessment, and architecture diagram map directly to what grant assessors expect to see in a submission.

At 5–10% of anticipated build cost, discovery pricing follows the same convention as adjacent professions. RIBA architects charge roughly 5–10% of construction cost in total fees, with early-stage work (Stages 0–2) representing about a third of that. RICS quantity surveyors charge 0.5–1% for a standalone feasibility report. The GDS Digital Marketplace prices discovery phases at £50,000–£150,000 for eight-week engagements on larger government programmes. McKinsey charged the UK government £563,400 for a six-week vision engagement in 2020 (Privacy International), and £3 million for an eight-week diagnostic in 2021 (The Register). At £4,500 for three weeks, the Sprint sits at the SME end of a pricing convention that every chartered profession follows.

Build, buy, or hybrid: the recommendation most agencies cannot give

The report includes an explicit build, buy, or hybrid recommendation — including "don't build, use off-the-shelf" where that is the honest answer.

Martin Fowler's Utility vs Strategic Dichotomy (2010) estimates that roughly 5% of business processes are genuinely strategic — the kind that differentiate your business and justify custom development. The other 95% are utility: necessary but not differentiating. Geoffrey Moore's core-versus-context distinction in Dealing with Darwin reaches the same conclusion from a different angle: build what creates customer preference at the point of purchase; buy or outsource everything else. Forrester reframed the binary entirely in 2021, arguing that "pure buy doesn't exist, and pure build is often impractical" — the real choice is between customising a packaged solution and composing a custom one from platforms and services.

The practical translation: if your workflow is well-served by HubSpot, Xero, and Calendly with some configuration, the report will say so. We have covered the full decision framework for when to build custom versus when to stick with SaaS in a separate article — the Sprint applies that framework to your specific situation.

This recommendation is structurally difficult for most agencies to give honestly, because recommending against a build means recommending against their own revenue. The Sprint's portability is the design feature that addresses this: the deliverable is yours regardless of whether you proceed with us. The £4,500 is credited in full against a Custom Platform Build signed within 30 days of the presentation — so if you do proceed, the discovery is effectively absorbed into the build cost. If you do not, the report stands on its own. Take it to any developer you choose.

Risk assessment: specific risks, specific mitigations

The report includes a risk assessment — not generic warnings about "technology risk" or "market risk," but specific risks with specific mitigations tied to the project. For applications handling personal data, this includes data privacy considerations under UK GDPR. For applications involving children or vulnerable users, it includes safeguarding considerations. For applications targeting grant funding, it includes the specific risks assessors will flag.

The risk assessment also covers technology risks: what happens if the chosen hosting provider raises prices, if a critical third-party API is deprecated, if the founding developer leaves. These are the scenarios we have documented extensively across our Laravel Support series — the Discovery Sprint identifies which of them apply to your project and how to mitigate them before they materialise.

Code Health Scorecard: for applications that already exist

For clients who arrive with an existing application — whether built by a freelancer, an agency, or with AI tools like Lovable, Bolt.new, or Cursor — the Sprint includes a Code Health Scorecard. This combines automated scanning with a manual expert review, producing a severity-prioritised list of findings with a fix, refactor, or rebuild recommendation per component.

The automated layer catches what humans miss at scale. Static analysis tools can detect hundreds of bugs, vulnerabilities, and code smells per language. Framework-specific analysers resolve patterns that generic tools cannot infer — dynamic properties, container bindings, query builder methods — catching type errors that would otherwise surface only in production. Dependency auditing checks every installed package against known vulnerability databases. Sonatype's 2024 State of the Software Supply Chain report (1.5 trillion+ requests to Maven Central, 20,000+ enterprise applications) found that 80% of application dependencies remain un-upgraded for over a year — and 95% of the time a fixed version already exists when a vulnerable component is consumed.

The manual layer catches what automation cannot: architectural decisions that make the codebase fragile, business logic that does not match the stated requirements, and the judgment call on whether a component is worth fixing or needs replacing. We have published a detailed guide to auditing an inherited Laravel codebase that covers the full toolkit. The Code Health Scorecard applies that process within the Sprint's three-week structure.

The recorded presentation: the deliverable that travels

The Sprint concludes with a 60-minute recorded presentation walking through every recommendation in the report. This is not a sales call. It is a recorded technical briefing you can share with your co-founder, your board, your investors, or your grant assessors — anyone who needs to understand the plan without reading a 20-page document.

The recording exists because the people who need to approve the budget are rarely the people who commissioned the discovery. A CTO reads the report. A CEO watches the presentation. An investor skips to the roadmap and the budget ranges. A grant assessor checks the architecture and the risk assessment. The recorded walkthrough means the Sprint's value travels beyond the person who booked it.

What the Sprint is not

Clarity on boundaries matters as much as clarity on contents.

The Sprint does not produce detailed wireframes or a clickable prototype — those are build-phase deliverables that belong after the architecture and requirements are settled. The report does include lo-fi screen layouts showing how each user type moves through the core flows. These are rough visual blueprints, not pixel-perfect designs — but they are specific enough to register with the IPO if you want to protect your product IP.

The Sprint is not designed for projects with a total budget under £15,000. At that level, the economics do not justify a separate scoping engagement — the discovery cost represents too large a fraction of the total investment. If your budget is in that range, we have written about why your MVP does not always need to be a custom build, and the free MVP Readiness Score may be a better starting point.

The Sprint is not a code review for its own sake. The Code Health Scorecard is included only for clients with an existing application. If you are starting from scratch — an idea with no code behind it — the Sprint focuses on requirements, architecture, and the roadmap. If you have an existing codebase that needs assessment, the Sprint includes both the forward-looking plan and the backward-looking diagnosis. The rescue cost data we have published elsewhere explains why that diagnosis matters before committing to further development.

The question the Sprint answers

Every discovery engagement — paid or free, ours or someone else's — exists to answer one question: what should you build, in what order, at what cost?

The difference between a free proposal and a paid discovery is who the document is written for. A free proposal is written to win your contract. A paid discovery is written to tell you the truth — including "don't build this" if that is the answer. The behavioural economics research is clear on why this distinction matters: Kong, Rajagopalan and Tong's 2018 paper in Production and Operations Management demonstrated that customers who pay for a diagnostic phase exhibit sunk-cost commitment that makes them more likely to proceed with treatment — but critically, the paid model also aligns the provider's incentive toward accuracy rather than persuasion. A diagnosis you paid for is a diagnosis that was written to be right, not to be convincing.

We are one of the only UK agencies to publish a discovery price. Most hide behind "get in touch." We think you deserve to know the cost before you book a call.

£4,500 + VAT. Three weeks. A document you can act on — with us, with someone else, or not at all.