Running a Technical Discovery Phase: How to Scope Engineering Projects Before Committing Budget and Timeline

The pattern is familiar. A founder or product leader comes to an engineering team with a project idea, a rough budget, and a timeline. Engineering says yes, builds for three months, and delivers something that is 60% of what was described, over budget, and three weeks late. The post-mortem reveals the real problem: nobody knew what they were building until they were already building it.

The fix is a technical discovery phase. Not a sales process. Not a requirements document. A structured, time-boxed investigation that surfaces what you actually know, what you do not know, and what those unknowns cost.

This is what that looks like in practice.

---

What Discovery Actually Delivers

Before describing the process, it is worth being precise about what a discovery phase produces and what it does not.

A discovery phase delivers:

• A clear statement of what is technically feasible within a given constraint set (budget, timeline, existing infrastructure)
• An architecture proposal with identified tradeoffs
• An effort estimate with explicit confidence levels per work stream
• A list of risks ranked by likelihood and impact, with mitigation strategies or kill criteria for the most serious ones
• A prototype or spike that validates one or two high-uncertainty assumptions

A discovery phase does not deliver:

• A production-ready implementation
• A guarantee that the estimate will hold
• A substitute for experienced judgment during the build phase
• A complete list of requirements (that is the product manager’s job)

The last point matters most. Discovery phases fail when they become requirements-gathering exercises. The job of discovery is to evaluate technical feasibility and risk, not to define product scope. If product scope is still undefined when discovery starts, that is a red flag worth naming immediately.

---

The Four Core Activities

1. Architecture Spike

An architecture spike is a focused investigation into the technical approach. The goal is to answer: given what we know about the requirements, what are the two or three plausible architectures, and what are the forcing functions that would drive the choice between them?

A spike is not a prototype. You are not building features. You are exploring the structural decisions: how data flows, where state lives, what the integration surface looks like, which third-party dependencies are load-bearing.

Document the spike as a decision tree, not a recommendation. Something like:

// Example: Architecture decision tree as a typed document
type ArchitectureOption = {
  name: string;
  description: string;
  constraints: string[];        // What must be true for this to work
  forceFactors: string[];       // What forces you toward this option
  tradeoffs: {
    benefit: string;
    cost: string;
  }[];
  estimatedComplexity: "low" | "medium" | "high";
};

const architectureOptions: ArchitectureOption[] = [
  {
    name: "Monolithic API with job queue",
    description: "Single deployed service handles all business logic; background jobs via BullMQ or similar",
    constraints: [
      "Single team owns the entire service",
      "Vertical scaling is acceptable until ~50k req/min",
    ],
    forceFactors: [
      "Team size under 8 engineers",
      "No existing microservice infrastructure",
      "12-week delivery target",
    ],
    tradeoffs: [
      { benefit: "Lowest operational overhead", cost: "Harder to scale individual components later" },
      { benefit: "Fastest to build initially", cost: "Coupling risk as codebase grows" },
    ],
    estimatedComplexity: "medium",
  },
  {
    name: "Event-driven microservices",
    description: "Separate services per bounded context communicating via message bus",
    constraints: [
      "Kafka or equivalent already running in infrastructure",
      "Team has prior experience with distributed tracing",
    ],
    forceFactors: [
      "Multiple teams working in parallel on the same system",
      "Different scaling profiles per service",
    ],
    tradeoffs: [
      { benefit: "Independent deployment and scaling", cost: "Significant infrastructure overhead" },
      { benefit: "Clear team ownership boundaries", cost: "Distributed system failure modes" },
    ],
    estimatedComplexity: "high",
  },
];

The spike document should conclude with a recommended option and a clear statement of which assumptions that recommendation depends on. If those assumptions do not hold, the recommendation changes.

2. Risk Assessment

Risk assessment is where most scoping efforts are weakest. Teams list risks, assign vague labels like “medium,” and move on. That is not useful.

A useful risk assessment maps each risk to three things: the likelihood of it occurring, the impact if it does, and the cost of mitigating versus accepting it.

Risk	Likelihood	Impact	Mitigation	Cost to Mitigate	Recommended Action
Third-party API rate limits block core feature	High	Critical	Cache responses + queue requests	2 days	Mitigate before build
Data migration takes 3x estimated time	Medium	High	Run migration in parallel with build	3 days	Spike in discovery
Compliance requirement surfaces mid-build	Low	Critical	Legal review before architecture locks	1 day	Do it now
Team member leaves during project	Medium	Medium	Document decisions + pair on key components	Ongoing	Accept, monitor

The “Cost to Mitigate” column is what makes this actionable. A risk with a 1-day mitigation cost and a critical impact has an obvious answer. A risk with a 3-week mitigation cost and a low-probability medium-impact outcome might be worth accepting. The table forces that reasoning to be explicit.

3. Effort Estimation

Effort estimation is not prediction. It is a structured statement of uncertainty. The output should be three numbers: optimistic, expected, and pessimistic, with explicit statements about what assumptions drive each.

Break the work into independent work streams before estimating. This matters because parallelism assumptions are where estimates go wrong. If three engineers can only work in parallel for 60% of the project because of shared dependencies, the timeline is not one-third of the single-engineer estimate.

type WorkStream = {
  name: string;
  owner: string;
  dependencies: string[];        // Other streams that must complete first
  estimate: {
    optimistic: number;          // In engineer-days
    expected: number;
    pessimistic: number;
  };
  assumptions: string[];         // What must be true for this estimate to hold
  unknowns: string[];            // What we don't know yet that could change this
};

const workStreams: WorkStream[] = [
  {
    name: "Authentication and authorization layer",
    owner: "Backend",
    dependencies: [],
    estimate: { optimistic: 3, expected: 5, pessimistic: 10 },
    assumptions: [
      "Using an existing auth provider (Auth0, Clerk, etc.)",
      "No custom permission model beyond RBAC",
    ],
    unknowns: [
      "Whether existing user data needs to be migrated from a legacy system",
    ],
  },
  {
    name: "Core data model and migrations",
    owner: "Backend",
    dependencies: [],
    estimate: { optimistic: 4, expected: 7, pessimistic: 14 },
    assumptions: [
      "Schema is stable before implementation starts",
      "No partitioning or sharding required at launch",
    ],
    unknowns: [
      "Whether multi-tenancy isolation needs to be enforced at the DB level",
    ],
  },
  {
    name: "API surface (REST/GraphQL)",
    owner: "Backend",
    dependencies: ["Core data model and migrations"],
    estimate: { optimistic: 6, expected: 10, pessimistic: 18 },
    assumptions: [
      "API contract is agreed before implementation starts",
      "No pagination beyond cursor-based",
    ],
    unknowns: [
      "Whether realtime subscriptions are required",
    ],
  },
];

Roll up the work streams into a project estimate only after accounting for dependencies. The critical path is not the sum of all estimates. It is the longest chain of dependent work.

4. Prototype Validation

Not every project needs a prototype. Build one when there is a high-uncertainty assumption that the entire architecture depends on. Not to demonstrate the product. To collapse a specific unknown.

Good candidates for prototyping during discovery:

• A third-party API you have never used that is on the critical path
• A data processing pipeline where throughput requirements are unclear
• An AI/ML component where latency or accuracy at production scale is unknown
• A legacy system integration where the documentation is wrong or missing

Bad candidates:

• UI screens that exist mainly to validate product ideas (that is product discovery, not technical discovery)
• Features that are well-understood and low-risk just because they are large

A prototype built during discovery should be throwaway code. Its job is to produce data: latency numbers, API response shapes, throughput under load, integration failure modes. Document the results, then delete the code. If the team feels reluctant to delete it, that is a sign the prototype has grown into something it was not supposed to be.

---

Structuring the Deliverables

Discovery produces three documents. Each has a specific audience.

Technical Assessment Document

Audience: the engineering team and any technical reviewers.

Content: the spike findings, the full risk register, the per-work-stream estimates with assumptions and unknowns, and the prototype results. This is the source of truth for every technical decision made during the build phase.

Keep it in version control alongside the code. An architecture decision that lives in a Google Doc nobody can find is not a decision; it is a rumor.

Architecture Proposal

Audience: anyone who needs to understand what is being built and why.

Content: one or two pages. The recommended architecture, the two or three alternatives considered, the forcing functions that drove the recommendation, and the decisions that will need to be revisited as requirements change. Include a simple diagram. Skip the details that only matter to implementers.

This document is not exhaustive. It is the minimum context someone needs to evaluate whether the recommended approach is sound.

Implementation Roadmap with Milestones

Audience: founders, product managers, and other stakeholders who need to plan around the build.

Content: a timeline expressed in milestones, not tasks. Each milestone is a testable outcome: “API authenticated and returning data for primary use case” is a milestone. “Backend sprint 2 complete” is not.

Include confidence levels per milestone. If the first milestone is well-understood and low-risk, say so. If a milestone in month two depends on an integration that has never been tested, say that too.

---

Communicating Findings to Non-Technical Stakeholders

The technical assessment document is not what you bring to a founder conversation. You need a translation layer.

A few principles that hold across audiences:

Lead with outcomes, not architecture. “The system can support 10,000 concurrent users at launch without requiring a rearchitecture” lands differently than “we are using a horizontally scalable stateless service layer.” Same information. Different utility for a non-technical reader.

Express uncertainty in cost, not confidence percentages. “We have a 70% confidence in the timeline” means nothing to someone evaluating a budget. “There is one unknown in the data migration that could add 2-3 weeks and $15,000 to the project” is a decision they can act on.

Name the decisions you are asking them to make. Discovery surfaces forks in the road. Stakeholders should not have to infer what you need from them. State it directly: “We need a decision on the compliance requirement by end of this week or the architecture recommendation changes.”

Separate what is known from what is estimated from what is unknown. Stakeholders often treat all statements from engineering as equally certain. Making the distinction explicit prevents misplaced confidence and the arguments that follow when estimates miss.

---

Red Flags That Should Kill a Project Before It Starts

Discovery sometimes concludes with a recommendation not to build. That is a legitimate outcome and one of the most valuable things the process can produce.

Specific patterns worth calling out explicitly:

The requirements are owned by someone who will not commit to them. If the person defining requirements is unavailable, unwilling to make decisions, or expects to change scope freely during the build, no estimate will hold and no delivery will satisfy. This is not an engineering problem.

The third-party dependency is not production-ready. If the critical-path integration is in beta, poorly documented, or run by a two-person team with no SLA, that risk does not have a mitigation strategy that fits inside the project budget. Document it and surface it to stakeholders before they commit.

The data model has not stabilized and nobody is responsible for stabilizing it. Building on an unstable schema is expensive. If there is no product owner who can freeze the data model before implementation starts, the cost of iteration gets absorbed into the engineering estimate without being visible.

The project is solving a problem that has already been solved by something buyable. This one requires some diplomatic care, but if discovery reveals that a $200/month SaaS product does 80% of what is being scoped for a six-month custom build, that is information the decision-maker needs.

The team lacks a critical skill and there is no plan to acquire it. A project that requires real-time infrastructure expertise, and a team that has never built with WebSockets or CRDT-based sync, is not blocked. But the estimate should reflect the learning curve, and if the team is not comfortable naming that cost, it will show up as schedule slip instead.

---

Pricing Discovery as a Service

For teams or consultants offering discovery as a paid engagement, the pricing structure matters because it shapes the incentives on both sides.

Discovery should be priced independently of the build. Not as a discount toward the build, and not as “free” to win the build engagement. When discovery is free or bundled, the incentive is to complete it quickly and confirm that the build should proceed. That is the opposite of what discovery is for.

A well-scoped discovery engagement for a medium-complexity project typically runs 1-2 weeks of senior engineering time. At a consulting rate of $150-250 per hour for a senior engineer, that translates to $6,000-$20,000 depending on complexity and team size. That range should be presented to clients as a function of scope: a discovery engagement for a greenfield SaaS product with unclear data model and third-party integrations is at the high end. A discovery engagement for a well-specified feature addition to an existing system is at the low end.

The client needs to understand what they are paying for: not a guarantee, but a reduction in risk. The alternative to a $10,000 discovery engagement is frequently a $300,000 build that delivers the wrong thing.

---

Concrete Example: Marketplace Payment Integration

A founder wants to add an escrow-based payment system to an existing marketplace. They have a budget of $120,000 and a 16-week timeline. Here is what a discovery phase looks like for this project.

Week 1: Architecture spike and risk identification

The engineering team spends two days mapping the existing marketplace’s data model, authentication surface, and current third-party integrations. They identify that the marketplace uses a monolithic Rails application, has no existing queue infrastructure, and currently processes no financial data.

The spike surfaces two viable approaches: direct Stripe Connect integration with Stripe handling escrow logic, or a custom escrow layer built on top of standard Stripe charges. The third option (building payment infrastructure from scratch) is immediately eliminated as outside the risk tolerance of the budget.

The risk register identifies three critical risks: PCI DSS scope expansion if the custom escrow layer is chosen, webhook idempotency requirements that the existing codebase has no pattern for, and a missing dispute resolution flow that is legally required but not in the original requirements.

Week 1 conclusion: Recommend Stripe Connect with Stripe’s managed escrow. The custom escrow layer adds 3-4 weeks of build time and expands compliance scope. The dispute resolution gap is flagged as a requirements issue that must be resolved before architecture locks.

Week 2: Effort estimation and prototype

The team builds a prototype connecting the existing authentication system to Stripe Connect’s account creation flow and verifying that the webhook event sequence for a complete transaction (hold, capture, release) works against Stripe’s test environment. The prototype takes one day and confirms the integration is feasible with no surprises.

Estimation produces three work streams (auth/account creation, transaction lifecycle, admin and dispute tooling) with the following totals:

Scenario	Timeline	Cost at $150/hr, 3-engineer team
Optimistic	10 weeks	$72,000
Expected	13 weeks	$93,600
Pessimistic	18 weeks	$129,600

The pessimistic scenario puts the project over the $120,000 budget. Discovery surfaces this before the build starts. The founder can now choose: reduce scope (remove admin tooling from v1), increase budget, or extend the timeline. All three options were available before discovery. Discovery made the choice visible.

---

Discovery Checklist

Before closing out a technical discovery phase, verify the following:

Architecture

• At least two architectural options documented with explicit tradeoffs
• Recommended option includes a statement of the assumptions it depends on
• Third-party integrations have been tested at least minimally (API keys work, rate limits documented, auth flow verified)

Risk Assessment

• Each risk has an owner, a likelihood, an impact level, and a recommended action
• At least one risk has been escalated to stakeholders as a decision they need to make
• Any compliance or legal risks have been explicitly flagged for non-technical review

Estimation

• Estimates are expressed as optimistic/expected/pessimistic, not a single number
• Each work stream estimate lists the assumptions that drive it
• Dependencies between work streams are documented and the critical path is identified

Prototype (if applicable)

• Prototype answers a specific question (document the question and the answer)
• Prototype results are recorded before the prototype is discarded
• No production-bound code was written during the prototype phase

Deliverables

• Technical assessment document is in version control
• Architecture proposal is one to two pages and written for a non-specialist reader
• Implementation roadmap uses milestones with testable outcomes, not task lists
• Stakeholder communication distinguishes known facts, estimates, and unknowns

Go / No-Go

• All critical-path requirements have an owner who is empowered to make decisions
• No third-party dependencies are in a state that would block production launch
• The data model is stable or there is a clear owner responsible for stabilizing it
• The build recommendation (or no-build recommendation) is in writing

---

The most expensive discovery phase is cheaper than a three-month build that reveals at week ten that the original approach was wrong. The goal is not to eliminate uncertainty. It is to make uncertainty visible before it becomes sunk cost.