Startup Discovery Phase: Plan Your Timeline and Budget

To plan a startup discovery phase, define the decision you need to make, agree on usable deliverables, and build a timeline and budget around the required work. Before commissioning the engagement, check which roles, research costs, technical investigations, and reviews the proposal includes.

This guide is for founders preparing a discovery brief or reviewing a proposed scope before funding an MVP build. It focuses on planning the engagement: cost, duration, deliverables, founder involvement, and the decision at the end. For definitions and the benefits of the approach, see our lean project discovery guide.

Executive Summary

Start with one decision and list the outputs needed to support it. Use the pricing references and planning ranges below to ask better questions, then agree on a project-specific scope, spending limit, schedule, and responsibilities. Compare discovery fees separately from the cost and timeline of the subsequent MVP build.

The article includes 2–4-week discovery planning references, a worked three-week schedule, agency pricing examples, and a 4–8-hour weekly founder allocation. These figures need to be matched to the included work and dependencies. Discovery should leave you able to approve a limited build, investigate further, change direction, or stop.

Prepare a Discovery Brief Before Requesting a Quote

Write the decision before listing activities. For example: should we invest in an MVP for independent property managers, and which maintenance workflow should it support first? That question is more useful than a brief asking for market research, a design system, and an architecture diagram without explaining why.

Separate assumptions about the customer problem, adoption, business model, usability, and technical feasibility. Rank them by how much a wrong assumption would change your next investment. You may need research before committing to a product; you may also need a small technical experiment before designing the entire workflow.

Agree on what evidence would change the plan. Record the target audience, current alternatives, available research, budget limit, decision date, and dependencies. Discovery can improve your understanding of these issues, but it cannot remove every uncertainty or establish product-market fit before real use.

Brief item	What to record
Decision	What the engagement should help you decide, and by when.
Audience and problem	The first user segment, buyer if different, and core workflow.
Existing evidence	Research, analytics, prototypes, and technical notes that can be reused.
Constraints	Spending ceiling, stakeholder availability, system access, and dependencies.
Required outputs	Deliverables, review points, rights and access, and handover needs.

Agree on Discovery Deliverables and Handover

Agree on deliverables before starting. Not every project needs all of the following, and format matters less than whether another person can understand the evidence and use it.

Deliverable	What makes it useful
Research summary	Audience, methods, findings, sources, and limitations are clear.
Assumption and risk log	Evidence is separated from assumptions, with unresolved questions and owners.
Scope and prioritized backlog	The core journey, intended outcome, exclusions, and priorities follow from findings.
Prototype and test notes	Editable files, tested tasks, observed issues, revisions, and limitations are included.
Technical feasibility notes	Dependencies, checks performed, options, constraints, and remaining investigations are recorded.
Recommendation and estimate	Next decision, scope assumptions, cost range, dependencies, and review points are explicit.

For a handover, specify editable files, access, rights to use the material, and a walkthrough. Include participant information only under the agreed consent and data-handling arrangements. A bundle of screens without the research context may leave the next team repeating important work.

Specify prototype detail in the scope. The examples below illustrate a user flow and wireframes that can support a handover; they are not a requirement to design every screen or commission a complete visual identity during discovery.

Plan Your Startup Discovery Phase Budget

The agency figures below provide concrete budget references for the services described. Compare the included work before comparing the amounts: a consultation or proposal is not equivalent to a standalone discovery package. Confirm the current scope, fees, and delivery terms in a written proposal.

Agency	Discovery pricing reference	Timeline or scope
You are launched	$2,980 for a standalone discovery package.	2-3 weeks delivery for the package scope.
Rootstrap	$10,000–$20,000 for discovery.	2–4 weeks for a technically involved engagement.
Goji Labs	$15,000 for a Product Strategy Sprint.	14-day sprint; further UX discovery may be part of development.
Chop Dawg	$0 for the initial consultation and development plan; $50–$99/hour for discovery activities billed within development.	A free proposal is different from a paid research, UX, and technical discovery engagement.

Budget for the agreed investigation rather than a generic discovery package. The main drivers are team roles and effort, recruitment and participant incentives, prototype depth, technical experiments, revision rounds, and handover. State what your team supplies and which third-party expenses are separate.

Budget item	What to clarify
Research and synthesis	Questions, audience coverage, activities, analysis, and reporting effort.
Recruitment	Who finds and screens participants, incentives, and handling of cancellations.
Design and testing	Workflow coverage, prototype fidelity, test sessions, and revision rounds.
Technical work	Specialists, system access, experiments, environments, and external services.
Coordination and handover	Workshops, progress reviews, documentation, editable files, and walkthrough.

Ask for a task and role breakdown for your own engagement. Check that the proposed hours can cover the promised outputs. A full investigation across several segments, detailed design, and complex technical work may need substantially different effort. Keep the discovery budget separate from the production MVP budget.

For fixed-price work, define scope, inputs, deliverables, exclusions, and changes. For time and materials, agree on rates, allocation, reporting, and approval of extra work. A time box limits duration; it does not create a financial cap unless a spending ceiling is agreed.

Keep the discovery fee separate from implementation and operations. Our MVP development cost guide covers the wider build budget. Compare the proposed discovery work here before deciding how much to commit to that next stage.

Plan Your Startup Discovery Timeline

As a planning reference, a standalone discovery engagement can take 2 weeks, while a more technically involved engagement may need 2–4 weeks. Goji Labs’ Product Strategy Sprint is described here as a 14-day sprint. These durations cover the stated discovery scope; recruitment, access delays, and additional investigation can change the calendar.

Plan the duration from the work and dependencies. Participant recruitment, stakeholder availability, technical access, and review turnaround can take longer than the scheduled workshop or interview. Distinguish calendar time from team effort: a two-week window does not mean every role works full time for two weeks.

The schedule below is a hypothetical three-week plan for one customer segment and one core workflow. It assumes recruitment starts before the first week, participants are available, and technical access is ready. It is an illustration, not an industry average or a delivery promise.

Period	Illustrative work	Review point
Before week 1	Confirm the decision, existing evidence, participants, access, scope, and responsibilities.	Check that the team can start meaningful investigation.
Week 1	Review evidence, investigate workflows, and begin consequential technical checks.	Decide whether the problem and audience need reframing.
Week 2	Synthesize findings, narrow scope, and create and test a focused prototype.	Review observed issues and decide what needs another iteration.
Week 3	Resolve priority gaps, revise the prototype, document risks, and prepare next-step options.	Choose whether to build, test further, change direction, or stop.

A smaller question with existing evidence may need less work. Several user groups, difficult recruitment, or complex integration risks may require more time or a different sequence. Set review points so the team can adjust scope rather than promise to complete a full research and design package regardless of what it learns.

Separate Discovery Estimates from the MVP Build

For budgeting, allow for 50–100% variation in an early development estimate and use 85–95% accuracy as a target after discovery. These are planning benchmarks rather than a guaranteed level of accuracy. Provide a development estimate with a range, assumptions, exclusions, dependencies, and a review date. Separate the first build from maintenance, third-party services, and future features. A tightly scoped MVP can be planned around an 8–12-week development window after discovery, subject to confirmed scope, team capacity, and technical dependencies. This is a planning assumption, not a guaranteed launch date. Screen counts alone are not enough to estimate integration complexity or operational work.

Who Participates and What Does the Founder Do?

For planning, allow 4–8 hours per week of founder involvement during a 2–4-week discovery phase. Use this allocation for workshops, research input, prototype reviews, and scope decisions. Confirm the actual calendar with the team and adjust it for the project.

Assign product decision-making, research, design, technical investigation, and coordination to people with the relevant skills. One person may cover several responsibilities in a small engagement. Add domain or operational specialists when their knowledge is needed to assess a consequential constraint.

The founder or delegated product owner supplies context, helps secure user and stakeholder access, reviews findings, and decides priorities. Ask for a calendar of required sessions and feedback deadlines. Record who can resolve disagreements and approve changes so the team does not wait for decisions.

If you are commissioning external help, our software development partner guide covers the broader provider relationship. This article focuses on planning the work itself. Compare any proposed idea-stage services against your decision, scope, and required outputs.

Choose the Activities Your Discovery Budget Must Cover

Use this checklist to assess the proposed work. Include an activity when it resolves a consequential gap; reuse relevant existing evidence to avoid paying to recreate it. The activities can overlap or repeat, so their sequence should follow the questions and dependencies in your brief.

Activity	Include it when…	Ask the proposal to specify
Evidence and market review	The audience, alternatives, or business assumptions need clarification.	Sources to review, current evidence to reuse, and the unresolved questions.
User research	The workflow, problem, buyer, or adoption barriers remain uncertain.	Participant criteria, recruitment owner, methods, analysis, and limitations.
Scope prioritization	The intended MVP is too broad or priorities are unclear.	Core task, intended outcome, exclusions, dependencies, and acceptance criteria.
Prototype and usability testing	The team needs to evaluate a proposed interaction before building it.	Workflow coverage, fidelity, test tasks, participants, and revision rounds.
Technical investigation	An integration, data constraint, or feasibility risk could change the plan.	Access requirements, checks or experiments, specialist effort, and remaining risks.
Synthesis and handover	The findings must support an investment decision or another delivery team.	Recommendation, editable outputs, assumptions, estimate range, and walkthrough.

Methods answer different questions. Nielsen Norman Group’s guide to user interviews explains investigating reported experiences; its overview of usability testing covers evaluating interaction with a design. Require the proposal to explain why the selected method fits the decision. Interviews and prototype tests do not automatically establish willingness to pay.

How to Decide What Happens After Discovery

Review what changed from the initial assumptions. Which questions have enough evidence for a proportionate next investment? Which risks remain, and how expensive would they be to investigate? Ask the team to explain both supporting and contradictory findings.

Outcome	Reasonable next step
Enough evidence for a limited release	Define the smallest useful MVP and its learning goals, with unresolved risks visible.
Usability or scope questions remain	Revise and test the relevant workflow before committing to the full build.
A critical technical assumption is unresolved	Run a focused feasibility investigation before relying on it in the plan.
Evidence challenges the problem or audience	Reframe the hypothesis, gather targeted evidence, or stop further spending.

Treat discovery as a basis for the next decision, not a certificate that the startup is validated. Continue learning during development and after launch. Record why you chose the next step so future product and budget decisions can build on the evidence.

Frequently Asked Questions About Startup Discovery