What to Do Before You Build an App (Most Founders Skip This)

← Back to Blog

I've had this conversation more times than I can count. A founder calls me after spending $30,000 and six months building an app — and it's not working. Not because the developers were bad. Not because the idea was bad. But because nobody did the pre-work before a single line of code was written.

Here's everything you should do before you build.

1. Talk to 20 potential users first

Not five. Not ten. Twenty. And not friends and family who'll be supportive — actual strangers who represent your target market. Ask them about the problem you're solving, not about your solution. The goal is to understand the pain deeply enough that you can't build the wrong thing.

The most important question to ask: "What do you currently do when this problem comes up?" Their answer tells you what you're actually competing with.

2. Get someone to pay before you build

This is the single best validation signal in existence. If you can get even one person to put money down for something that doesn't exist yet, you have something real. A landing page with a waitlist doesn't prove demand. A credit card charge does.

"If you can't sell the idea, you can't sell the product."

3. Write the scope document

Before any developer touches your project, you need a scope document that answers:

• What does the app do? (In one sentence.)
• Who is it for? (Specifically.)
• What are the 3–5 core features for version 1?
• What does it NOT do? (Just as important.)
• How does a user flow through the app from start to finish?
• What does success look like after 90 days?

If you can't write this document, you're not ready to build. Developers will fill in the blanks with their own assumptions — and those assumptions will cost you.

4. Get a technical review before hiring

Before you hire any developer or agency, have someone technical review the scope. They'll catch missing requirements, flag technical risks, and tell you if the timeline and budget are realistic. A one-hour review can save you months of rework.

5. Build only the core, and nothing else

Version 1 should do one thing extremely well. Not five things adequately. Every feature you add to v1 doubles your build time and cost, and most of those features will be wrong anyway — because you haven't had real users yet. Build the smallest thing that delivers the core value. Everything else is version 2.

The pre-build checklist

• Interviewed at least 20 potential users
• At least one person has committed money to it
• Written a clear one-sentence description of what it does
• Defined v1 features (maximum 5)
• Written the user flow from sign-up to value
• Had a technical person review the scope
• Have a realistic budget including maintenance
• Know what success looks like in 90 days