Why We Still Care About Quality
Quality is slow, hard, and totally worth it
I recently read Linear’s excellent blog post on why quality is so rare, and it resonated deeply with me. Craft, quality, care — these aren’t buzzwords. They’re a way of working, a way of thinking, and frankly, the only way I’ve ever known how to build things.
For me, it started with open source. When you put your code out in the open, you naturally want to make it good. Maybe even beautiful. I started more than 20 years ago, polishing my Debian packages, making sure they were clean, understandable, and useful. Later I poured that same mindset into building awesomewm, striving to write the best C code I could — because that code was me, visible to anyone curious enough to look.
Open source taught me that quality is not an accident. It’s a habit. And a commitment.
Even though Mergify is no longer open source, the ethos never left. We still build like our code is going to be read by thousands, because, well, it is at least read by our folks. Our team ships work we’re proud of. Whether we win a deal or not, it’s common to hear people tell us:
The quality of Mergify stands out.
That never gets old.
I know I’m not alone in this. Mehdi, my cofounder, and I have been building together for over 15 years. It’s in our DNA: we hate mediocrity. We won’t ship something that we wouldn’t use ourselves — joyfully.
That said, I’ve also seen the flip side. Back when I worked on OpenStack, a massive open-source project, there was a lot of code… and not always a lot of care. Many contributors came from companies that didn’t value quality — and it showed. Open source can be beautiful, but when it’s driven by quantity instead of pride, it becomes exhausting. I hated that part.
Quality isn’t just aesthetic. It’s a business strategy. Linear nailed that in their post. When you build something that feels right — fast, polished, thoughtful — users notice. They stay. They tell others. We’ve seen this at Mergify: our growth has been fueled not just by features but by how those features feel to use.
But quality is more than just a great UI or bug-free code.
It’s also:
A fast, reliable, intuitive product.
Clean code that enables long-term agility.
Thoughtful defaults and edge-case handling.
Being able to say “no” when something adds complexity without enough payoff.
Getting there isn’t easy. You need judgment — to know what’s worth doing and what can wait. That comes with experience and the humility to know you’ll never get everything right. We aim for 80/20, not 100/0. Sometimes that means leaving the last 20% for another day — or maybe never. Not because we don’t care, but because we care about the whole system staying healthy and fast.
Quality isn’t free. But it pays back. In speed, trust, and joy.
So yes, it’s a choice. One you make every day.
You can take the shortcut, or you can make something that lasts.
We still choose the latter.