#75: Pricing Power & Scaling Lessons
March 30, 2025 – DevTools Brew #75
I’m Morgan Perry, co-founder of Qovery. Every week, I’m sharing lessons and truths behind building and scaling devtool startups—from 0 to 1 and beyond.
In today's edition:
Pricing Power
→ How focusing on the wrong metrics held back our revenue—and the approach that helped us 3x it.Scaling Lessons from startup to IPO
→ Lessons from HashiCorp’s CEO from startup to IPO, and why frameworks, not features, are what truly scale.
Both stories share a common theme: The most powerful levers for growth aren’t about building more - they’re about aligning what you build with what truly drives value.
Let's dive in.
Pricing Power
How we 3X'd revenue without changing our product
“The biggest lever isn’t building the right features—it’s charging for the right value.”
Early on at Qovery, we did what everyone else was doing: textbook SaaS pricing.
Per-user pricing, tiered plans, usage caps. The classic “One-size-fits-all” model.
But here’s the problem: charging for the wrong metrics.
In our case, we priced by seats and deployment counts - metrics that were easy to measure but had nothing to do with the actual value we were delivering.
Worse, we were penalizing the exact behavior we wanted to encourage.
Customers were actively limiting their usage just to stay within certain tiers.
And when customers are holding back to avoid paying you more, something’s broken.
The issue wasn’t acquisition. It was revenue.
The wrong pricing model was leaving so much value on the table it was almost embarrassing.
It clicked during customer conversations. We started seeing our product through a different lens. The real value wasn’t in the features themselves—it was in what our product replaced and rationalized.
It was about the resources customers no longer needed to allocate:
→ Headcount (DevOps engineers) they didn’t need to hire or dedicate to infrastructure work.
→ Consultants they no longer had to pay for integration, maintenance, or optimization.
→ Time and complexity saved by eliminating the need to build and maintain custom infrastructure solutions.
But there was also another critical piece we missed: Tool overlap.
Our product wasn’t just replacing tasks and expertise. It was also consolidating other paid tools - tools our customers were paying for separately.
→ For example, our native CI capabilities were bundled into our platform from day one. But customers were still using external CI tools because we never emphasized that ours could fully replace them.
→ We were giving away significant value without even realizing it.
Once we saw this pattern, we made two strategic changes:
1. We shifted to a usage-based model:
→ Lowered entry prices to reduce friction and get more people started.
→ Charged premium rates for capabilities replacing headcount, paid tools, or dedicated expertise.
→ Scaled revenue naturally with value delivered, not arbitrary metrics.
2. We started emphasizing consolidation:
→ Clearly communicated how our platform replaced existing tools.
→ Positioned our product as an efficiency play—not just a better product, but a simpler, more cost-effective stack.
The results?
→ Average revenue per customer tripled - without significant pushback.
→ Our entry point became more accessible, and customers expanded usage organically.
→ We aligned what we were charging with what customers were saving, both in costs and complexity.
But here’s the real learning:
The mistake wasn’t that we were charging too little. It was that we were charging for the wrong things.
The value wasn’t in the features themselves—it was in the costs, complexity, time, headcount, and tools our product replaced.
Now, we evaluate every new feature by asking:
→ What expertise or time does this replace?
→ What paid tools does this make redundant - from overlapping to rationalizing ?
→ What complexity or specialized knowledge does this remove?
The lesson is brutal BUT simple: You can build all the right features, but if you charge for the wrong things, you’re leaving money on the table.
Pricing is your most powerful growth lever. And most founders—myself included—don’t realize it until it’s almost too late.
Scaling Lessons from HashiCorp’s CEO
Dave McJannet’s journey scaling HashiCorp from startup to IPO is packed with lessons that go beyond the usual clichés. His approach is refreshingly systematic - breaking down growth into patterns and frameworks that can be applied to any devtool company.
Here’s what stood out:
1. Pick the Market First
A mistake many founders make: starting with the product instead of the market. The most technically impressive product is irrelevant if it’s not solving a critical problem for the right audience.
Dave’s point: Market fit matters more than product elegance. The best products aren’t always the ones that win - it’s the products that resonate with a real, urgent market need.
2. Find the Right People
Scaling isn’t just about hiring talent - it’s about hiring the right talent for the right stage.
Builders, sellers, operators. The right mix shifts depending on the phase you’re in. Dave’s approach is ruthless about fit. The people who thrive at $0-10M may not be the same ones who excel at $100M+.
3. Build Systems, Not Dependencies
One of the hardest lessons: Individual brilliance doesn’t scale. Systems do.
Creating frameworks that work independently of any one person is the only way to build resilience at scale.
Dave’s insight: Build execution systems that can be replicated and adapted by anyone, not just your best people.
The 6 Growth Phases
What impressed me most was how clearly Dave broke down growth into distinct phases.
Instead of treating scaling as one continuous motion, he divides it into six revenue milestones - each requiring a different playbook:
→ $0-10M: Pattern Matching - Experiment, gather insights, iterate fast.
→ $10-30M: Product-Market Fit - Validate early signals with real data.
→ $30-100M: Repeatability - Create systems that drive consistent results.
→ $100-250M: Early Scale - Expand successful systems and frameworks.
→ $250-500M: Mid-Scale - Refine processes and scale operations.
→ $500M+: Scale and Diversify - Prepare for long-term growth and market leadership.
Strategies that work at one revenue level often break down at the next. The systems need to evolve as you grow.
The 4 Core Plans Every Company Needs
Dave simplifies complexity by distilling it into four interlocking plans:
Financial Plan: Cash flow, burn rate, and the pace of spending.
People Plan: Hiring strategy and organizational design.
Product Plan: What to build, when, and why.
Go-to-Market Plan: How to acquire and expand customers.
Misalignment between any of these plans will derail growth. They need to be developed in concert, not in isolation.
The Time Horizon Principle
A counterintuitive but powerful insight:
→ CEO: 36-month horizon
→ Leadership Team: 18-month horizon
→ Managers: 12-month horizon
→ Individual Contributors: 6-month horizon
Different roles should operate on different timelines. When everyone runs on the same horizon, long-term growth is sacrificed for short-term wins.
Final thoughts
Both stories are about building for what’s real - not just what’s visible.
Whether it’s revenue or scale, the mistake is often the same: mistaking noise for signal, activity for progress.
The hardest part of building anything meaningful is stripping away the distractions and narrowing your focus on what truly matters.
It’s all about doing what moves the needle.
Because in the end, real growth is rarely loud. It’s systematic, intentional, and built on decisions that often feel counterintuitive.
That’s it for me today! :)
Thanks for reading and Happy Sunday!
— Morgan
Do you like personal lessons like this? More insights/stories from other devtool founders? Let me know, I’m always open to feedback.
You can reach out to me on LinkedIn.