When building a SaaS, you can either start coding immediately and hope it’s right, or spend three weeks in a product discovery phase figuring out what is right.
Most teams choose door number one. They start Sprint 1 with enthusiasm and a backlog full of features. Six months later, they’re pivoting core functionality, rebuilding their data model, or staring at stagnant usage graphs.
We learned this lesson through experience. After years of watching smart teams build the wrong products, we changed our approach. Now we start every project with discovery-a focused phase that turns guesswork into clarity before coding.
Here’s what that shift taught us, and why one failure changed how we work.
The costly lesson
We watched a well-funded startup burn through its seed round building features. They started coding on day one. By the time they ran out of money, they had beautiful code, empty dashboards, and no users.
The exact words of the founder are: “We built everything except the thing that was important.”
What made this failure special was that they did everything “right.” They held daily standups, two-week sprints, code reviews, and automated testing. They followed every agile best practice except one-validating what to build before building it.
Their feature list came from competitor analysis and investor feedback. Their user personas were fictional. Their pricing model was a guess. Every two weeks, they shipped another piece of an elaborate product that solved problems for non-existent users.
They kept adding features to fix their activation problem: better onboarding, more integrations, and a slicker UI. But you can’t iterate your way to product-market fit when you’re solving the wrong problem.
By the time they realized they needed to talk to actual users, they had a codebase too complex to pivot and a runway too short to recover.
The worst part? We saw the warning signs early. The skipped user interviews. The untested prototype. The unanswered questions because they were too busy answering them with code.
Since then, we’ve made the product discovery phase non-negotiable. We don’t do this because we’re process zealots, but because we’ve seen too many talented teams code themselves into corners. The most cost-effective time to change direction isn’t after your first sprint or failed launch-it’s before you write the first line of code.
The 3 discovery questions
We’ve distilled years of MVP validation framework pattern-matching into three questions. Successful SaaS products could answer them before coding. Failures couldn’t-or provided an incorrect answer.
1. “What’s the first thing a user must do to gain value?”
Ask a CRM founder this question. If they list ten features, they’re in trouble. If they say “get their contacts in and send the first outreach,” they might do well.
The difference isn’t simplicity-it’s clarity. We worked with an HR tech startup that initially described their value as “comprehensive workforce management.” Six months and zero traction later, they figured out users just wanted to track who was working from where. The entire product collapsed into a single, valuable action: check in your location.
2. “How will you know it’s working before you have users?”
This stumps founders because they think they need scale to validate MVP metrics. Wrong. You need to know if users can complete the core action that delivers value-and you can measure that with your first ten testers.
We built a project management tool that thought their onboarding was “dead simple.” When we measured it, only three out of ten test users created their first project. Why? The template selection screen overwhelmed them. We cut it to three templates. Completion jumped to nine out of ten.
3. “What will motivate someone to pay on day 31?”
Free trials end, and credit cards get charged. What happens in between determines if you have a business or an expensive hobby.
Most founders guess, “They’ll pay when they see the value.” But value is vague. Payment triggers are specific. A document automation startup found users converted after processing their tenth document, not their first or hundredth. That insightshaped everything: MVP metrics like trial length, onboarding goals, upgrade prompts.
These questions work because they force specificity where founders want to stay abstract. You can’t build “powerful analytics,” but you can build “see which content drives sales.” You can’t price “value,” but you can price “I’ve saved 10 hours this month.”
The VeryCreatives discovery method
After years of refinement, our strategy sprint–driven discovery process follows a deliberate arc. It goes from understanding the core problem to validating the solution to ensuring someone will pay for it.
Find the one thing that matters
Every SaaS has a center of gravity-the one action that delivers the core value. Most founders can’t see it because they’re too close.
A logistics startup approached us for route optimization, driver tracking, delivery confirmations, and customer notifications. We kept asking: “If the product could only do one thing, what would it be?” After three days of pushing back on feature lists, we landed on: “Show me where my delivery is right now.”
Everything else-the optimization algorithms, the driver app, and the notifications-became implementation details serving that single need. The founders initially resisted this focus. “Our competitors have twenty features,” they said. But they also had thousand-page manuals and six-month implementation cycles.
Prototype the reality check
This is where SaaS MVP development meets user behavior, and user behavior prevails
We don’t prototype everything-just the moments where assumptions are most expensive. For a procurement platform, that meant the approval workflow. The founder envisioned a sophisticated multi-level approval chain. The prototype revealed that users wanted their boss to get a text message.
Another client insisted their “simple” data import would be straightforward. The prototype exposed edge cases that would take months to handle: duplicate detection, field mapping, and error handling. So, we built a manual upload process instead. Yes, it was less sophisticated. But it was shippable in two weeks instead of twelve.
Price the moment, not the product
Pricing isn’t about features or competitors. It’s about when free becomes paid.
A founder of a content planning tool wanted to charge for “advanced analytics.” Watching users revealed they’d pay when needing to collaborate. Solo users were happy with free forever. When they added one teammate, they needed permissions, shared calendars, and approval workflows. That’s a payment incentive.
We test pricing through behavior, not surveys. The second question, “Your trial ends tomorrow. Enter a card to keep your workspace,” reveals the reality. “Would you pay $50/month?” gets different answers than the second question.
The discovery moment
In every discovery, there’s a moment of silence. The founder sees their idea clearly for the first time-not the ideal version, but what it needs to succeed.
The founder’s face changes. You see them doing math-calculating how much time and money they’ll save by not building the wrong thing.
This moment always follows the same pattern: a user says something obvious that makes the complex solution look ridiculous. “Why would I need real-time updates? I check this once a week.” Suddenly, the WebSocket architecture becomes a daily email.
We’ve seen this happen dozens of times. A founder planning six months of development realizes they need six weeks. The $500K seed round that seemed tight becomes more than enough. The technical co-founder they were recruiting becomes unnecessary.
But here’s what most founders miss: this isn’t a downgrade. It’s an upgrade to reality. The simple version ships faster, costs less to maintain, and is easier for users to understand. We tracked outcomes across our projects: the “embarrassingly simple” versions had 3x better activation rates than the original complex ideas.
Why? Because complexity kills good products. Every added feature means another decision for users, another potential issue, and more support tickets. Founders who insist on building their original vision usually end up with powerful but unusable software.
The hard part isn’t technical. It’s emotional. You have to let go of the story you’ve been telling yourself. The TechCrunch headline you’d written. The disruption narrative. The complexity that made you feel like a visionary.
Some founders can’t do it. They’ll acknowledge the simple version would work, but insist on building “a few more features” to differentiate. Those projects typically fail. Not because the features are bad, but because they’re solving for founder ego instead of user needs.
What’s left is simple. A spreadsheet with better sharing. A form that sends emails. A dashboard that shows three numbers. The kind of thing you could build in a weekend, but you convinced yourself needed six months.
Founders who resist this moment spend months building features that should be buttons. Those who embrace it ship in weeks and iterate on something tangible.
Ironically, the simple version often grows into something complex and powerful, but with actual users guiding that complexity instead of founder assumptions. Stripe started as seven lines of code. Zoom was just working on video chat. Sophistication came later, built on proven value.
Discovery delivers the profitable truth instead of the costly fantasy.
What discovery truly costs
Let’s discuss what founders want to know: discovery costs and why they are worthwhile.
MVP cost for discovery runs a fraction of your build budget but determines whether it gets wasted. Teams skip discovery to save money and spend months rebuilding core features. Others invest in discovery and ship exactly what users need on the first try.
The pattern is consistent: teams that skip discovery to save time take longer. They build, test with users, realize they’re wrong, and rebuild. Each cycle burns runway and morale. Teams that invest three weeks upfront achieve better results faster.
What matters is that discovery saves development and opportunity costs. Every month spent building the wrong thing is a month your competitor captures your market. A procurement platform we worked with spent eight months perfecting unnecessary features. During that time, a simpler competitor launched and captured their market.
The real ROI isn’t in MVP cost dollars saved. Instead, it’s in shipping something people will pay for instead of something they’ll overlook.
Three real stories
JamDoughnut: when activation rate beats features
JamDoughnut wanted to build a comprehensive cashback app. The app would have twenty retail categories, price comparison, savings goals, and shopping lists. It was feature overload from a founder who’d studied every competitor.
Discovery revealed the critical insight: we needed to prioritize instant first value over breadth. The focus became clear-get users their first cashback immediately.
We refocused the roadmap on the fastest path to first cashback. That meant backend-driven UI to update content and sections without app releases. Deep linking took users straight back to the relevant action or offer. We integrated referrals as a growth lever into the core experience.
By focusing on activation over features, JamDoughnut now markets itself as the UK’s #1 instant cashback platform. The other features? They added them later-after gaining users.
Reachbird: building for both sides from day one
Most marketplace founders first build for one side, then scramble to attract the other. Reachbird wanted to connect brands with influencers, but couldn’t decide who to serve first.
Discovery solved it: both sides simultaneously, but distinct problems.
Brands didn’t care about discovery features. They wanted to know if influencers would post. Influencers didn’t care about analytics. They wanted to know if they’d get paid.
This insight shaped everything. Instead of elaborate search and filtering, we focused the MVP on both sides’ core needs: trust and delivery confidence. The essential components that make marketplaces work.
The technical choices followed the discovery insights. Elixir for real-time messaging because quick responses built trust. PostgreSQL with specific indexing for the key search: “Show me influencers who’ve completed campaigns like mine.” React and AWS rounded out the stack, chosen for their ability to support rapid marketplace iteration.
Reachbird continues to operate on this stack. Later, competitors’ features-AI-powered matching, sentiment analysis, audience overlap detection-came, built on a functional marketplace.
PinqDR: speed as the entire product
Virtual dispute resolution platforms compete on features such as video quality, document management, and scheduling systems. The founder of PinqDR had the complete list ready.
Commercial and international arbitration typically take 12-20+ months to resolve. Discovery revealed that time-not features-was the critical pain point in the market.
The discovery pivot was radical: PinqDR wouldn’t be a better platform, but a faster one. Verdicts in 6-8 weeks instead of the industry standard of over a year. This wasn’t a feature-it was the entire product.
Everything else bent to serve speed. We simplified the entire process to reduce time at every step. Case submission, arbitrator selection, and scheduling were all streamlined to eliminate delays.
The legal industry pushed back. “You need more features to be taken seriously.” But when PinqDR delivered on their promise of 6-8 week resolutions-compared to the typical 12-20+ months, feature conversations stopped. They were shortlisted at the 14th GAR Awards (2024) not for their platform capabilities, but for transforming how quickly justice could be delivered.
Ready to break the pattern?
After years of watching smart founders build the wrong things beautifully, we can identify the patterns in the first conversation.
If you’re explaining your product as a combination of other successful products (“It’s like Uber meets LinkedIn for…”), you’re probably solving the wrong problem. If you’re listing features instead of outcomes, you’re building too much. If you can’t explain what makes day 31 different from day 30 for a user, you don’t have a business model yet.
Book a Discovery Scoping Call. We’ll ask three questions. Most founders can’t answer them clearly-that’s normal and fixable. The ones who think they can, but give feature lists instead of user outcomes, are the ones to watch out for.
The call is 30 minutes. You’ll either leave confident in your direction or clear on why you need a product discovery phase first. Both outcomes are valuable. Building without clarity is costly.
