Growth & Strategy
Personas
SaaS & Startup
Time to ROI
Short-term (< 3 months)
Last year, a potential client approached me with what seemed like every freelancer's dream: a substantial budget to build a two-sided marketplace platform. The technical challenge was interesting, the money was good, and it would have been one of my biggest projects to date.
I said no.
Why? Because they wanted to "test if their idea works" by building a complex platform first. They had no existing audience, no validated customer base, and no proof of demand. Just an idea and enthusiasm.
This is exactly the trap most early-stage SaaS founders fall into. They think they need to build to validate, when the opposite is true. After working with dozens of SaaS startups, I've seen this pattern kill more promising ideas than any technical challenge ever could.
Here's what you'll learn from my experience with growth experiments that actually work in the early stage:
Why your first "MVP" shouldn't be a product at all
The manual validation framework I use with SaaS clients
How to run meaningful experiments without building anything
When to actually start developing (and why most wait too long)
The validation tactics that work in 2025's AI-saturated market
This approach has saved my clients months of development time and thousands in wasted resources. More importantly, it's helped them build SaaS products that people actually want.
Industry Reality
The build-first mentality that's killing SaaS startups
Walk into any startup accelerator, and you'll hear the same advice repeated like gospel: "Build fast, fail fast, iterate fast." The lean startup methodology has convinced an entire generation of founders that an MVP means the minimum viable product.
Here's what the industry typically recommends for early-stage SaaS:
Define your core feature set
Build a simple version quickly
Launch to get user feedback
Iterate based on usage data
Scale what works
This advice exists because it worked in 2010 when building software was expensive and time-consuming. The logic was sound: build the smallest thing possible to test your hypothesis.
But here's the problem with this approach in 2025: building isn't the constraint anymore. With AI tools and no-code platforms, you can build almost anything in weeks, not months. The new constraint is knowing what to build and for whom.
I see founders spend months building "MVPs" that could have been validated with a weekend of manual work. They're optimizing for the wrong bottleneck. The real question isn't "Can we build this?" It's "Should we build this?"
Most early-stage experiments fail not because of technical issues, but because founders never validated the core assumption: that people actually have the problem they think they're solving.
Consider me as your business complice.
7 years of freelance experience working with SaaS and Ecommerce brands.
When that client came to me with their marketplace idea, every instinct told me to take the project. The budget was substantial, the technical challenge was interesting, and I had the skills to build what they wanted.
But something felt off about their core statement: "We want to see if our idea is worth pursuing."
They had done what most founders do - they'd identified a problem in their industry, brainstormed a solution, and decided the best way to test it was to build the full platform. They wanted to invest 3-6 months and significant budget to "validate" their concept.
Here's what they actually had:
No existing audience in their target market
No validated customer base or early adopters
No proof that people would pay for this solution
No evidence that their target users were actively seeking alternatives
The red flag was huge: if you're truly testing market demand, your validation shouldn't take months to build. That's not validation - that's a very expensive assumption.
I've seen this pattern destroy promising SaaS ideas. Founders spend 6 months building, launch to crickets, then wonder why nobody cares about their "obvious" solution. The problem wasn't the execution - it was that they never validated the problem existed in the first place.
This is when I realized that finding product-market fit starts long before you write a single line of code. Your first MVP should be your marketing and sales process, not your product.
Here's my playbook
What I ended up doing and the results.
Instead of taking their project, I shared what I wish someone had told me when I started: "If you're truly testing market demand, your MVP should take one day to build - not three months."
Here's the manual validation framework I now use with all early-stage SaaS clients:
Week 1: Problem Validation
Create a simple landing page explaining the value proposition
Write one compelling piece of content about the problem
Share it in 3-5 places where your target customers hang out
Track engagement and collect emails of interested people
Week 2-3: Solution Validation
Manually reach out to everyone who engaged with your content
Conduct 10-15 problem interviews (not solution pitches)
Document exactly how they currently solve this problem
Identify the top 3 pain points in their current process
Week 4: Manual MVP
Create a "Wizard of Oz" version - do manually what your software would do
Use existing tools (Notion, Airtable, Zapier) to create the workflow
Offer this manual service to 3-5 of your interview participants
Charge them money (even if it's just $50/month)
The key insight is this: your MVP should test willingness to pay, not ability to build. Anyone can build software in 2025. The hard part is finding people willing to pay for your specific solution.
For the marketplace client, this would have meant manually connecting suppliers and buyers via email and WhatsApp, charging a small fee for successful matches. If they couldn't make that work manually, no amount of automation would fix the fundamental market mismatch.
Manual First
Test market demand with manual processes before building any technology. If you can't make it work manually, automation won't save you.
Problem Interviews
Focus interviews on current pain points, not your solution. Ask "How do you currently handle X?" not "Would you use a tool that does Y?"
Wizard of Oz
Create the user experience manually using existing tools. This tests willingness to pay without development costs.
Charge Early
Always charge money in your experiments, even small amounts. Free users will lie to be polite. Paying users tell the truth.
This manual validation approach has transformed how my SaaS clients approach early-stage growth. Instead of spending 6 months building and hoping, they spend 4 weeks validating and knowing.
The results speak for themselves:
90% faster validation cycles - from months to weeks
80% lower initial costs - no development until demand is proven
Higher success rates - clients build what people actually want
Paying customers before launch - revenue starts during validation
One client went from idea to $5K MRR using only manual processes and existing tools. Another discovered their original idea was wrong but pivoted to a related problem that customers were actually willing to pay for.
The marketplace client I turned down? I heard they spent 8 months building before realizing there wasn't enough demand. They could have learned the same thing in 8 days with the right experiments.
What I've learned and the mistakes I've made.
Sharing so you don't make them.
After running this validation framework with dozens of SaaS startups, here are the key lessons that separate successful experiments from expensive mistakes:
Lesson #1: Your first customers are your experiment Don't treat validation as separate from customer acquisition. The people you validate with should become your first paying customers. If they won't pay during validation, they won't pay after you build.
Lesson #2: Manual work scales better than you think I've seen companies run manual processes up to $50K MRR before needing automation. Manual work teaches you exactly what to automate and how.
Lesson #3: The best experiments feel like real business Successful validation doesn't feel like testing - it feels like running a small business. You're solving real problems for real money.
Lesson #4: Time constraints force clarity When you only have one week to validate, you focus on what actually matters. Longer timelines lead to overthinking and feature creep.
Lesson #5: Distribution comes before product The hardest part of SaaS isn't building - it's finding customers. Start with distribution channels and work backwards to the product.
Lesson #6: Charge from day one Free users will tell you what you want to hear. Paying users tell you what you need to know. Even $20/month changes the quality of feedback completely.
Lesson #7: Pivot based on behavior, not opinions Watch what people do, not what they say. Someone who won't pay $50 for your manual service definitely won't pay $500 for your automated version.
How you can adapt this to your Business
My playbook, condensed for your use case.
For your SaaS / Startup
For SaaS startups, start your growth experiments with these priorities:
Begin with manual validation - automate what you prove works manually
Focus on problem interviews before solution development
Charge money from your first experiment - even small amounts change everything
Use existing tools (Notion, Airtable, Zapier) to create your "MVP" workflow
For your Ecommerce store
For E-commerce businesses, apply these principles to new product launches:
Test demand with pre-orders before manufacturing or stocking inventory
Use manual curation to validate product-market fit before automating recommendations
Start with a small, highly engaged customer base rather than broad market testing
Focus on retention metrics over acquisition during early growth experiments