How to Validate a Mobile Idea Before You Spend $20k on a Build

Most mobile app failures don't happen during the build. They happen in the two weeks before the build, when nobody slowed down to ask the right questions. Then $20,000 to $200,000 gets committed to a product the market didn't want, and the founder finds out at week 16 instead of week 2.

We charge $4k–$10k for a discovery engagement specifically to prevent that. It's not a sales call. It's two weeks of paid work that ends with one of three answers: build this, build something different, or don't build a mobile app at all. Here's what we do during those two weeks, and how you can do a version of it yourself before you sign a build quote.

What "validation" actually means at this stage

When founders say they want to validate their idea, they usually mean one of two things:

1. Will anyone use this? (demand validation)
2. Can this be built profitably? (technical and business validation)

Both matter, but they have different methods. Validating demand is interviews and lightweight prototypes. Validating buildability is architecture review, integration checks, and cost modeling. Skipping either is how $20,000 disappears.

Week 1: demand validation (about 25 hours of work)

The goal of week 1 is to talk to 8–12 of your target users and write down what they actually do today.

The interview script is not "would you use an app like this." Everyone says yes to that question and almost nobody actually downloads. The script is:

• What do you do today when [the problem your app solves] happens?
• What's broken about the way you do it now?
• What have you tried that didn't work?
• If you had a magic wand, what would change?

Notice the script doesn't mention your app. You're trying to find out whether the problem is real and painful enough that someone would change their behavior. If the answer to "what do you do today" is "nothing, it's not really a problem," your app is going to struggle no matter how good the build is.

We've ended discovery engagements with the recommendation not to build the app twice in the last two years. Both clients thanked us. One pivoted to a SaaS web tool that shipped in six weeks. The other realized they didn't actually need software, they needed a part-time hire.

Want to skip the DIY version and have us run discovery for you? Book a two-week discovery engagement and we'll deliver a feature list, technical recommendation, and fixed quote.

Week 1, continued: the smoke test

Interviews tell you whether the problem is real. A smoke test tells you whether people will actually do something to solve it.

The cheapest smoke test for a mobile app is a landing page with a clear value prop and a "Download" button. The button doesn't have to go anywhere — it can go to a "coming soon" page that captures emails. Run $200 of paid traffic from the audience you interviewed in week 1. Track:

• Click-through rate on the Download button. Below 5% means the value prop isn't landing.
• Email capture rate after the click. Below 30% means people clicked but lost interest immediately.
• Cost per email captured. This is your earliest read on whether paid acquisition will work post-launch.

This whole exercise costs $200–$500 and a weekend. It tells you more about whether to build the app than three more weeks of internal discussion.

Week 2: technical and business validation

Once demand is real, the question shifts to: can this be built in a way that makes business sense?

This is where things get less DIY and more "you probably want experienced engineers in the room." But you can do a first pass on your own.

Map the integrations. What other systems does the app need to talk to? Payments (Stripe, PayPal, Apple Pay), auth (your existing user store or a third-party like Auth0), push notifications, analytics, your back-end API, file storage, third-party data providers, location services. List every one. Each is a sprint of work and a potential point of failure.

Identify the hard part. Every app has one or two technical things that are 10x harder than the rest. Real-time chat. Video processing. Offline-first sync. Audio mixing (this is what made Cerebyte non-trivial — playing audio derived from EEG brain-activity recordings needed a Dart-side engine that didn't exist). If you don't know what your hard part is, you haven't scoped the project. We'll usually identify it for you in week 2.

Model the unit economics. If this is a B2C app, what's the most you can spend acquiring a user and still be profitable? What's the lifetime value? If you don't know within a 2x range, you're not ready to commit a build budget — you're committing to fundraising. Different problem.

Decide native vs. cross-platform. This decision used to be a religion. Now it's mostly an honest tradeoff. Native iOS + Android is faster at runtime, has earlier access to OS features, and costs more to build (two codebases). Flutter and React Native are 60–80% of the iOS experience at 50–60% of the build cost, plus a single codebase for maintenance. We pick per project — there's no universal right answer.

What you should have at the end of week 2

A decision-quality artifact, not a deck.

1. A 1-page market validation summary: who you talked to, what you learned, what the smoke test said.
2. A 1-page feature list, prioritized v1/v1.5/v2. Every feature is either in v1 or it isn't.
3. A 1-page technical recommendation: stack, key integrations, the hard part, build-time estimate.
4. A fixed quote and timeline, sprint by sprint.

If you can't produce all four after two weeks, you're not ready to build. Spend two more weeks before you spend $20,000.

The thing most founders skip

You'll be tempted to skip week 1. The interviews feel slow. The smoke test feels like a distraction from "the real work." You'll tell yourself you already know your users.

You almost certainly don't know them as well as you think. The interviews surface assumptions you didn't know you were making. The smoke test tells you whether the language you've been using to describe the product actually lands. Both are cheaper than building the wrong app.

Founders who skip week 1 are not bad founders. They're founders who've been thinking about this idea for 18 months and are sick of thinking and want to move. We sympathize. We still won't quote you a build without it.

A short worked example

A B2C founder came to us last year wanting a "social network for indoor climbers." Discovery week 1 surfaced three things:

• Climbers already had three apps they used (Mountain Project for route info, Strava for tracking, Instagram for social). They didn't want a fourth.
• The actual pain they described was finding climbing partners at their gym — a local matchmaking problem, not a global social-network problem.
• A landing page testing both framings got 11% CTR on the partner-matching version vs. 1.4% on the social-network version.

We delivered a discovery report recommending a much smaller, gym-partnered tool focused on partner matching, not the broader social product. Build budget went from $180k to $55k. The founder shipped in 9 weeks. The product has 4,000 monthly active users at six months — modest but profitable. The original $180k build would have launched a product almost nobody wanted.

That's the validation engagement paying for itself 30x over.

If you'd rather not do this alone

The DIY version of this is doable. The version we run is faster, surfaces more, and gives you a build-ready artifact at the end. Book discovery here — $4k–$10k, two weeks, a real recommendation. Worst case, you've spent a couple thousand dollars to avoid spending twenty.