#72: Move Fast, Break Trust & Open-Source Monetization
March 9, 2025 – DevTools Brew #72
Welcome to DevTools Brew! 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:
Move Fast and Break Trust
→ The painful reality of prioritizing speed over reliability—and how it cost us a our biggest early deal.The Open-Source Monetization
→ The CEO of Gatling breaks down four failed attempts before finding a sustainable business model.
Two moments where conventional startup wisdom didn’t match reality, and what actually worked instead.
Let's dive in.
Move Fast and Break Trust
"The velocity that got you here might be the fragility that destroys you."
At the beginning of Qovery, we did what every early-stage founder does: we built fast. MVP, rapid iterations, new features constantly shipping. The classic "move fast and break things" mantra. And it worked... until it didn't.
I still remember the exact moment we lost our first major enterprise deal - a recognizable and shiny logo that would have instantly legitimized us in the market. The problem wasn't our vision, value proposition, or pricing. It was our reliability. Our product didn't just underperform - it actually broke their production environment. Let that sink in: we damaged the very thing we were supposed to help them manage.
That’s when I realized something counter-intuitive: for products where customer operations depend on your reliability, “move fast and break things” can be a death sentence.
Speed is a competitive advantage - until it isn’t
I thought we were being smart by prioritizing new features over stability. “We can fix that later,” became our unofficial motto. What we didn’t understand was that later would come sooner than we thought.
When you’re building a software, there’s a moment where speed shifts from an asset to a liability. You’re no longer experimenting in a sandbox—you’re becoming part of someone’s infrastructure. And when that happens, every shortcut, every piece of rushed code, every “we’ll fix it later” becomes a ticking time bomb.
For instance, at Qovery, we hit that breaking point when that shiny logo customer tried to deploy a production workload, and our system not only failed—it took down parts of their environment with it. We scrambled, worked nights, but the damage was done. That single incident didn’t just cost us a deal—it permanently damaged our reputation with them.
The inflection point: when speed stops being your friend
There’s a critical moment in every startup where you go from “fast and scrappy” to “trusted and reliable.” The real challenge? Knowing when that moment arrives. And having the courage to slow down so you can accelerate later.
I realized this the hard way. After losing that fintech deal, we made a painful but necessary decision: we froze platform access for new users. For six months, we worked tirelessly on performance, stability, and reliability. No new features. No growth hacks. Just fixing what was broken.
It was brutal. But looking back, it was one of the best decisions we ever made.
Because here’s the hard truth: Building a (great) software takes years.
It’s easy to build an MVP. At Qovery, we shipped our V1 in under six months. But building something people can trust? That takes years.
This is something that’s easy to forget when you’re in the trenches. The pressure to grow fast is real. But if your foundation is shaky, that speed will eventually collapse on itself.
What I’d do differently
→ Before product-market fit: Accept technical debt, but be strategic. Some components (especially those touching user data or reliability) need quality from day one.
→ At the first signs of traction: Identify your robustness breaking points - the areas where failure will cost you credibility with serious customers.
→ When approaching larger deals: Allocate at least 30% of engineering time to robustness and scalability, even if it means shipping fewer features.
The uncomfortable reality is that trust is fragile. When you’re building tools businesses rely on, you can’t fix trust problems once they’re exposed. The damage is already done.
I might be wrong about many things, but I’m confident about this: The velocity that helps you find your market will eventually become the fragility that destroys your vision - unless you recognize the breaking point and act before it’s too late.
Open-Source Monetization
Gatling's CEO Hard-Earned Lessons
When Paul-Henri Pillet joined Gatling as CEO (a popular open-source load testing tool), he had a seemingly simple task: find a business model for an open-source project. What followed was a four-year journey of trial and error that offers valuable lessons for any founder considering open-source.
Here's what they tried, what failed, and what finally worked:
1. Consulting
The false first step
Like many open-source startups, Gatling began with consulting:
- Selling days and hours of expertise
- Creating starter packs for load testing
- Leveraging founder Stephane's technical knowledge
The results? Revenue came in, but:
- "Not scalable"
- "Pulled us away from our goal of developing Gatling"
- "Stéphane started to get really annoyed"
→ Lesson: Consulting pays bills but distracts from product building - a classic trap many technical founders fall into.
2. Paid Support
A model nobody wanted
Seeing community questions flood in, they built tiered support plans with:
- Response time SLAs
- Bundled consulting hours
- Early access to preview versions
Reality check: "No one bought." Why? "Gatling isn't a production-critical tool. Support was a 'nice-to-have,' not a 'must-have.'"
→ Lesson: Just because your community asks questions doesn't mean they'll pay for answers.
3. Custom Development
The transition phase
They pivoted to selling custom add-ons for specific customer needs. This worked better than consulting but still suffered from:
- Still not focused on core product development
- "Customers became less eager to pay for every new feature"
The breakthrough insight came from a customer: "Why don't you sell what you built for us to other customers?"
They noticed every customer wanted the same things:
- An orchestrator for Gatling
- A nice dashboard
→ Lesson: When multiple customers request the same customizations, you’ve identifyed your product gaps - and then you've found your product opportunity. .
4. Open-Core
Right Model, Wrong Execution
After a year of development, they launched Gatling Enterprise with initial excitement. They spent a year building Gatling Enterprise. The beta launch brought excitement:
- Major US companies signed up
- Feedback poured in
- It felt like product-market fit
But deals weren't closing. The problem? Not the product, but the buying experience.
The winning formula came when they refined the sales process:
- Clear evaluation milestones
- Technical team involvement in trials
- Transparent pricing upfront
- Complete legal documentation ready
- Strategic vision presentations
The result? "The first prospects with this experience converted immediately. Their subscriptions fully funded our first years."
→ Lesson: For open-source tools, the buying experience is as critical as the product itself.
Paul-Henri's most profound insight from this journey gets to the heart of open-source monetization: "Customers don't just buy a product—they buy a partnership. Tech is only part of the decision. Reactive support, trust, and company vision matter just as much."
This rings especially true for open-source tools where users have already experienced your technology before becoming customers. The product gets them interested, but the partnership gets them to pay.
Final thoughts
I do think startup success it’s all about recognizing the pivotal moments that demand counterintuitive choices.
Whether it’s slowing down when everyone says “move fast” or rejecting obvious revenue paths to find a sustainable model, the key is seeing your specific reality with clarity.
The founders who win aren’t the ones with the perfect playbook—they’re the ones who know when to break it.
That’s it for me today! :)
Thanks for reading and Happy Sunday!
— Morgan
Do you want more deep dives like this? More personal lessons? More insights from other devtool founders? Let me know, I’m always open to feedback.
You can reach out to me on LinkedIn.