The Mobile App Discovery Phase: What We Deliver in Two Weeks for $4k–$10k

A two-week discovery engagement costs $4,000 to $10,000. It is, without exaggeration, the most leveraged dollar you'll spend on a mobile-app project. It determines whether the next $20k–$200k goes to building the right product or to rebuilding a wrong one.

Discovery is also the engagement most founders don't understand before they sign. They've been pitched discovery as "we'll get to know your project," which sounds soft and optional. It isn't. Here's exactly what discovery delivers, day by day, and what you should expect to walk out of it with.

What discovery is (and isn't)

Discovery is: paid work, a contractually defined deliverable, and a one-way input into a fixed build quote. By the end of it, you have a feature list, a technical recommendation, a timeline, and a quote. You can take all four and shop them around. We've had clients do that, decide to build in-house, and come back two years later. The work transfers.

Discovery is not: a free sales pitch. A "we'll get on a call and figure out what to do." A pre-build kickoff disguised as planning. Any agency that doesn't charge for discovery is either making the cost back in the build margin or skipping the planning work entirely. Both are bad for you.

The discovery price ($4k–$10k) varies based on scope. A single-platform B2B internal tool with clear users sits at $4k. A two-sided marketplace with complex integrations and undefined audience sits at $10k. Most projects fall in the $5k–$7k range.

Week 1: discovery work in detail

Day 1: scoping the scope. A 90-minute kickoff where we map the rough product surface area. We're not deciding features yet — we're figuring out the size of the project. By the end of day 1 we'll have the rough budget bracket ($20k, $50k, $100k+) and a working hypothesis of the user.

Days 2–3: stakeholder interviews. Typically 4–6 calls with the founder, the founder's existing team, and where possible, 2–3 representative users. The user calls are short (20 min) and follow a script. We're not selling the product to them; we're listening.

Days 4–5: the technical sketch. Our engineering lead writes a one-page technical recommendation. Stack choice, integrations, the hard part (every project has one), the deployment story, the data model. This document is short on purpose — it's a sketch, not a spec.

End of week 1: midpoint review. A 60-minute call where we share what we've learned, the rough feature list, the stack recommendation, and any red flags. If we're going to recommend against building the project, it almost always surfaces here. The two clients we've recommended against in the past two years both heard it at the midpoint, and both thanked us for not letting them spend further.

If a two-week discovery sounds like the right starting point, you can book one here. We'll send a scope and quote within one business day.

Week 2: turning sketch into commitment

Days 6–7: feature list with priorities. We take the rough feature list from week 1 and force every feature into one of three buckets — v1 (must-have for launch), v1.5 (polish for a happy launch), or v2 (later). This is the most important work of discovery. Cuts made on paper now save weeks during the build.

Days 8–9: sprint-by-sprint build plan. The engineering lead writes a sprint breakdown of the proposed v1. Eight to ten sprints (two-week each, so 16–20 build weeks). Each sprint has a clear goal and a clear "done" criterion. Slippage during the build is a function of how unclear the sprint plan was at discovery. Ours is clear.

Day 10: the deliverable bundle. You receive four documents:

Market validation summary (1 page) — who you'll serve, what they need, where the demand signal came from.
Feature list with v1/v1.5/v2 priorities (1–2 pages) — every feature explicitly bucketed.
Technical recommendation (1 page) — stack, integrations, the hard part, the deployment plan.
Build quote and timeline (1 page) — fixed quote against v1, sprint-by-sprint timeline.

Four pages of decision-quality work. Not a 40-page deck. We've seen the 40-page decks; they're impressive and they're a sales artifact, not a build plan.

What "fixed quote" actually means

When we say the build quote is fixed, we mean it. If we quoted $85k for v1 and the build takes us 20 weeks instead of 16, we eat the difference. We don't bill hourly during the build, and we don't issue change orders unless you change scope.

You'll change scope. Every client does, and that's fine. The change order is straightforward: a new feature gets priced, you approve or reject, the timeline updates. The change is your choice, not ours.

What the fixed quote requires from us is that discovery be honest and thorough. If we under-quote because we missed the hard part, we eat that. So we don't miss the hard part. That's what week 2 is for.

What we won't do during discovery

To keep the engagement honest, we set boundaries upfront:

We won't write production code. Sometimes we'll throw together a 50-line proof-of-concept in week 2 if there's a specific technical risk we need to retire (does the audio engine actually run in the background on iOS? does the third-party API support the volume we need?). These are tests, not the start of the build.

We won't design final screens. We might sketch a couple of wireframes for clarity. The design phase happens in the build, paid for separately, where the design system gets built once and reused.

We won't try to upsell you on a bigger build. If discovery surfaces that you actually need a $30k tool rather than a $150k app, we'll say so. We've quoted smaller scopes than the client expected more than once.

What you should bring to discovery

You'll get more value if you arrive with these things ready:

The problem statement in one sentence, without compound clauses. Practice it. ("My app lets X do Y" — not "my app lets X do Y, and also Z, and also...")
3–6 users or potential users we can call. Not your friends. Real people who have the problem.
A real budget number, even if it's a range. "$50k–$80k" is useful. "Whatever it costs" is not.
The hard problem you're worried about. Every founder has one. Tell us upfront. We'd rather de-risk it in week 2 than find it in week 8.

What you should expect not to get

We sometimes get pushback from founders who expected a different deliverable. To set expectations early:

You won't get visual mockups of every screen. Those are part of the build, not discovery.
You won't get a working prototype to demo to investors. If you need that, talk to us — we can scope a focused prototype as a separate engagement, but it's not discovery.
You won't get a market-research report. Discovery is about your product, not about the market category. We'll incorporate market context, but we don't sell a category report.

A short worked example

A SaaS founder came to discovery wanting "an iOS app for our existing web platform." They'd already gotten quotes from three dev shops ranging $120k–$220k.

Week 1 surfaced that 80% of their users only used four features. Week 2 scoped a v1 of exactly those four features, on iOS, with offline support for one specific workflow that mattered most to enterprise customers.

Quote at end of discovery: $58k for v1. Timeline: 14 weeks. The founder shipped on time, on budget, and one of the deferred features got cut later based on actual usage data — saving another $18k they'd have spent in v1.5.

Discovery cost: $5k. Money saved on misallocated v1 scope: ~$60k. Time saved: about 2 months.

The shorter version

Discovery is two weeks, $4k–$10k, four documents at the end. The deliverable is the cheapest piece of high-leverage thinking you'll do in the whole project. It tells you whether to build, what to build, how long it'll take, and what it'll cost — fixed.

If the rest of your $80k+ build budget should be spent on a product, not a rewrite, start with discovery. We'll send a scope and a discovery quote within one business day.