How to Validate Your Startup Idea Before Spending a Dollar on Development
You have an idea you can't stop thinking about. You've sketched screens on napkins, described it to friends over dinner, maybe even started looking at developer rates. Stop right there. Most founders I work with come to me after they've already spent $5k-$15k building something nobody wanted. That money is gone. The fix is embarrassingly simple: validate before you write a single line of code.
I'm going to share the exact steps I give every founder who books a call with me. Six years of building MVPs for non-technical founders across Mexico, LATAM, and the US. These steps work.
Talk to Real People (Not Your Friends)
The least exciting part of validation: conversations. Not surveys. Not polls on Twitter. Actual, uncomfortable, one-on-one conversations with people who have the problem you think you're solving.
Why uncomfortable? Your friends will tell you your idea is great. Your mom will tell you it's brilliant. Those conversations are worthless. You need strangers who live with the problem daily. Ask them how they currently deal with it.
Don't pitch your solution. Ask about their pain. Questions like "Walk me through the last time this happened" or "What did you try before giving up?" will teach you more in 30 minutes than a month of Googling market research reports.
Aim for 15-20 conversations. If you can't find 15 people who have this problem, that's your answer. The market might not exist, or the problem doesn't hurt enough for people to pay for a solution.
What You're Listening For
You want specifics: how often the problem happens, what they've already tried, how much time or money it costs them. If someone says "yeah, that's annoying but I just use a spreadsheet," that's useful data. It tells you your competitor is a free spreadsheet, and your product needs to be significantly better to justify its price.
Run a Smoke Test Before You Build
Once you've confirmed the problem is real, test whether people will actually commit to a solution. Most of these tests are simpler than you think.
The landing page test. Build a single page that describes your product as if it already exists. Add a "Join the waitlist" or "Get early access" button. Run $50-$100 in ads targeting your audience. If nobody signs up, you've saved yourself months of development. If people do sign up, you now have a list of early users to talk to.
The concierge test. Deliver your service manually to 5-10 people. No code. No app. Just you, doing the work behind the scenes. One of my clients wanted to build a CRM for small media agencies. Before we wrote any code for what became Social Monkey Media CRM, the founder spent two weeks managing client data in Notion for three agencies. She learned exactly which features mattered and which ones she'd imagined were important but nobody used. When we finally built it, the project took three weeks instead of eight.
The pre-sale test. Ask people to pay before the product exists. Hardest test, most honest one. If someone hands you money for something that doesn't exist yet, you've found real demand. If they say "sounds cool, let me know when it's ready," they're being polite. Polite doesn't pay your server bills.
Define What You're NOT Building
Founders skip this step, and it's the one that saves the most money. After your validation conversations and smoke tests, you should have a clear picture of what matters. Now make a list of everything you're not building in version one.
I've seen the same pattern dozens of times. A founder validates a real problem, gets excited, then adds fifteen features to the spec because "users might also want this." They won't. Not yet.
When I built CherryStripes, a women's wellness app, the founder's original vision included journaling, cycle tracking, breathwork, calming music, live chat, a shopping list, and a challenge-a-friend feature. We launched the MVP in six weeks. The first 20 real users told us live chat and the shopping list were useless. Never touched them. But that "challenge a friend" feature the founder had almost cut? That's what took the app from 20 users to over 100 in three weeks.
Founders don't have bad instincts. But you genuinely cannot know which features matter until real people use your product. Every feature you add to v1 without validation is a bet, and most of those bets lose.
Put a Number on "Validated"
Before you start any of this, decide what success looks like. "I'll know it when I see it" is not validation criteria. Set specific targets.
- Landing page: 100 visitors, 10% sign up, or the idea needs rethinking.
- Conversations: 15 interviews where at least 10 people describe the problem without you prompting it.
- Pre-sales: 5 people pay a deposit, or you go back to the drawing board.
Adjust these numbers for your market. But write them down before you start, because confirmation bias is brutal. Without clear targets, you'll convince yourself that three lukewarm sign-ups mean you've found product-market fit. You haven't.
The Real Cost of Skipping Validation
Skipping validation is the most expensive mistake a non-technical founder can make. Not because development costs are high, but because you lose something you can't buy back: time. Three months building the wrong thing is three months you didn't spend building the right thing.
Validate with conversations, smoke tests, and clear success criteria. Two to four weeks, almost zero cost. The product you build afterward will be sharper, smaller, and far more likely to survive contact with real users.
Not sure which path is right for your project? Describe your idea and I'll give you my honest take — no sales pitch. Get in touch
Launching Code Team