Growth & Strategy
Personas
SaaS & Startup
Time to ROI
Short-term (< 3 months)
Last year, a potential client approached me with what seemed like a dream project: build a comprehensive two-sided marketplace platform with a substantial budget. The technical challenge was exciting, it would have been one of my biggest projects to date, and the client was enthusiastic about leveraging the latest no-code and AI tools.
I said no.
But here's the thing - I didn't just turn down the money and walk away. I spent time explaining why their approach was fundamentally flawed and what they should do instead. That conversation taught me more about prototype validation than any framework or methodology ever could.
Most founders get caught up in the excitement of building. They see tools like Bubble, Lovable, and AI platforms and think "finally, I can build my vision quickly and cheaply." They're not wrong about the tools - you can build complex platforms faster than ever. But they're missing the crucial question: should you?
In this playbook, you'll learn:
Why "testing market demand" isn't the same as building an MVP
My hierarchy of prototype validation that saves months of development
The Day 1 validation method that most founders skip
How to know when you're ready to actually build something
Real examples from client conversations that changed everything
This isn't about being anti-building or anti-technology. It's about building the right thing for the right people at the right time. For SaaS founders especially, this mindset shift can be the difference between a profitable launch and an expensive learning experience.
Industry Reality
What Every Founder Hears About MVP Building
Walk into any startup accelerator, browse through Y Combinator's playbook, or attend a founder meetup, and you'll hear the same advice repeated like gospel:
"Build fast, launch quickly, iterate based on feedback."
The industry has standardized around this approach:
Start with an MVP - Build the minimum viable version of your idea
Launch to early adopters - Get your product in front of users as soon as possible
Collect feedback - Analyze user behavior and gather insights
Iterate rapidly - Make changes based on what you learn
Scale what works - Double down on features that resonate
This advice exists for good reasons. The traditional "waterfall" approach of spending years in stealth mode building the "perfect" product has created countless failures. Companies would burn through millions before ever talking to a real customer.
The lean startup movement was a necessary correction to this waste. Tools like no-code platforms and AI have made this "build fast" approach even more appealing. Why spend months validating when you can have a working prototype in weeks?
But here's where conventional wisdom falls short: it confuses "building something quickly" with "validating demand quickly." These are fundamentally different activities that require different approaches. The industry has optimized for speed of development when it should be optimizing for speed of learning.
When you can build anything in days or weeks, the constraint isn't technical capability anymore. The constraint is knowing what to build and for whom. Most founders skip right past this crucial step because building feels like progress, while validation feels like... talking.
Consider me as your business complice.
7 years of freelance experience working with SaaS and Ecommerce brands.
The client who approached me had everything that looks like startup success: a clear vision for a two-sided marketplace, enthusiasm for the latest tech stack, and a budget that would make most consultants say yes immediately. They'd done their homework on no-code tools and AI platforms, and they understood these could dramatically reduce development time and cost.
But as they walked me through their idea, one statement revealed the fundamental problem: "We want to see if our idea is worth pursuing."
They had no existing audience, no validated customer base, no proof of demand. Just an idea and the assumption that building would reveal whether people wanted it. This is what I call the "Field of Dreams" fallacy - "if you build it, they will come."
The conversation got interesting when I asked about their target market. They had identified two distinct user groups for their marketplace but hadn't talked to anyone from either group. They had assumptions about pain points but no conversations with people experiencing those pain points. They had a vision for how the platform would work but no evidence that anyone would actually use it.
This reminded me of a pattern I'd seen repeatedly in my client work. SaaS founders especially fall into this trap because technical execution feels more concrete than market validation. You can see code being written, features being built, designs taking shape. Validation feels mushy and uncertain by comparison.
What struck me wasn't their lack of business knowledge - they were smart people who understood their industry. The problem was they were optimizing for the wrong variable. They were optimizing for "how quickly can we build this" when they should have been optimizing for "how quickly can we prove people want this."
That's when I realized I had to have a difficult conversation about what an MVP actually should be.
Here's my playbook
What I ended up doing and the results.
Instead of accepting the project, I walked them through what I call the "Day-One Validation Framework." This isn't about being anti-technology or anti-building. It's about making sure that when you do build, you're building something people actually want.
Day 1: Create a Proof-of-Concept Page
Not a prototype, not a working platform - just a simple page explaining the value proposition. This could be a Notion doc, a basic landing page, or even a detailed slide deck. The goal isn't to impress anyone with technical sophistication. It's to articulate your hypothesis clearly enough that potential users can understand and respond to it.
Week 1: Manual Market Research
Start reaching out to potential users on both sides of your marketplace. This isn't survey research - it's conversation research. You're not asking "would you use this?" You're asking "how do you currently solve this problem?" and "what's frustrating about existing solutions?"
I recommend at least 10 conversations with each user type. If you can't find 10 people willing to spend 15 minutes talking about the problem you're solving, that's valuable data about demand.
Week 2-4: Manual Solution Testing
This is the part that separates real validation from founder theater. Instead of building automated matching or sophisticated algorithms, manually connect supply and demand via email, WhatsApp, or phone calls. Become the human version of your platform.
If you're building a marketplace for freelancers and clients, manually match freelancers with projects. If you're building a B2B platform, manually facilitate the connections you claim your platform will automate. This does two crucial things: it proves demand exists, and it teaches you what the automation actually needs to do.
Month 2: Systematic Process Documentation
Only after proving that manual processes work should you consider automation. By this point, you understand the real workflow, the actual pain points, and the genuine value exchange. You've proven that people will pay (or engage) when you solve this problem manually.
This approach flips the traditional MVP model. Your first MVP isn't your product - it's your marketing and sales process. Distribution and validation come before development, not after.
Manual First
Prove demand exists before building anything automated. Manual processes reveal real workflows and pain points.
Conversation Research
Talk to at least 10 potential users from each side. Focus on current solutions and frustrations, not hypothetical usage.
Process Documentation
Document everything you learn from manual operations. This becomes your actual product requirements.
Build-or-Buy Decision
Only automate after proving the manual process creates real value for real people.
The client took my advice, and the results were eye-opening. Within two weeks of manual market research, they discovered that one side of their intended marketplace had very different needs than they'd assumed. The pain point they thought was universal actually only affected a small subset of users.
More importantly, when they started manually facilitating connections, they learned that the real value wasn't in the matching algorithm they'd planned to build. It was in the vetting and quality control process that happened between matches. This insight would have taken months to discover through a built platform, but became obvious within weeks of manual operations.
By month two, they had a waiting list of paying customers and a clear understanding of what to build. More importantly, they knew their unit economics worked because they'd proven them manually. When they finally did build their platform (with a different consultant), they had paying customers from day one instead of hoping to find them.
This experience reinforced something I'd suspected from working with multiple startups: the constraint in 2025 isn't building capability, it's knowing what to build. AI and no-code tools have democratized development, but they haven't solved the fundamental challenge of product-market fit.
What I've learned and the mistakes I've made.
Sharing so you don't make them.
Manual processes reveal real workflows - You can't design good automation without understanding messy reality first
Conversations beat surveys every time - People will tell you things in conversation that they'll never write in a survey response
Early adopters are validation, not customers - Finding people willing to try your product is different from finding people willing to pay for it
Your assumptions are always wrong - Not completely wrong, but wrong enough that building on them first is expensive
Distribution is harder than building - In the age of no-code and AI, knowing how to reach customers matters more than knowing how to code
Unit economics must work manually first - If you can't make money when you do everything by hand, automation won't save you
Patience saves time - Two weeks of validation can save two months of building the wrong thing
The biggest lesson? In 2025, the most successful founders aren't the fastest builders - they're the fastest learners. Tools like AI automation and no-code platforms are incredible once you know what to build. But they can make expensive mistakes happen faster than ever if you start with the wrong assumptions.
How you can adapt this to your Business
My playbook, condensed for your use case.
For your SaaS / Startup
For SaaS startups:
Start with manual customer success before building automation
Test pricing through direct sales, not free trials
Validate technical feasibility through manual processes first
For your Ecommerce store
For E-commerce businesses:
Test product-market fit through pre-orders or waiting lists
Validate logistics manually before building automated fulfillment
Use manual customer service to understand automation requirements