On this page · 11 sections
Summary. Discovery used to be the phase clients asked to skip. In 2026 it is the phase that decides whether an AI-accelerated build lands anywhere useful. Google's DORA research, updated 12 January 2026, reports that teams with a user-centric focus have 40% higher organizational performance, and that AI acts as an amplifier: "If a team's priorities are not aligned to the North Star of user needs, amplification with AI can propel them even further in the wrong direction." CISQ put the cost of poor software quality in the US at "at least $2.41 trillion" in its November 2022 report, up from $2.08 trillion in 2020, with accumulated technical debt alone at roughly $1.52 trillion. And Microsoft's own engineering guidance now names four places where intent leaks out of a project: stakeholder needs to requirements, requirements to architecture, design to implementation, and implementation to validation. Apoorv Gupta, Principal Software Engineer at Microsoft, compresses the whole argument into four words: "Spec quality = output quality."
That is the shift. When a developer wrote every line by hand, ambiguity surfaced slowly, one confused pull request at a time. An agent that generates a thousand lines an hour does not surface ambiguity at all. It fills the gap with a plausible guess and moves on. So the deliverable of a good discovery sprint in 2026 is not a requirements document that sits in a drive. It is the spec your coding agents build against, and the reason your team argues about the right things in week two instead of month five.
Below is what three weeks actually produces, what it costs you in calendar time, the five questions that determine whether an estimate is real, and the cases where discovery is a waste of your money.
Why the arithmetic changed
DORA's 2024 report found something uncomfortable for anyone about to commission a build: "Unstable organizational priorities cause meaningful decreases in productivity and substantial increases in burnout. This negative impact is highly resistant to mitigation and persists even in environments with strong leaders and high-quality documentation."
Read that last clause twice. Strong leadership does not fix it. Good documentation does not fix it. The only thing that fixes unstable priorities is settling them, and the cheapest moment to settle them is before anyone has written code they will defend.
DORA's 2025 report, published as the State of AI-assisted Software Development, reaches the same conclusion from the AI side. Its central finding is that AI magnifies an organisation's existing strengths and weaknesses, and "the greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system." DORA names the failure mode directly: the feature factory, where "adopting AI without a user-centric focus can actually harm team performance" because the team optimises for features shipped rather than user value.
Microsoft's spec-driven development guidance, published 10 June 2026, describes the mechanism at the artefact level: "Without a shared artifact that preserves intent, every handoff becomes an interpretation step. AI can accelerate those steps, but it cannot correct ambiguity that was never resolved." Its verdict on prompt-first workflows is blunt. They "often struggle as scope and complexity increase", and when "requirements, constraints, and edge cases live only in prompts, teams get fast output without a durable source of truth."
None of that is an argument for a six-month analysis phase. It is an argument for three weeks of hard thinking with a written output, then building fast against it.
What three weeks produces
A discovery sprint that earns its keep produces artefacts a third party could pick up and build from. Not slides.
| Artefact | What it settles | Who signs it off |
|---|---|---|
| Problem and user definition | Which user, which job, what changes for them | Business owner |
| Scoped slice list, ranked | What ships first, what is explicitly out | Business owner and engineering |
| Acceptance criteria per slice | How anyone can tell the slice is done | QA and engineering |
| Architecture and integration map | Data flows, third-party systems, auth model | Engineering lead |
| Risk register with named unknowns | What could move the date, and by how much | Everyone |
| Non-functional targets | Latency, concurrency, uptime, device floor | Engineering lead |
| Data classification and residency plan | What personal data is collected and where it lives | Compliance owner |
| Estimate with a stated confidence band | The number, and what would invalidate it | Both parties |
The last row is the one most proposals fake. An estimate without a stated set of assumptions is not an estimate, it is a bid. The useful version reads: this range holds if the payment provider exposes a sandbox by week two, if the legacy order API returns line-item detail, and if the design system is settled before build starts. Name those, and both sides know what a slip looks like before it happens.
Week by week
| Week | Focus | Output at the end of the week |
|---|---|---|
| Week 1 | Problem, users, and constraints. Stakeholder sessions, existing-system walkthrough, data inventory | Problem statement, user definition, constraint list, first risk register |
| Week 2 | Architecture and integration reality. Spike the riskiest integration, not the easiest | Integration map, auth and data model, spike results, non-functional targets |
| Week 3 | Scope, slicing, and the estimate. Rank slices, write acceptance criteria, price the first release | Ranked slice list, acceptance criteria, estimate with assumptions, build plan |
| Gate | Go, no-go, or re-scope decision | A signed spec, or a documented reason not to build |
Week 2 is where discovery either pays for itself or does not. The temptation is to spike the interesting piece of technology. The discipline is to spike the thing that would hurt most if it turned out to be untrue: the undocumented legacy API, the payment provider whose sandbox does not match production, the device that has to run this offline in a warehouse basement. A spike is not a prototype. It is a question with a yes or no answer, run against the real system, closed within days.
The third week ends in a gate, and a real gate can say no. A discovery sprint that has never once concluded "do not build this yet" is not a gate, it is a formality.
The five questions that make an estimate real
Ask these before signing anything. If a partner cannot answer them from their own discovery output, the estimate underneath is decoration.
- What is the thinnest slice that a real user can complete end to end, and what does it deliberately exclude? A slice that no user can finish is a demo, not a release.
- Which integration have you actually called, with credentials, against a real environment? Documentation is a claim. A logged response is evidence.
- What are the non-functional numbers? Concurrent users, p95 latency target, the oldest device and OS version you support. Vague answers here become re-architecture later.
- What personal data does this collect, where is it stored, and who is accountable for it? Under India's Digital Personal Data Protection Act 2023 the data fiduciary stays accountable for processing done on its behalf, so this is a design input, not a legal afterthought.
- What would make this estimate wrong? A partner who cannot name three things is either hiding the risk or has not looked for it.
Discovery against no discovery
| Dimension | Straight to build | After a 3-week discovery sprint |
|---|---|---|
| When scope is settled | During the build, repeatedly | Before the contract, once, in writing |
| Where integration surprises land | Mid-build, on the critical path | In week 2, before the date is promised |
| What AI agents work from | Prompts and inference | A spec with acceptance criteria |
| What the estimate rests on | Analogy and optimism | Named assumptions with a stated band |
| Cost of a scope reversal | Rework across code, tests and design | An edit to a document |
| Who owns "done" | Argued at delivery | Written per slice at the start |
| Calendar cost upfront | Zero | Three weeks |
The honest entry in that table is the last one. Discovery costs three weeks you would rather spend building. The trade is that a decision reversed in a document costs an afternoon, and the same decision reversed after implementation costs a sprint, plus the tests, plus whatever the design system inherited from it. CISQ's framing is the same at national scale: "preventing TD or removing it early, is the most cost effective long term strategy."
Discovery output is now agent input
This is the part that has genuinely changed since 2024, and it is why discovery is worth more now than it was then, not less.
DORA describes the emerging practice plainly: in spec-driven development, "developers refine user needs and constraints into detailed documentation (specs) before writing code. This documentation becomes the source of truth for AI agents, ensuring that generated code is constrained by actual user requirements rather than just generic patterns."
Microsoft's GitHub Spec Kit gives the practice a concrete seven-step lifecycle: Constitution to define principles and guardrails, Specify to capture requirements and acceptance criteria, Clarify to resolve ambiguity and edge cases, Plan to translate intent into architecture and constraints, Tasks to break work into implementation-ready units, Implement using AI, and Validate against the spec. The first four steps are discovery. The tooling has simply made the output machine-readable.
Microsoft reports a measured outcome from one brownfield project that adopted the approach: by capturing a repeated onboarding pattern in parameterised specs and documenting only the deviations per new asset type, the team moved to a configuration-driven model that "reduced onboarding time from 2-3 weeks to a few days." That is Microsoft's own result on its own project, not a general benchmark, but it shows what the artefact is for. The spec is not paperwork. It is the thing that makes the tenth instance cheap.
Two practical notes if you are handing discovery output to agents. Write acceptance criteria as assertions a test can express, because that is what an agent can verify itself against. And keep the spec versioned in the repository next to the code rather than in a document store, so a change to intent shows up in a diff. Getting that habit right is most of what an AI coding agent rollout and governance exercise is actually about.
Microsoft's own summary of the lessons is worth keeping on the wall: "Alignment is a team habit, not just a tooling choice", "Planning has an outsized impact on implementation quality", and "Not every change needs the full lifecycle, so adoption should be right-sized."
When to skip discovery
Three weeks is the wrong answer often enough that it is worth saying so.
Skip it when the build is small and reversible, and a working version costs less than the analysis would. Skip it when the requirement is a single well-understood integration into a system you already own. Skip it when the real question is market demand rather than feasibility, in which case a landing page and a waitlist answer it faster and cheaper than any engineer can. And compress it, rather than skipping it, when a hard external deadline governs the release: a one-week version that settles the slice list, the riskiest integration, and the data model is worth far more than nothing.
Discovery earns its three weeks when at least two of these are true: multiple integrations you do not control, an existing system with undocumented behaviour, personal or regulated data, more than one stakeholder group with different definitions of success, or a fixed budget that has to survive a scope argument. If none of those apply, build the thin slice and learn from it. The related decisions of rewriting against refactoring a legacy mobile app and rebuilding a no-code product for production both start from the same discovery output, which is why doing it once serves several decisions.
India-specific considerations
Two things make discovery weigh differently for teams building from or into India.
Data classification is a design input, not a review step
The Digital Personal Data Protection Act 2023 makes the data fiduciary accountable for personal data processed on its behalf. In a discovery sprint that translates into concrete week-one work: list every field the product collects, mark which are personal data, decide where each is stored and which third parties see it, and record who signs off. Retrofitting that after the schema is built is the expensive version. A discovery output that names the data flows is also what makes any later data residency and DPDP cloud architecture decision a short conversation rather than an audit.
Note the honest limit of a claim like this. Designing aligned with DPDP requirements is not the same as being certified against anything, and no engineering partner can hand you compliance. What discovery can give you is a documented data map and a named accountable owner, which is what a regulator or an enterprise procurement team will ask for first.
Device and network floors decide the architecture
An app that will be used across Indian cities has to work on older Android builds and on intermittent connectivity, which changes the architecture rather than the polish. Offline data synchronization, conflict resolution and a stated device floor belong in the week-two non-functional targets, because each one has an architectural consequence. Deciding them in week two is a design choice; discovering them in month four is a rewrite.
For teams weighing where to build at all, the same discovery output feeds the India against US app development cost comparison and the GCC against product partner build decision, because both of those turn on scope clarity more than on rate cards. The wider technical context sits in the enterprise mobile app development guide.
FAQ
How eCorpIT can help
eCorpIT runs discovery as engineering work rather than a sales exercise: senior engineers call your real integrations, spike the risk that would hurt most, write acceptance criteria a test can express, and hand back a versioned spec your team owns whether or not we build it. As a CMMI Level 5 and ISO 27001:2022 certified organisation, we design that output aligned with DPDP Act 2023 requirements, with the data map and accountable owner written down in week one rather than discovered in an audit. Founded in 2021 and based in Gurugram, we work as a multi-disciplinary organisation across product, engineering and QA, with partnerships including AWS, Microsoft and Google. If you are about to commission a build and want the scope settled before the contract, talk to our engineering team.
References
- DORA capability: User-centric focus, Google Cloud DORA, last updated 12 January 2026
- DORA Research 2025: State of AI-assisted Software Development, Google Cloud DORA
- Accelerate State of DevOps Report 2024, Google Cloud DORA
- DORA research archive, Google Cloud DORA
- Spec-Driven Development: A Spec-First Approach to AI-Native Engineering, Apoorv Gupta, Microsoft for Developers, 10 June 2026
- github/spec-kit toolkit, GitHub
- The Cost of Poor Software Quality in the US: A 2022 Report, Consortium for Information and Software Quality, November 2022
- CISQ technical reports and guidance, Consortium for Information and Software Quality
- DORA capability: Working in small batches, Google Cloud DORA
- DORA capability: Test automation, Google Cloud DORA
- DORA capability: Platform engineering, Google Cloud DORA
- DORA metrics guide, Google Cloud DORA
- DORA AI Capabilities Model report, Google Cloud DORA
Last updated: 8 August 2026.
