startup — jd:/dev/blog

The SaaSpocalypse Won't Kill SaaS

Tue, 31 Mar 2026 00:00:00 GMT

A reader emailed me last week. He'd listened to a podcast I did on saas.group about selling developer tools, and he had a question I've been hearing a lot: how do you pitch SaaS when the cost of building software is collapsing?

Source: TechCrunch

Fair question. In January 2026, Anthropic launched Claude Cowork, and Wall Street panicked. Roughly $300 billion in SaaS market cap disappeared in a single trading session. Wall Street analysts coined a term for it: the SaaSpocalypse. Per-seat pricing? Dead on arrival, apparently.

The "I can build that" crowd finally has data on their side. They're right about one thing, and wrong about everything else.

"I Can Build That"

I've been hearing this for seven years. From the very first Mergify demo, developers would look at our merge queue and think: "This is just an automatic rebase, right?" Twenty minutes later, after walking them through race conditions, speculative merging, priority queues, and a dozen edge cases they hadn't considered, the reaction would shift: "Oh. That sounds quite hard to do." (I wrote about this back in 2024, and every word still applies.)

AI has made the objection louder. A developer with Claude or Cursor can now scaffold a basic merge queue in a weekend. I know this because I've done it myself: I shipped a production feature at Mergify using AI, coding less than an hour a day. But I could do that because I had seven years of context telling me what to build and how to evaluate the output. The AI wrote the code. The judgment about what code to write came from running the product.

A competitor starting from scratch with the same AI? They'd build the wrong thing. And that's the part nobody talks about at the end of the vibe-coding weekend: you're not done. You're at the starting line. You've compressed the first sprint, not the product. It's not done until you have real users running real workloads. Until you have a team that can maintain what you built. Until you can evolve it for years. The weekend prototype doesn't know that GitHub's API is asynchronous in ways they don't document, that it breaks under load in ways you only discover at scale, or that the enterprise customer needs SAML before they'll even look at your product.

Building Is the Easy Part

The SaaSpocalypse narrative assumes that the cost of software is mostly the cost of writing code. It's not. Writing code was always the cheapest part.

Source: Retool

Retool's 2026 Build vs. Buy report says 35% of enterprises have already replaced at least one SaaS tool with a custom build. That's a real number. But the report also shows where the replacements are concentrated: workflow automations, internal admin tools, basic dashboards. The easy stuff. The tools that were always one ambitious intern away from being replaced. I don't see enterprises vibe-coding their own Salesforce or Datadog.

The costs that AI didn't make cheaper:

Users. Finding them, understanding what they actually need (not what they say they need), and iterating based on real usage patterns. We built speculative merging at Mergify because a customer running 100+ PRs a day showed us that sequential merging broke down at scale. That insight came from watching real teams hit real walls, not from a prompt. No model can replicate that feedback loop yet, because it requires deployed software, real usage data, and the kind of trust that makes customers tell you what's actually broken.

Maintenance. Your weekend project works today. Will it still work when GitHub ships a breaking API change? When your company scales from 50 to 500 engineers? When the on-call engineer at 2am needs to debug a failure path you never tested? AI makes writing code faster, but it hasn't made maintaining it any easier.

Trust. Enterprise buyers don't want a git repo. They want SOC 2, uptime SLAs, a support contract, and someone to call when things break. Trust is earned across hundreds of deployments, not generated in a prompt.

The Real Moat Is Not Code

If building is cheap and maintenance is expensive, what's the actual moat? Domain expertise. The thing that takes the longest to build up and is the hardest to transfer.

Product discovery is the boring work that separates a tool from a product. The thousands of conversations with users. The wrong turns that taught you what not to build. The instinct for when a feature request is actually a symptom of a different problem. Seven years of running Mergify gave us knowledge that doesn't fit in a markdown file (or a Claude skill, at least not yet).

Reliability, trust, and ease have no price. They're earned over years, not generated over a weekend.

AI agents are getting better at learning domains. METR benchmarks show that the scope of what AI can handle autonomously is doubling roughly every seven months. I'm not dismissing that. But domain expertise isn't just knowledge you can look up. It's judgment shaped by consequences. AI can read your docs. It can't feel the pain of shipping a bad feature to 2,000 teams and spending the next month cleaning up the fallout. That scar tissue is what makes you build differently the next time. Maybe AI will get there. But right now, there's no shortcut to the operational context you accumulate by running a product for years.

Natural Selection

None of this means every SaaS company is safe. Thin wrappers, glorified CRUD apps, tools that existed only because building was expensive: they should be worried. This is natural selection, and it won't be fair. Some decent products with real value will die too, because their surface area is small enough for AI to replicate. A standalone CSV-to-dashboard tool? That's a Claude prompt now, not a business.

Source: TechCrunch

Benioff says "this isn't our first SaaSpocalypse." He's right that SaaS survives, but he's wrong to be dismissive about how many won't.

The SaaSpocalypse narrative confuses the death of lazy SaaS with the death of SaaS. The model isn't dying. The bar is rising. The products that survive will be the ones where the code was never the point. The point was always the knowledge embedded in it.

The Pitch Hasn't Changed

Back to my reader's question: how do you update the sales pitch?

You don't. The pitch was never "we wrote the code so you don't have to." It was always "we know things you don't, and we turned that into a product you can trust." The framing shifted. Instead of "look at all the edge cases you'd have to handle," it's now "look at all the edge cases AI doesn't know exist."

The moat was never the code. It was always the knowledge.

Tech Is the Easy Part

Tue, 13 Jan 2026 00:00:00 GMT

Last week, a founder reached out for advice. Two co-founders — one technical, one not — a couple years of R&D, patents pending. They’d built something they described as a breakthrough: AI-powered app generation, any app, a few hours. They were ready to raise several million euros. Think Lovable, but better.

I asked the usual questions. What’s the product? Who’s the customer? How do you distribute it? What’s your unfair advantage?

The answers were thin. No clear vertical. No distribution plan. No product, really, just capability.

I pushed on all of this for an hour. And then the non-technical co-founder said the thing that made me sit back in my chair:

“Well, we did the hard part. We solved the tech.”

Here’s what’s actually happening.

If you’re an engineer — or if you’ve built a company around one — tech feels hard because it is hard. It’s complex, demanding, and requires real skill. But it’s also legible. You write code, you get feedback. You solve a problem, you know it’s solved. Effort correlates with output. The system makes sense.

The rest of the business doesn’t work like that.

Distribution is not legible. You can do everything right and still fail. Positioning is not legible: you’re trying to exist in someone else’s mind, and you can’t compile that. Saying no to opportunities, picking a vertical, pricing, hiring, firing; none of it gives you the clean dopamine hit of a passing test suite.

So technical teams do what’s rational: they retreat to where effort is rewarded. They keep building. They add features. They refactor. They convince themselves that if the tech is good enough, the rest will follow. (I wrote about this exact pattern in The Engineer’s Dilemma.)

It won’t.

Ben Horowitz called his book The Hard Thing About Hard Things because the hard things aren’t the technical problems. They’re the ambiguous, human, no-right-answer problems. The ones where you have incomplete information and the consequences are irreversible.

For a technical founder, the hard thing is almost never the tech. The hard thing is:

Picking one customer, one use case, one vertical, and ignoring everything else
Building distribution before you feel ready
Charging money before the product is “done”
Talking to the market more than you talk to your codebase

The tech is the part you already know you can solve. That’s exactly why it’s the wrong place to start.

If you’re a technical founder and you’ve spent two years on R&D with no product, no customers, and no distribution, you haven’t done the hard part.

You’ve been avoiding it.

The Day I Got Custom Table Legs

Tue, 22 Jul 2025 00:00:00 GMT

Last week, I was with my team at our Mergify on-site — what we call our MAHOS (Mergify All-Hands On-Site). Yes, we’re a fully remote team, so your regular off-site are called on-site for us. 😉

We talked about the usual: roadmap, strategy, alignment. But then I brought up something a little different. I wanted to explain how we think about customer support at Mergify—not as a checkbox, not as a cost center, but as a way to deliver what I call the wow effect.

To make my point, I told them a story. A true one — about a table.

Two years ago, I had just moved into a new house. My first real garden. I was excited to enjoy it, so I decided to buy a garden table and chairs. After browsing around, I picked Lafuma — a French brand I’ve liked since I was a kid.

Fun fact: my very first school backpack in first grade was a Lafuma. Yes, I still remember it.

Anyway, the table and chairs arrived. Great delivery. Good packaging. Quality seemed top-notch.

But something felt… off.

I sat down, and it wasn’t right. The proportions felt weird. The table was just a little too high, or the chairs too low. So I did what every curious engineer does: I grabbed a tape measure. Compared it to my indoor table. And there it was — the Lafuma table was exactly 2cm too tall. Just enough to make every meal feel slightly awkward.

So I wrote them a message. Not angry, not demanding. Just a note saying:

“Love the brand, love the product, but this feels like a design oversight.”

I didn’t expect a reply.

One week later, I got a call. It was someone from Lafuma’s support team — a QA engineer.

He said:

“I read your message. I’d like to understand exactly what’s wrong.”

I explained. He listened. Then, without hesitation, he said:

“Okay. I’ll send you custom table legs, 2cm shorter. You’ll have them next week.”

I was stunned.

“Wait, really? You can do that?”

“Of course,” he replied. “We have spare legs in the workshop. We’ll just trim and ship them to your size.”

And that’s exactly what happened. A week later, I swapped out the legs. Perfect fit. Perfect height. Perfect support.

They didn’t have to do that. I wasn’t going to return the table. I wasn’t even asking for anything. But they did it anyway — because they cared. Because they listened. Because they understood what great support means.

New leg size approved by my wife.

That’s the kind of service we try to deliver at Mergify.

Even in B2B, even in software, even at scale — you can still surprise people. (Why we still care about quality is about the same mindset.) You can still make them feel heard. You can still wow them. That’s what Amazon did so well for years. And it’s what so many companies forget as they grow.

But it’s not optional. It’s the difference between a satisfied user and a loyal one. Between a customer and a fan.

Build the table. And send the legs.

Not Everything is a Hustle

Tue, 01 Jul 2025 00:00:00 GMT

This Sunday, I made the mistake of opening LinkedIn.

Among the usual weekend calm, a post caught my eye. A young founder proudly explaining how every morning before heading to the office, he cold-DMs 15 people. Every day. Rain or shine.

He then listed all the amazing outcomes of this habit: high-paid jobs, startup funding, conference invites, customer meetings, top hires, you name it.

I couldn’t help but roll my eyes.

So I reshared their post, wrote this instead, and published it on LinkedIn:

Every morning before I head to my home office,
I bring my kids to school.
It’s literally the single most important habit I’ve built.
Want to learn how I do it?
Comment “school” and I’ll tell you my secret.

Boom. Thousands of views.

Because here’s the truth: not everyone is under 30, lives in San Francisco, works at a startup with no users that raised millions, and spends their weekends writing cold emails to VCs and their evening eating pizzas with the team, crushing the latest release.

Some of us are in our 40s.

Some of us are building real companies.

Some of us are taking our kids to school, going for a run at lunch, playing music on the weekends, and still—yes, still—shipping, raising, hiring, and growing.

We don’t brag about skipping meals or sleeping 4 hours.

We don’t show our productivity hacks on a treadmill desk.

We don’t post about cold-DMing 15 people a day.

We just don’t need to turn every moment into content.

So if LinkedIn makes you feel like you’re not doing enough, or not doing it right, just know this:

You’re not alone. You’re not late.

And success can look very, very different.

Take a breath. Pick up your kids. Go for that run.

Enjoy the ride.

Why Engineers Shouldn’t Decide Your Cloud Strategy

Tue, 17 Jun 2025 00:00:00 GMT

Every few months, a new wave of engineers proudly announces their exit from the cloud. “We’re going bare metal. Look at our savings!”.

The thread goes viral. Everyone nods wisely.

But here’s the truth: if you’re making infra decisions without thinking about your growth model, you’re optimizing the wrong thing.

The cloud is not a cost problem. It’s a scaling solution.

Startups don’t pay AWS bills because it’s cheap. They pay because it gives them instant access to global infrastructure they couldn’t build or operate themselves, and arguable, they should not spend time building a team to operate it.

If your business is growing 100% year over year, optimizing gross margin is not your first battle. Surviving growth is.

Datadog has been in the cloud since day one. They’ve scaled revenue 150× over 10 years. The cloud didn’t kill them. It enabled them. They did that while controlling and optimizing their gross margin, but also without spinning up a giant project to double them by leaving the cloud (yet). Why? Because they’re still (a little bit more slowly) growing.

Bare metal works — if you’re not growing much.

Basecamp left AWS. They made noise. But they also “only” grew 6**×** in 12 years — not 150**×**. When growth is slow and predictable, you can (and should) optimize for margin. You have time. You have predictability. Maybe you even have ops engineers with spare cycles. And if you don’t, as you’re not struggling to grow your team, you can expand into infrastructure and internalize it.

When you run out of stamina for growth, you optimize your gross margin; therefore, your cost is what you want to shrink. It’s a different phase.

The same goes for any small or internal project; there might be no need to deal with a cloud provider if you know your infrastructure will not double every year. Just rent or buy a bunch of bare metal servers and deal with them.

Most engineers don’t see the whole picture.

If you follow engineers, they always want to optimize. The problem is that most of them can’t optimize your market, your growth. The only thing they know how to optimize is resource consumption and cost by working more.

Therefore, they’ll look at a line item on the AWS invoice and say, “We could get this cheaper with low-cost bare metal and our team spending time spinning things up.”

Maybe.

Who’s factoring in the cost of talent to manage infra? The time you won’t spend shipping product? The opportunity cost of slowing down? (This is a classic case of solving build vs. buy.)

So… bare metal or cloud?

It depends.

If you’re building a startup and aiming for fast growth: cloud, 100%.
If you’re a slow-growth company with predictable traffic: maybe bare metal.
If you’re a big org running an intranet or legacy app: buy servers, no big deal.

But let’s stop pretending this is just a technical decision.

It’s not.

It’s a strategic one.

Why French Tech Is Playing Not to Lose

Tue, 29 Apr 2025 00:00:00 GMT

There’s an uncomfortable truth in French tech. One that doesn’t get talked about much in conferences or demo days. One that’s quietly baked into a lot of the strategies, funding rounds, and product roadmaps.

Most French tech entrepreneurs are not playing to win. They’re playing not to lose.

They build nice, safe products. They avoid risk. They target the French market, maybe Europe if they’re feeling bold. They slap “sovereign” stickers on their infrastructure and call it innovation.

But let’s be honest: that’s not innovation. It’s insurance.

And it’s killing our chances to matter.

The Safety Bubble

A lot of French startups don’t dream of being global leaders. They don’t set out to compete with the best in the world. They design around constraints. Around regulation. Around what’s “acceptable.” Around what the French government might subsidize.

And for a while, that works. You can build a decent company by playing it safe. Get a few French customers. Raise a seed round. Maybe land a grant from the government innovation bank. Position yourself as “GDPR-compliant,” “cloud sovereign,” “data hosted in Europe.”

Yay. The state might give you a pat on the back. However, no CAC 40 company will buy your product (way too risky to work with you), but if you’re lucky, you’ll land a few scale-ups.

Meanwhile, somewhere in California, someone is building the product that your customers will switch to as soon as they need something that actually moves fast, scales globally, or breaks new ground.

This is the real issue: French entrepreneurs are incentivized to build for compliance, not for users.

And that’s how you end up with European companies that are five years behind their American counterparts, but proudly calling themselves “local alternatives.” They sometimes go as far as making other entrepreneurs feel guilty for using a non-French technology provider because it’s better — especially in those complicated times.

That’s not ambition. That’s surrender in disguise.

Sovereignty Is Not a Product Strategy

Let’s talk about the word that gets thrown around a lot lately: sovereignty.

Yes, it’s important that we have control over critical infrastructure. Yes, data security matters. But it’s not a business model. It’s not differentiation.

You don’t win by saying “we’re like AWS, but French.”

You don’t win by saying “we’re like OpenAI, but hosted in Europe.”

You don’t win by saying “we’re like GitHub, but on OVH.”

An actual email I received today while writing this post.

You win by solving problems better. By innovating. By taking the risk to challenge the status quo.

Sovereign hosting is a checkbox. It’s not a moat.

What frustrates me is that they use it as a crutch. As a justification for not competing with the leaders. As an excuse to stay in their comfort zone and call it strategy.

Meanwhile, the world is moving. And they’re watching.

The US Is Still the Market to Beat

There’s a pattern I see all the time: French startups that refuse to even consider entering the US market.

“It’s too crowded.”

“It’s too expensive.”

“We’ll start with France. Then maybe Germany. Then maybe UK.”

But here’s the thing: the US is the only market that can validate your product at scale. It’s where the fastest companies live. The most demanding customers. The strongest competitors.

If you’re not building with the intention of competing there, what are you doing?

Sure, it’s hard. Sure, you’ll probably get punched in the face. But that’s where you learn. That’s where you improve. That’s where you build something that matters globally — not just locally.

Avoiding the US is not a cautious strategy. It’s a self-imposed ceiling.

French Tech Has the Talent. What’s Missing Is the Fire.

I’m not saying we don’t have the brains. Or the skills. Or the creativity.

We do.

I’ve worked with incredible engineers, designers, product thinkers in France. People who could work anywhere in the world. (I wrote more about what it takes to build globally in The Future Is Being Built Elsewhere.)

But too often, the culture around them is one of caution, not ambition. One where failure is seen as shameful, not as a stepping stone. One where fundraising is seen as the end goal, not the fuel for building something bold.

And when that’s the vibe — guess what? You get safe products. You get local clones. You get decks that talk more about “sovereignty” than about solving user problems in new and interesting ways.

You don’t get industry leaders. You don’t get Snowflakes or Stripes or Notions.

And that’s a shame. Because we could.

We Need to Build Like We Mean It

If we want to matter in the next decade of tech, we need to stop building like we’re afraid.

We need founders who want to win — not just survive.

We need investors who back risky, ambitious plays — not just safe, incremental growth.

We need products that start by targeting the world’s best users — not just the few who care about local hosting.

And yes, we’ll need to fail more. That’s part of the deal.

But at least we’ll be failing forward. Not settling for second place.

Closing

I know this is an unpopular opinion. I know it sounds harsh. But I say this because I want us to do better.

French tech doesn’t lack talent. It lacks urgency. It lacks the hunger to build something that doesn’t just exist — but leads.

And until we face that, we’ll keep getting the crumbs.

From Failure to Focus

Tue, 22 Apr 2025 00:00:00 GMT

Startups love to talk about iteration. Failing fast. Learning from mistakes. But when you’re six months into a project that doesn’t ship — not once, but twice — that mantra starts to feel a bit too real.

At Mergify, we recently spent almost a year building two separate products around CI/CD. Both had potential. Both looked promising. And both ended up in the graveyard.

I have written about this in three posts already: The $100,000 Mistake, When Nobody Wants Your Product, and When Great Tech Isn't Enough.

But here’s the thing: that journey was the best thing that could’ve happened to us because it led to CI Insights, our newest product, which we’re shipping for real this time.

When R&D Goes Off-Road

If you’ve followed the first parts of this series, you know the backstory. In 2023, after years of growing Mergify’s Merge Queue product, we started exploring new ideas.

The first was CI Optimizer — a tool to help teams reduce CI/CD costs. But we quickly learned something important: engineers aren’t the ones who care about CI spend. That’s a FinOps conversation. And FinOps teams weren’t our users.

Then came CI Issues, a project aimed at tracking flaky tests and infrastructure problems. This time we had interest. Teams did struggle with these problems. But we made the mistake of diving into R&D without doing proper design work. We built a complex system — and it worked — but it was so hard to deploy and operate that we never felt confident letting users in.

No design, you said?

So once again, we shelved it.

Two product attempts, zero releases.

But what survived both efforts was a deeper understanding of the pain engineers feel every day around CI.

The Real Problem: CI Is a Black Box

Across all our conversations, one theme kept showing up: visibility.

Teams weren’t desperate to reduce CI costs. They weren’t obsessed with infrastructure failures. But they were all asking the same questions:

Why is our CI pipeline so slow?
Which PRs are consistently the bottleneck?
Which tests are flaky?
Where are we wasting time?

Nobody had good answers. CI is treated like a utility — flip the switch and hope the light turns on. But when it doesn’t, or when it flickers, most teams don’t have the tools to understand why.

We realized what was missing wasn’t a FinOps tool or a smart test tracker — it was observability.

CI Insights: The Missing Layer

With all the groundwork we’d laid — our CI connectors, our data pipelines, our internal dashboards — we already had most of the pieces. We just needed to reframe the problem.

So we did.

CI Insights is the observability layer for your CI.

It helps teams:

Spot flaky jobs and tests
Identify long-running or unstable jobs
Understand where their pipeline is slowing them down
Track trends over time across teams and repos

It’s not about cost savings. It’s not about blaming the CI tool. It’s about clarity — understanding what’s going on, so teams can ship faster and with less frustration.

This Time, We Built It Right

We learned from our previous mistakes.

This time, we:

Started with real use cases from customers and our own internal needs
Designed first, coded second
Focused on value over complexity
Shipped it to users. Yes. Really.

We’ve been using CI Insights ourselves for months now. It already helped us catch flaky jobs, detect broken test workflows, and reduce merge queue delays.

Now, we’re rolling it out to early users — and so far, the feedback has been 🔥.

The Bigger Picture

CI Insights is more than just a tool. It’s a shift in how we think about CI.

It’s not just a thing that “runs your tests.” It’s a critical part of your development workflow. And it deserves the same kind of visibility, metrics, and tooling that you already have for production systems.

We’re building CI Insights to be the best observability tool for CI — because engineers deserve better tools.

What’s Next?

We’re just getting started. The roadmap is full. We’re onboarding users slowly and shaping the product based on real feedback.

If CI is a black box for your team — if you’re tired of guessing why things are slow — we’d love to hear from you.

👉 Request early access

Not Just a Job, It’s a Ride

Tue, 15 Apr 2025 00:00:00 GMT

Hiring is easily one of the hardest jobs I’ve had to do at Mergify. Not because there aren’t smart people out there — there are. But because we’re not just hiring for skill. We’re hiring for mindset.

And let’s be honest: that’s a lot harder to screen for than technical chops.

When you’re building a startup, every new hire changes the shape of the team. Every person matters. You’re not adding a cog to a big machine — you’re inviting someone on the ride with you, and they’d better be ready for the speed bumps.

What We Actually Look For

At Mergify, we look for people who care. Not just about clean code or nice UI — but about the mission. The thing we’re building. The problems we’re solving. If what we’re doing doesn’t excite you, we’re not going to try to sell it to you. We want you to come in already leaning forward.

We’re looking for people who aren’t title-driven but outcome-driven. People who will get things done even when no ticket has been assigned or clear ownership has been defined yet. That happens a lot.

You need to bring ideas, not just execute someone else’s. We expect initiative, curiosity, and autonomy.

We provide a good summary of our vision and mission on our website.

Autonomy Isn’t a Buzzword, It’s the Filter

Here’s a small story that stuck with me.

We had a candidate once who asked me during the interview, “Who’s in charge of breaking down the project into tickets?”

I said, “You are.”

That was enough to scare them off — and that’s OK. At Mergify, you’ll be expected to do exactly that. Define your work, structure your plan, ask questions when you need to — but no one’s going to hand you a Jira board and a user story spec for every task.

If that makes you nervous, we might not be the right place. If it makes you excited? You should talk to us.

Startups Are Messy. That’s the Point.

You can’t build a startup with neat little boxes around every role.

One week, you might be writing code. The next, you’re giving a talk at a meetup. The week after, you’re helping a customer figure out something weird in their CI pipeline.

We look for people who can jump between lanes without crashing the car. If you need clear job boundaries, startup life will drive you insane. But if you like wearing multiple hats (sometimes in one day), you’ll thrive here.

Wearing multiple hats.

Hiring Mistakes: Yep, We Made Some

One of our early missteps? Underestimating how hard remote work can be — for some people.

We’re fully remote, and we love it. But not everyone is cut out for it. We’ve had brilliant engineers who struggled because they needed more structure, more hand-holding, and more real-time sync. (I wrote about this in Remote Work: Great, But Not Perfect.) And we’ve learned the hard way that great resumes don’t always mean great remote workers.

Now, we screen harder for that. Autonomy, again, is a big part of the puzzle.

Our Hiring Process (And Why We Meet in Person)

Our process is pretty standard on the surface:

👉 A technical test

👉 A technical interview

👉 A CEO chat

👉 An onsite interview

👉 Reference checks

We’ve documented the whole thing on our website, so there are no surprises.

But one thing we insist on: we meet you in person.

Remote or not, hiring is a human process. A real-life conversation can reveal things that a dozen Zoom calls won’t. We’ve avoided a few bad hires because we took the time to meet face-to-face.

Motivation Over Résumé

The biggest signal we look for? Why you want to join.

We try not to overexplain this part publicly, because it’s one of our most effective filters. But let’s just say: if your reason for leaving your current job is “looking for a remote job,” we’ll probably pass.

We want people who are actively choosing this kind of work, people who are ready for the ambiguity, the responsibility, and, yes, the chaos.

Hiring for Roles You Don’t Know? Brutal.

When we hired our first designer, it took us way longer than it should have. Why? Because we didn’t know how to assess the role.

If you’ve never done the job yourself, hiring for it is like ordering dinner in a language you don’t speak. You might get lucky, but you probably won’t.

We’ve learned to spend more time understanding what we actually need before we go looking for someone to do it. Sounds obvious. It’s not.

What’s Hard Now?

Right now, our biggest challenge is finding candidates who combine technical skill with startup DNA.

We’re looking for people who’ve spent a few years in early-stage companies, who know what it’s like to ship fast, wear multiple hats, and stay sane through ambiguity. Not just smart — adaptable.

If That’s You…

Then maybe we should talk. If you’re looking for more than just a job — if you want to build something, shape it, and take pride in it — you might belong here.

We’re picky, yeah. It slows us down. But we’ve learned the cost of the wrong hire is much higher than waiting for the right one.

So if you’re ready for the ride, we’re hiring.

When Great Tech Isn’t Enough

Wed, 26 Mar 2025 00:00:00 GMT

Welcome to the third post in our “we-built-something-and-killed-it” series.

In the first chapter, we shared how we started building CI Optimizer—our ambitious attempt to help teams cut down on CI/CD costs.

In the second, we explained why that effort never made it past the runway: while the problem existed, no one really wanted the solution.

But that wasn’t the end of the story.

Because just as we were winding down CI Optimizer, something else started to take shape—almost accidentally.

From CI Cost to CI Chaos

As we were working on CI Optimizer, we had to dig deeper into CI platforms like GitHub Actions or CircleCI. We needed to understand the structure, failures, and performance of CI pipelines to measure their cost.

And the more we explored, the more something else stood out: teams weren’t just struggling with CI/CD costs—they were struggling with CI reliability.

❗Flaky tests.

❗Unreliable runners.

❗Timeouts.

❗Random infra failures.

And as users of our Merge Queue product kept telling us:

“Our workflow is fine—until CI starts acting up.”

So we asked ourselves a new question:

💡 What if we stopped focusing on how much CI costs, and started looking at how much CI hurts?

That’s how the idea for our next product—CI Issues—was born.

The Pivot: CI Issues

CI Issues was meant to do one thing really well:

Track, identify, and alert on CI problems before they silently torpedo developer productivity.

We wanted to give teams insight and visibility into:

How often their tests flaked
Whether their CI infrastructure was unreliable
Which PRs were impacted
Which workflows deserved attention

The goal wasn’t just dashboards. It was detection and action. You’d be able to see patterns, set alerts, and flag recurring issues before developers noticed them.

And as we started to pitch the concept to engineers, the excitement was real:

💬 “We have this exact pain.”

💬 “We’ve built half of this internally.”

💬 “Please let us know when it’s ready.”

We felt like we were onto something.

The R&D Rabbit Hole

So we jumped in headfirst. We already had code collecting and analyzing CI data, so we started adapting it for CI Issues.

We ran the system internally, refined metrics, tested detection logic, built a first UI. And then we iterated. And iterated. And iterated again.

But something was off.

Every time we looked at what we had, the same thought came back:

“This is good… but it’s not a product.”

It was barely working for us internally. Even we had trouble using it.

It was noisy. It was complex. It was fragile. It wasn’t obvious how to deploy or operate it at scale.

We had built tech.

But we hadn’t designed a product.

The Realization That Stopped Us

After almost a year of work, we paused and took a step back. And it hit us:

We had made the same mistake again—but in a different way.

With CI Optimizer, we had no market.

With CI Issues, we had no design.

This time, it wasn’t the problem that was flawed—it was our approach.

We had focused on research, experimentation, pipelines, metrics, code—but we hadn’t put the same energy into figuring out how the product should be used.

How would teams onboard?

How would they configure it?

How would they act on the data?

What does success look like for them?

The longer we waited to answer those questions, the more we realized:

💣 “If we ship this now, we’ll be building another tool that’s hard to use, hard to maintain, and ultimately, unadopted.”

So we made the call—again.

We stopped.

What We Learned (This Time)

This second failure didn’t sting the same way as the first.

In fact, it felt like a necessary part of the journey.

Here’s what we learned:

Validation isn’t enough—you need design.

Even if users want a solution, they won’t use a product that’s hard to operate or understand.
Great tech doesn’t mean great UX.

CI Issues worked, technically—but without thoughtful design, it was dead in the water.
You need both clarity and empathy.

Clarity on what you’re solving, and empathy for how your users will experience it.

What’s Next?

The story doesn’t end here.

CI Issues gave us a powerful insight into how fragile and painful the CI experience can be—and how underserved engineers still are when things go wrong.

So we took everything we learned from CI Optimizer and CI Issues, and went back to the drawing board—with a new vision, new design principles, and a better understanding of how to build the right thing the right way.

Stay tuned for the final post in the series: what we built next, and how it’s going to change how developers deal with CI failures.

When Nobody Wants Your Product

Tue, 04 Mar 2025 00:00:00 GMT

In the first part of this series, we introduced CI Optimizer, a product we were convinced would help engineering teams reduce their CI/CD costs. Given the economic downturn in 2023, we saw budgets tightening, companies folding, and engineering teams being forced to justify every dollar they spent.

If you missed the first part, read it here.

It seemed like the perfect time to launch a tool that would bring cost visibility and optimization to CI/CD workflows.

We started building immediately, setting up a landing page and a waitlist, and running early customer interviews. Our approach was clear:

Build the product.
Talk to potential users.
Iterate based on feedback.

But as we reached out to customers, one thing became clear:

💡 Nobody really cared about optimizing CI/CD costs.

This was the moment we realized we were building something that might never find an audience.

Trying to Sell the Product Before It Existed

I strongly believe that you should be selling a product before it even exists. If you can’t generate demand when it’s just an idea, chances are you won’t generate demand once it’s built.

So, as we were writing the first lines of code, we also launched:

✅ A marketing campaign to build awareness.

✅ A landing page with a waitlist.

✅ Customer outreach to gauge interest.

Our goal was to validate demand early—before we wasted months building something nobody wanted.

But things didn’t go as expected.

The First Red Flag: Engineers Didn’t Care

As we started talking to users, the first warning sign was that engineers were simply not interested in optimizing their CI/CD costs.

💬 “Sure, spending less money is nice, but it’s not a priority.”

💬 “We’ve never been asked to reduce our CI/CD spend.”

💬 “CI is just a necessary cost of doing business.”

This was surprising. We expected companies to be actively looking for ways to cut costs, but instead, we found:

👉 Engineers weren’t incentivized to optimize costs. Most of them were measured by features delivered and bugs fixed, not by how much they spent on infrastructure.

👉 Budgets were tight, but existing expenses weren’t scrutinized. Many teams were cutting new expenditures, but existing CI/CD costs were just accepted as part of doing business.

👉 It wasn’t an engineering problem—it was a finance problem. Even when engineers acknowledged CI/CD spending was high, they said, “This isn’t my job to fix.”

In short:

🚨 We had built a solution for a problem our audience didn’t care about.

But we weren’t ready to give up yet.

The Second Red Flag: Talking to the Wrong People

Since engineering teams didn’t seem to care, we were often redirected to FinOps teams—the financial teams responsible for tracking cloud spend.

So we thought, “Great! Maybe this is our actual target audience.”

We started talking to FinOps teams, and here’s what we discovered:

💬 “We don’t need another tool—we just need a report in a spreadsheet.”

💬 “Can you just give us an API so we can generate cost breakdowns?”

💬 “We don’t want to ‘optimize’ CI/CD automatically. We just need visibility.”

💬 “If we were to buy your product, we’d need more than reporting. We want automatic cost optimization.”

Here’s where we ran into our second major issue:

🚨 We were not equipped to build a product for FinOps teams.

We understood engineers. We had deep experience with CI/CD workflows.

But we knew nothing about selling to FinOps.

Selling to FinOps teams is a completely different game.

They care about budgets, forecasting, and high-level cost reporting, not about how CI/CD actually works.

Even worse:

❌ The product we had in mind was too technical for FinOps teams.

❌ The version they needed was much more complex and would take a year to build.

❌ We would be competing against massive cloud cost monitoring tools, not other DevOps tools.

At this point, we had two choices:

Keep building a product for engineers who didn’t care.
Completely pivot to a new audience we didn’t understand.

Neither option looked good.

The Hard Decision: Killing the Product

By the six-month mark, we had spent:

🕚 Hundreds of hours building a proof-of-concept.
📞 Countless customer calls trying to validate the idea.
💬 Weeks refining our messaging to see if we could spark interest.

But deep down, we knew the truth:

❌ Engineers wouldn’t pay for cost optimization.
❌ FinOps teams needed something completely different.
❌ There was no clear path forward.

And so, after six months of work, we made the hardest decision a product team can make:

We killed the project.

Instead of pushing forward with a product that had no market, we pivoted to something else—which I’ll reveal in the final part of this series.

Lessons Learned

Even though we ultimately abandoned CI Optimizer, the experience taught us some critical lessons about building new products:

Talk to Customers Before Writing Code

We should have validated demand before starting development. Building first and testing later is a risky approach. Fortunately we mitigated this by talking while building.

Engineers Don’t Always Care About Cost Savings

Developers are focused on shipping code, not cutting costs. If a product doesn’t directly impact their work, they won’t engage with it.

Just Because a Problem Exists Doesn’t Mean It Needs a Product

Companies do spend too much on CI/CD, but that doesn’t mean they’re looking for a tool to fix it. Some problems are simply not painful enough to justify a new product.

Selling to Finance Teams is a Whole Different Game

FinOps teams think differently from engineers. If your product doesn’t fit into their existing finance workflows, they won’t use it.

Know When to Walk Away

One of the hardest skills in startups is knowing when to cut your losses. We could have wasted another 6–12 months building something nobody wanted. Instead, we chose to fail fast and pivot.

What’s Next?

Even though CI Optimizer never launched, it wasn’t a wasted effort.

In fact, the insights we gained from this failure led us to build something even better.

In Part 3, I’ll reveal how we took everything we learned from this failure and pivoted to a product that actually resonated with engineers—and how that decision changed the trajectory of Mergify.

The $100,000 Mistake

Tue, 18 Feb 2025 00:00:00 GMT

A Journey into Startup Reality

Not every startup success story begins with a garage, two co-founders, and an overnight explosion of users. And not every failure is a dramatic, fiery crash. Some of the most valuable lessons happen in the quieter moments—when you’ve built something, spent months refining it, and then realized you were solving the wrong problem all along.

This is the story of CI Optimizer, a product we believed would transform the way companies managed their CI/CD costs. We spent six months designing, building, and testing it—only to ultimately kill it before launch.

Why? Because we made one fundamental mistake.

This three-part series is not just about the technical challenges of optimizing CI/CD or the intricacies of pricing cloud infrastructure. It’s about the hard reality of building a product, talking to customers, and realizing you missed the mark.

If you’re an entrepreneur, a product builder, or just someone fascinated by the messy, unpredictable world of startups, this series is for you.

Let’s start at the beginning.

How It Started

At the end of 2022, Mergify was on a roll.

We had spent the past year growing steadily, tripling our revenue, refining our Merge Queue product, and deepening our place in the DevOps ecosystem. Our customers were engaged, our product-market fit felt strong, and our team fired on all cylinders.

But as the year drew to a close, something in the air felt different.

Conversations with prospects were shifting. Instead of discussing new features and scaling up their usage, they were hesitant. Startups—our core audience—were tightening their budgets. Investors were slowing down. Some of our customers simply disappeared.

First, it was the crypto companies. Then, real estate tech. One by one, they went silent—not because they didn’t love our product, but because their businesses were collapsing. The market was crashing. Funding was drying up.

The message became clear:

“We love Merge Queue, but our budget is frozen.”

We knew we couldn’t just sit back and hope the market would bounce back. We needed to adapt. That’s how startups survive.

And that’s when we had what we thought was a brilliant idea.

The Birth of CI Optimizer

One undeniable truth about software engineering is that CI/CD is expensive.

Every build, every test, every deployment—it all costs money.

At scale, those costs grow exponentially, often without teams fully understanding where their budget is going. Developers push a change, run a full test suite, and move on. But in the background, cloud bills are racking up, and finance teams are left wondering where all that money is going.

So we thought:

“What if we built a tool that gave teams complete visibility into their CI/CD costs? What if we could identify waste, eliminate unnecessary builds, and optimize pipelines automatically?” What if we could help companies save money on their CI without slowing them down?”

It sounded like a no-brainer. We’d build a smart system that could analyze CI/CD usage and recommend cost-saving adjustments—maybe even automate them.

This is something we could even use ourselves to save on our CI/CD bills.

This wasn’t just an idea—we were convinced we had struck gold.

Building the Future of CI/CD Cost Optimization

By early 2023, we had begun prototyping.

The first step? Connecting to GitHub Actions. GitHub, like many CI/CD providers, is well known for not providing a good report on cost analysis (still true as of today). Since GitHub is where all of our customers are, this made sense.

We needed to pull in detailed CI/CD usage data and break down the cost per minute of every build. Our system would scan pipelines, report metrics, identify inefficiencies, and provide actionable insights—like which jobs were wasting the most money.

It felt like a natural extension of what I had worked on years earlier at Datadog, where I had pushed for replacing CPU seconds with dollar values in profiling tools. The goal was simple: make CI/CD costs tangible, trackable, and optimizable.

We saw an opportunity to build something that would fit neatly into engineering workflows. The logic was airtight:

✅ Developers hate waiting for builds.

✅ Developers need to get more budget.

✅ We could solve both problems at once.

Or so we thought.

What We Hoped to Prove

Our plan for early 2023 was straightforward:

1️⃣ Build an MVP that could accurately measure CI/CD costs at a granular level.

2️⃣ Talk to real users and validate whether CI/CD engineers cared about cost optimization.

3️⃣ Launch a first version of CI Optimizer and start onboarding teams.

We expected engineers to tell us:

“This is amazing! We’ve been waiting for something like this!”

But that’s not what happened.

Instead, we hit an unexpected roadblock that completely changed the course of the project. (Read what happened next in When Nobody Wants Your Product.)

Remote Work: Great, But Not Perfect

Tue, 21 Jan 2025 00:00:00 GMT

Running a fully remote company is an incredible experience, and I say this as someone who’s been working remotely for the past 15 years and managing a remote-first company, Mergify, for the last five. Yet, after a week of in-person collaboration with my team in Toulouse, I feel compelled to reflect on what makes remote work great—and where it falls short.

Let me start by saying this: remote work is fantastic, but it’s not perfect. It’s a trade-off. Depending on your company’s stage, your team’s roles, and the challenges you’re facing, the choice between remote, hybrid, or in-office work can make all the difference.

What Makes Remote Work Amazing

The benefits of remote work are undeniable:

Focus and Efficiency: Remote work allows individuals to dive deep into their tasks without the distractions of an open office.
Work-Life Balance: Cutting out commutes and office hours lets people design their schedules in ways that suit them best.
Access to Global Talent: A remote model lets you hire the best person for the job, no matter where they are. At Mergify, this has been invaluable.
Flexibility and Autonomy: Remote work naturally fosters a culture of trust, where people take ownership of their time and deliverables.

But here’s the catch: communication in remote work isn’t as fluid as in-office communication.

Why In-Office Communication is Superior

Face-to-face communication is powerful in ways that virtual communication simply can’t replicate. It’s not just about words—it’s about body language, energy, and subtle nonverbal cues that humans naturally pick up when we’re in the same room.

When you’re remote, everything has a higher latency. Sure, you can make video calls, send Slack messages, and send emails, but it’s like having a conversation with poor reception. You’ll get your message across, but it’s less fluid and often lacks the nuances that make communication easy and productive.

Now, this might not be a problem, depending on where you work.

For startups, this trade-off is especially magnified. When you’re building something new and need constant alignment, the lack of spontaneous coffee chats and hallway conversations slows you down. Good ideas often spark from casual interactions—something much harder to replicate remotely.

The rollercoaster, that a startup is, requires sharing the energy and adrenaline that you get from awesome news and the comfort that everyone needs when some cloudy day happens. But it’s hard to get the vibe from your coworkers when they are far away. The connection is more difficult to make and maintain.

The Remote vs. Office Matrix

Consequently, the choice between remote and office work isn’t one-size-fits-all; it’s a matrix of role and company size:

Large Companies: For individual contributors, remote work can be as effective as being in the office. In large organizations, communication often requires structure anyway, and remote tools can handle most of this. However, for managers in these settings, the lack of face-to-face interaction can make it harder to truly understand what’s going on in their teams.
Startups: For smaller companies and startups, where speed, creativity, and alignment are critical, remote work becomes trickier. It’s harder to maintain momentum and cohesion when everyone is isolated. Founders and managers need to be proactive, creating systems for communication and connection that compensate for the lack of in-person collaboration.

Of course, it’s an oversimplification, and it requires nuance, but you get the gist.

The matrix also applies to roles:

Individual contributors, particularly in large companies, the need to be physically present in an office can feel unnecessary. Their work often revolves around tasks that require focus rather than constant communication or managing teams. Sitting behind a desk all day in an office doesn’t necessarily enhance their productivity or add value to their contributions.
On the other hand, managers, especially in startups, face unique challenges with remote setups. Their roles demand frequent interaction, gauging team dynamics, and fostering collaboration. Without the ability to observe non-verbal cues or engage in casual, spontaneous conversations, understanding the team’s morale and addressing issues proactively becomes significantly harder.

The same goes for seniority:

Junior employees typically require more hands-on management, regular feedback, and frequent check-ins. Without the autonomy or experience to navigate challenges independently, they benefit greatly from close guidance and structured oversight.
In contrast, senior employees tend to be highly autonomous. They often need minimal direction, excelling at managing their own work and making decisions. They are comfortable raising issues or seeking input when needed, allowing them to operate effectively with little interaction from their managers.

This is one of the reasons there has been so much vociferation against Return to Office (RTO) mandates promulgated in recent years, especially in larger companies and amongst senior individual contributors.

The Mergify Experience: Remote, But Not Alone

At Mergify, we’ve been fully remote from the start, and we’re committed to staying that way. But we know it’s not without challenges. Here’s how we’ve managed the trade-offs:

Intentional Connection: We schedule regular virtual coffee breaks to foster camaraderie and maintain a sense of community.
Quarterly On-Sites: Every few months, we bring the team together in person. Our recent week in Toulouse was a reminder of how valuable these moments are—not just for productivity but for bonding as a team. Sharing meals, brainstorming in person, and simply spending time together are irreplaceable experiences. Nothing beats your team being yelled at by the game master of an escape game for having hacked your way around the solution, in true startup spirit. 😅
Focus on Proactivity: Remote work requires deliberate communication. Everyone on the team needs to take the initiative to keep each other informed and aligned.
Hiring for Autonomy: A remote model of self-motivated, independent individuals who excel without constant oversight. Building a team with these traits has been crucial for our success. Not everyone is made for remote work. (More on this in Not Just a Job, It's a Ride.)

RTO and the Future of Work

The current trend of companies mandating a Return to Office reflects the challenges of remote work—particularly for management. It’s easier to see what’s happening, build trust, and foster collaboration in person. Yet, for many roles and organizations, remote work remains a superior option.

The reality is that no single model is perfect. For some, the trade-offs of remote work are worth it. For others, the benefits of in-office collaboration outweigh the flexibility of remote setups. What matters most is that companies recognize these trade-offs and build systems that suit their unique needs

Remote work is here to stay, but it’s not a panacea. It’s a trade-off between flexibility and connection, efficiency and spontaneity. At Mergify, we’ve embraced remote work with open eyes—recognizing its strengths while finding ways to address its weaknesses. Whether remote, hybrid, or in-office, the key is to adapt, experiment, and keep evolving.

What’s your take on the remote vs. office debate? Let me know in the comments or reach out—I’d love to hear how others are navigating this shift.

Reflecting on 2024

Tue, 07 Jan 2025 00:00:00 GMT

As 2025 begins, I’m taking a moment to reflect on an eventful 2024—a year of evolution, challenges, and new beginnings for me and Mergify. Building a bootstrapped company comes with its own unique highs and lows, and 2024 was no exception. Here’s what the past year taught me and how it has shaped the future of Mergify.

Keeping Mergify Thriving in a Changing Market

Surviving and thriving as a bootstrap startup is always worth celebrating, especially in a niche like ours. In 2024, we doubled down on what makes Mergify special: our Merge Queue product, which remains the best in the market for helping engineering teams manage pull request workflows.

That said, we also recognized our limitations. While we’ve always been proud of our technology, we realized this year that having great tech isn’t enough. For years, Mergify was more of a tech-driven company than a product-focused one. This year, we worked hard to change that, shifting our mindset to prioritize product design, usability, and scalability.

The advancement of competitors, such as GitHub, forced us to rethink our strategy. We’ve been evolving in a niche for years, and it’s now time for us to expand our vision beyond what we’ve been doing so far.

2024 also brought some tough lessons about the realities of the market. We initially decided to double down on marketing in late 2022, deploying our efforts during all of 2023. However, after the startup market crash of late 2022, we spent much of 2023 navigating a challenging environment where companies were hesitant to adopt new tools. As that trend continued into early 2024, we ultimately decided to scale back our marketing efforts and rethink how we approach growth.

The truth is that marketing alone can’t solve every problem—especially in a niche like ours. Instead, we’re focusing on building the best products possible and letting our work speak for itself. This approach has already started to pay off, and we’re more confident than ever in Mergify’s future.

A Shift Toward Product and Design

Consequently, one of the pivotal moments in 2024 was hiring a designer—a first for Mergify. This move sparked a transformation in how we approached our product. It wasn’t just about solving technical challenges anymore; it was about creating an experience developers love.

New Mergify design

This new focus led to a complete redesign of our branding and dashboard, making it easier than ever for teams to onboard and use Mergify. It also paved the way for new products like Merge Protections, a tool for managing repository freezes and policies. This was the first product we built with a product-driven mindset from the ground up, and it’s already gaining traction with customers.

Back to Founder Mode

In 2024, I found myself returning to what is now called “founder mode.” For the first time in years, I rolled up my sleeves and dove back into coding and product development. Writing Python again, designing architecture, new workflows, and collaborating directly with the team reminded me of the early days of Mergify—and how much I enjoy building things.

This hands-on approach was fueled in part by the rise of AI tools, which have transformed how we work. From speeding up R&D to enhancing productivity, AI has helped us stay agile and efficient as we tackle big challenges in CI/CD.

Doubling Down on R&D

Speaking of challenges, research and development was a major focus for us in 2024. We spent a lot of time exploring how to solve some of the toughest problems in CI/CD, like flaky tests, CI failures, and observability issues. These pain points resonate deeply with our customers, and we’re excited to bring solutions to market in 2025.

Our work so far has been a team effort, but it’s also required stepping outside our comfort zone. We’ve been engaging more directly with developers, learning from their frustrations and workflows, and using those insights to shape our next big product.

On a Personal Note

Outside of Mergify, 2024 was a year of rediscovery for me. I started writing again, leaning on tools like GPT to help me produce regular content and share my thoughts with a wider audience. Writing has always been a way for me to reflect, and having the discipline to do it consistently has been rewarding.

I’m also trying to teach my kids to take photographs

I also continued my work as a business angel, supporting other startups and sharing what I’ve learned from building Mergify. While balancing this with my responsibilities at Mergify can be challenging, it’s incredibly fulfilling to help others navigate the ups and downs of entrepreneurship.

I continued publishing episodes of Nom d’un Pipeline !, my French CI/CD-themed podcast. This has been a tremendous way to meet new people and learn stuff. I really enjoy the exercise of podcasting, and I’m looking for an excuse to start a new one this year.

I also recorded several episodes as a guest, one in French in IFTTD, another one in French and in Toulouse on the future of tech, another one in French on The Cloud Screener, one on The Python Show, and, finally, one with saas.group.

Looking Ahead to 2025

As I look to the year ahead, I’m more excited than ever about what’s next for Mergify. We’re working on new products that tackle critical pain points in CI/CD, and we’re committed to helping developers ship faster and with less friction. At the same time, we’re staying true to our roots as a bootstrap startup—focused, agile, and always learning.

2024 was a year of growth in every sense of the word. It challenged us to think differently, to embrace new ideas, and to keep pushing forward. As we enter 2025, I’m grateful for the lessons we’ve learned, the customers we serve, and the incredible team that makes it all possible.

Here’s to another year of building, learning, and growing.

The Engineer’s Dilemma: What We Did Right at Mergify

Tue, 05 Nov 2024 00:00:00 GMT

In the early days of Mergify, the journey Mehdi and I embarked on wasn’t unique. In fact, it’s a tale as old as time for engineer founders: a couple of smart engineers, passionate about technology, with an exciting vision to revolutionize their space. We had everything we needed—or so we thought: the knowledge, the technical expertise, and the drive to build something incredible.

This is where the story of Mergify begins, but what often happens next is a classic mistake that many tech founders make. They build a beautiful, feature-packed product that doesn’t solve a real problem—or even worse, it solves a problem no one has. This is the hard lesson that too many engineers learn too late, and it could have easily been us.

But we managed to steer our ship in a different direction, and looking back, there are key things we did right. Let me take you through that journey.

The Temptation of the Tech

For any engineer, there’s nothing more fun than building. The thrill of creating a new feature, optimizing your product, or pushing out updates can become intoxicating. Mehdi and I felt this pull strongly when we started Mergify. We had big ideas, a packed roadmap, and technical solutions that we were eager to implement.

But here’s the thing: technology, while critical, is only a part of building a successful SaaS business. We could have easily fallen into the trap of focusing solely on the tech and neglecting the most important piece of the puzzle: the customer.

We both had to confront the reality that building an amazing product wasn’t enough. If we didn’t speak to our customers, understand their pain points, and really get to the heart of their problems, we were going to fail.

This is where so many engineer-founded startups stumble. They fall in love with their technology rather than falling in love with solving the customer’s problem. Luckily, we managed to recognize this early on.

Engineers Need to Talk to People

Talking to customers doesn’t come naturally to most engineers—it didn’t for us either—but it was a necessary step. While it’s tempting to stay behind your keyboard, tweaking code or adding features, the real magic happens when you step out and listen to what your customers are saying. What do they struggle with? What would make their lives easier? What’s keeping them up at night?

I remember one story about two bright engineers who reached out to me on LinkedIn, seeking advice. We decided to meet at a bar. They had spent three years working on a fantastic piece of technology but hadn’t seen any traction. Why? because they hadn’t built it with a customer in mind. The tech was solid, but it didn’t solve any real problem. They hadn’t spent time talking to users, and so the product existed in a vacuum.

You've got to start with the customer experience and work backwards to the technology — Steve Jobs (1997)

With Mergify, we knew that if we were going to build something with a lasting impact, we needed to constantly engage with our community and understand their problems. It wasn’t enough to have a great piece of technology—we had to have a great solution to a real problem.

Shifting Roles for Success

One of the smartest things Mehdi and I did early on was divide our roles clearly. We knew that if both of us were deep in the tech, Mergify would never succeed. So, while Mehdi stayed focused on building the product, I took on the role of sales, marketing, and customer interaction.

For an engineer, stepping into these roles can be uncomfortable at first. Sales? Marketing? Communication? These aren’t things they teach you in computer science class. But it was a necessary shift and one that paid off.

I drew from my experience selling self-published books. I knew that just because you write something doesn’t mean people will read it. You have to market it, spread the word, and get it into the hands of people who need it. The same principle applied to Mergify. We couldn’t just build features and expect users to come flocking. We had to sell it, promote it, and make it known. This is still something we need to do to this day.

The Hard Truth

The truth is, you can have the best technology in the world, but if you don’t have customers, it’s worthless.

I remember another encounter at a wedding, where the bride's father introduced me to his nephew—a tech entrepreneur. The moment I heard him describe his startup, I already knew what was wrong. “You’re not selling anything, are you?” I asked. The bride’s father looked at me, astonished by the boldness of my assumption. And sure enough, he wasn’t. He and his co-founder, both engineers, had spent their time adding features instead of learning how to sell their product. He admitted that I was not the first to tell them it was one recipe for a disaster.

At Mergify, we avoided that trap. We recognized early on that while the tech needed to be solid, the success of our business depended on our ability to market and sell it.

What We Did Right

So, what did we do right at Mergify? We talked to our customers, really talked to them. We asked questions, learned about their challenges, and made sure we were solving their pain points. We didn’t fall in love with our technology; we fell in love with the problem. And most importantly, we divided and conquered. Mehdi stayed on the tech while I trained myself in the art of sales, marketing, and product management.

These steps weren’t easy, requiring us to step outside our comfort zones, but they made all the difference. Five years later, Mergify isn’t just a successful SaaS company because we built great tech — it’s successful because we solved real problems for real people. (For a different angle on the same lesson, read Tech Is the Easy Part.)

And that’s the real lesson for any engineer founder: focus on the problem, not the tech, and you’ll go far.

Why Stock Options are Terrible for Employees

Tue, 08 Oct 2024 00:00:00 GMT

Imagine you’re joining a startup, excited by the potential to share in its future success. You’ve just been offered stock options. What do they actually mean for you?

You’re not sure if you need to negotiate these terms, or even what they imply. Once you’re in, someone mentions them during a coffee break, and you’re confused all over again. Whatever—you decide to see how it plays out. Maybe you’ll get filthy rich without understanding why. Maybe you’ll get screwed over. Who knows?

As a tech employee, tech entrepreneur, and investor, I’ve had my share of discussions with fellows about stock options over the last decade.

Stock options are a great leverage for founders to share future value with their (early) employees. The intention behind it is noble, but using them has terrible drawbacks.

Understanding What You Get

When I joined Datadog a few years ago, they offered different packages that you had to choose from:

Option 1: a small salary, a large number of stock options;
Option 2: a medium salary, a medium number of stock options;
Option 3: a large salary and a small number of stock options.

I believe many tech companies use the same template.

A few months after I joined, the company IPO’ed. I went to a coffee break and chatted with one of my colleagues. The recent IPO and the rising stock values sparked the conversation. They asked me, “Which option did you pick when you joined?” I replied that I was looking for a venture back then, focusing on wealth creation, so I picked option 1—the salary was enough for me to live.

They replied that they now regretted picking option 3.

I suspect that most employees were more attracted to larger salaries than stock options. I wish somebody from HR could confirm the stats about what I observed, but I doubt they would. The truth is, even HR did not understand what they were doing.

When I got offered the 3 packages above, I asked what the value of the stock options was. Stock options are options (no shit), meaning they offer you the right to buy shares of a company. My natural question was: what was the price of this option, what was the company's value back then, and what was the total number of outstanding prices?

The recruiter’s answer was: 😳

Nonetheless, I insisted, and they escalated my question to an HR director. The director ended up reaching out to the US side of the company. They finally showed me a spreadsheet with the number I was asking, easing my final decision.

The lesson? Always ask for clarity on the value of your options before deciding. If even the recruiter is unsure, push until you understand what you’re getting.

Not Everyone is an Investor

If you ask people what investing is all about, they’ll reply with “finance and maths.” That’s true, but it’s only one part of the equation. Investing is also a very psychological discipline; not everyone’s ready for that.

When I was working at Red Hat, the company used to distribute RSU (Restricted Stock Units) to its employees. RSUs are basically free stocks. You’d get a bunch of those every year and could keep them, therefore becoming a shareholder, or sell them on the market and get cash in exchange.

As the company was on a growth trajectory back then, the stock would keep climbing every month or so.

Red Hat stock history before being bought by IBM in 2019.

Most people I worked with were young engineers and not investors. They had no clue why the stock would fluctuate.

One day, I was chatting with a colleague over a beer, and they seemed worried. I asked what was wrong, and they explained that they had lost thousands of dollars over the last month because Red Hat stocks had plunged. They had received RSUs over the last years and were so happy with their growth that they never sold them and didn’t think they could crash. Now, they were upset and did not know what to do.

Of course, they did not know what to do.

They had no way to know if the stock was overvalued or undervalued.

They had no idea if the market would continue its bull run or if a bear market was upcoming.

They were no investors. They had no plan, and the uncertainty left them feeling lost.

How to Approach Stock Options as an Employee

Owning stock options (or RSUs) means one thing: you are becoming an investor. It means that you now own (potentially, in the case of options) a part of a company with a market value and an intrinsic value. If you cannot assess the value or form an opinion on your company’s stock, you probably shouldn’t be a shareholder.

I know. It’s not your fault. You didn’t ask for it, but this is what happens if you stick to your stock. You are transformed.

As an employee, should you keep or sell your Airbnb Inc. stock? When do you sell? Why?

→ Once you vest your RSUs, if don’t sell them immediately in exchange for cash, you’re effectively becoming an investor.

→ When a liquidity event occurs, and you choose not to exercise your stock options, you are deciding to become an investor.

It’s great to be an investor, for sure. But that comes with many questions: what’s my allocation policy? What’s my exit strategy? What is my risk tolerance? What is my investment horizon? What are the tax implications? How well do I understand the business model? Do I trust the leadership team? What’s my plan if things go wrong? How does this investment fit into my overall financial plan?

Investing isn’t just about understanding finances; you also need to handle fear, greed, and uncertainty. Most people aren’t ready for the psychological strain of watching their savings plummet overnight.

CrowdStrike shares lost 50% of their value during the incident in 2024.

Stock options can be a powerful motivator, but they aren’t for everyone. Next time you’re offered stock options, think like an investor—ask the tough questions, seek clarity, and ensure you’re prepared for both the financial and emotional aspects of investing.

If you then plan to stick to your stock, decide whether you truly want to become an investor and learn the trade. If you don’t, it’s fine; just get your money and enjoy it. ✌️

Why You Need Product Engineers

Tue, 01 Oct 2024 00:00:00 GMT

A couple of weeks ago, I attended our quarterly MAHOS (Mergify All Hands On-Site)—an event where we gather the whole Mergify team together for a week—and gave a small speech about product engineers.

Mergify’s team, Sept. 2024

I was unsure if I coined the term product engineer at that time or if it already existed. After Googling, I found that I was not the only one who realized that we no longer need software engineers.

When we started our venture a few years ago and decided to hire engineers, we naturally looked for software engineers. We found great engineers. They learned a ton of stuff working with us over the last couple of years and became very efficient at producing code. Awesome. I wrote last month about how to become a great software engineer, and while I hold to this, the next step in your career, if you want to work in a product-oriented startup, is to become a product engineer.

What is a Product Engineer?

Is that just a software engineer building a product? Yes! But that is not what a software engineer does by default. Let me tell you an anecdote.

Last month, with my product owner hat on, I wrote a user story explaining one of the changes we needed to make in Mergify: feature X is enabled by default in the product, which is annoying because most users do need it. We need to 1. allow the users to enable or disable it and 2. make it disabled by default.

One of our software engineers picks the ticket and implements a solution. Here’s what they do:

The feature X can be enabled or disabled;
The feature X is disabled by default;
An error message warns the user constantly that feature X is currently disabled and that they need to enable it to have it work. There’s a giant red banner to warn users that feature X is disabled—until the user has enabled the feature.

When I see that, I’m really confused. The code is great, and the ticket is indeed implemented, but the last part is terrible from a user experience perspective. It forces the user to enable feature X to get rid of the warning, meaning we get back to a point where users have to enable feature X by default, even if they don’t need it, just because they’re confused.

Bad product design.

That is great software engineering work but terrible product engineering work. In no case did the engineer put themself in the user's shoes or try to understand why we needed that change.

This is where a product engineer must shine. They need to understand the value and the reason behind the code they write, taking into account the product, its roadmap, its priorities, etc. It requires the ability to do trade-offs by being pragmatic. They need to be obsessed with the customer and understand their problem. In a startup, you need to ship fast, meaning, again, doing trade-offs and being efficient and practical. They need to be detail-oriented, have a sense of ownership, and be on the look to create terrific experiences.

Writing software has never been so easy. With AI on the rise, writing actual code will have less and less value.

The core value of building software is going to be whatever AI is not yet able to do, which is empathy—connecting with and learning from other human beings’ needs.

How to Transform Engineers in Product Gurus

Do not follow Indeed’s advice, for sure.

Based on the description I wrote above, we implemented some changes and made good progress overall. The improvements we made were due to simple changes we made to the organization.

Connect engineers with customers. Doing support directly with customers, joining a demo call, spending time in a booth during an event, and talking to prospects. All those activities where engineering can interact with prospects and customers are very valuable;
Explain the why, not the how. As a product owner, you must explain why changes are being made and not how they should be made. The more context you feed into your user stories, the easier for an engineer is to make the right decision when building a feature or fixing a problem. It’s especially important when, as a product manager, you have a technical background and you could be tempted to dictate a solution.

There are many software engineers out there, but not many product engineers. We’ll be on the lookout for that when hiring in the future. And if you want to join a product-oriented startup in the future, make sure you change your mindset to not just writing code. 😉

Staying Competitive

Tue, 10 Sep 2024 00:00:00 GMT

Starting a company is always a challenge. You start small, and you might have to fight competitors that are way larger than you. They could crush you.

However, being small does not mean that you will necessarily lose against large companies.

Last week, I was wandering through a forum where I regularly hang out with other SaaS founders. We share founders’ issues, anything from how to run ad campaigns to how to fire people (sigh).

That day, one of the participants asked a question about staying competitive when large companies enter your market. They were facing a few challenges, the main one being that a multi-billion corporation was adding features to its product that would poach on their turf.

That resonated with me. Mergify went through the same hassle when GitHub launched its own merge queue features last year.

Being in this position is extremely risky. There are many horror stories out there of startups being killed by larger competitors. You’d just have to watch the latest OpenAI DevDay announcements over the last few months to see how many startups they would instantly disrupt with the announcement of a single feature (marketplace, custom GPTs, etc.).

Is Apple going to kill a bunch of companies with iOS18?

Now, that being said, being the underdog is not necessarily a bad thing and can turn out to be a strength. When survival is at stake, the smallest dog can become the more fierce one.

80/20

In 1668, Jean de La Fontaine wrote a famous fable, Le Lièvre et la Tortue. If you never heard of it, the TL;DR is: a confident hare mocks a slow tortoise and challenges her to a race. The hare, overconfident, takes a nap mid-race while the tortoise steadily continues and wins. The fable teaches the lesson that persistence and diligence can triumph over arrogance and haste.

There are multiple choices to do in this situation, but my feeling is that most large companies will implement the “20% features that do 80% of the job.” It makes sense to them economically. With little effort, they can enter the market and grasp a large amount of the share using their moat, branding, marketing, and existing customers.

They can leverage their vast resources and existing ecosystems to quickly dominate this space. However, they often leave gaps in niche or specialized needs because building the remaining 80% of features to cover every specific use case requires more effort and may not align with their broader goals.

Unfortunately, if you were also targeting the same 20% feature, this can hurt your business. You’ll stop seeing new customers and will lose existing ones as they remove the one-too-many vendor from their list.

However, there is a chance for you to stay ahead of the game. Like the hare in the tale, large companies will just take a gigantic nap once they’re done with what they expect to be enough. This is where you can shine.

A small company that builds beyond the basic 20% and focuses on solving complex or specialized problems can appeal to customers who require more tailored solutions, thus capturing a large share of a more focused market. While large companies serve the general market, small players can dominate specialized verticals. By implementing, e.g., 40% of the features for a particular scope, you could address 97% of the market, thus appearing as an expert and leader in your area.

Vertical

Another play that I like is to target different verticals. If you design presentation software and suddenly PowerPoint enters the market, it’s going to be pretty hard to win over the long run. Microsoft will win because they’re known (the “nobody gets fired for buying IBM” rule), and they can reach out to millions of customers — you can’t.

However, if you pivot to becoming the presentation software specialized in building convincing, AI-generated, prospect-centered sales decks automatically, then you can win an entire part of the broader market.

For sure, the initial market might be narrower, but by being focused, it’ll be easier to win it. As you’re winning it, you can expand into adjacent markets and grab more share of the global offering.

Strategy

For both strategies — expanding beyond the 80/20 or addressing a particular, the key to discovering which approach might suit you better is to talk to your existing customers. They are the ones having the answer to the questions “Is there a usage pattern they rely on?” or “Are they working in the same industry?”. Focusing on customer experience or specializing in integrations that large corporations won’t do is only identifiable if you speak to your users.

Small companies have the agility and execution speed that large companies lack, making them the best innovators.

I guess that’s my message to anyone out there being attacked by large corporations. Don’t throw the towel too soon. There might be different plays for you to continue growing and fighting back against the Goliath.

In the end, it’s not just about size. It’s about understanding where you can uniquely provide value and delivering that value better and faster than anyone else.

Launching Byte Brigade

Tue, 20 Aug 2024 00:00:00 GMT

Today I'm excited to announce the launch of Byte Brigade, a community dedicated to investing in early-stage developer tools and SaaS companies. Our mission is to support tech startups at their initial stage of development, helping them become leaders in their respective fields

The Challenge

Many developers start companies to build incredible tools, but they face enormous challenges when it comes to marketing and productizing their innovations. This is particularly true in the French ecosystem, where we have brilliant engineers but often lack the cultural know-how to propel projects to their full potential. For example, marketing to developers is tough, and addressing the US market from France adds another layer of complexity.

I've seen this problem repeatedly in my career. For instance, I've recently shared insights with CodSpeed on the differences between European and US marketing strategies, helping them understand the specific challenges they might face. This is just one example of the kind of guidance that can make a significant difference for tech startups.

My Journey

Having worked in open source for over 25 years and in devtools and SaaS for close to 15 years with companies like Red Hat, Datadog, and Mergify, I understand these challenges intimately. Over the past few years, I've had the privilege of funding and mentoring several tech startups, helping them navigate the tricky landscape of market fit and growth.

This experience has inspired me to create Byte Brigade—a collective of tech enthusiasts who can bring their unique expertise to startups aiming to grow. We are building a group of business angels interested in investing in companies that could become tomorrow's tech leaders. Byte Brigade is unique in that we are very developer-centric, focusing on solving problems that matter most to developers.

Our Approach

Our approach is simple: we invest in and guide startups, helping them transform into dev tools and SaaS powerhouses. This involves significant efforts in marketing and product development, areas where we provide invaluable guidance. With advanced technology, experienced leadership, and a growing customer base, our portfolio companies are well-positioned for significant growth. Once they refine their strategies in their initial verticals, they can expand into new sectors, leveraging their technological capabilities and market insights.

Looking Ahead

In the long term, I envision Byte Brigade growing into a community where multiple developers and business angels come together to invest in tech startups that solve problems for developers. While we have no set timeline, we plan to host events, workshops, and networking opportunities for our members and portfolio companies, fostering a collaborative environment where ideas and experiences can be shared.

If you're a developer or a business angel interested in investing in companies that build solutions for developers, I invite you to join us. Your expertise and investment can help shape the future of tech innovation. On the other hand, if you're a tech company targeting developers and need funding and mentorship, we’re here to support you. Feel free to reach out to hello@bytebrigade.fund.

Call to Action

Launching Byte Brigade marks an exciting new chapter in my journey to support and empower developer tool startups. I'm eager to see what we can achieve together and look forward to helping many more companies grow and succeed. Join us in driving innovation and growth in the tech world.

Stay tuned for more updates, and let's build the future of developer tools together.

For more information or to get involved, please contact us at hello@bytebrigade.fund.

Solving Build vs Buy

Tue, 13 Aug 2024 00:00:00 GMT

Selling to developers is challenging, and the mindset of “build or buy” is one of the biggest hurdles. Over the past year at Mergify, we've encountered countless engineers grappling with this dilemma.

Developers are natural problem-solvers. When they encounter an issue, their first instinct is often to build a solution themselves. They see a problem, identify it, and immediately start imagining how they would solve it. However, there's a significant gap between having expertise in engineering and having expertise in a specific solution.

The Overconfidence Trap

Many developers fall into the trap of underestimating the complexity of the problems they're trying to solve. It's akin to asking an engineer, "How long to fix XYZ?" and hearing, "Should be done today," only for the task to stretch out over a week as unforeseen complications arise. They start working on the problem, only to discover layers of hidden challenges—refactoring needs, unexpected dependencies, and more. It all makes sense in hindsight, but it's nearly impossible to foresee these issues at the outset.

This overconfidence often leads to the creation of subpar solutions. While some teams might eventually succeed, these homegrown solutions fall short of their commercial counterparts more often than not. Moreover, solving problems outside of your core business usually results in a poor return on investment. Think about it: how many companies still manage their own email servers when GSuite offers a hassle-free solution for just $6 per user per month? Your IT team is incapable of competing with such an offer.

The typical customer for this comes to your demo call with a speech along those lines: “We’ve tried building a solution to this problem, but we failed because we hit too many bumps in the road; it seems you guys know how to solve it.” Teams that take this road are the easiest to win customers because they already know they can’t build.

The Build or Buy Mindset in Action

During our demo sessions at Mergify, we frequently encounter engineers who are initially skeptical about buying a solution. They come with a build-or-buy mindset, confident in their ability to solve the problem themselves. They're curious about why they should spend money on a product when they believe they can build it in-house. This is where it gets interesting.

One of the most enjoyable aspects of these sessions is debunking their assumptions. For instance, many engineers approach our merge queue system thinking, "This is just an automatic rebase, right?" After a 20-minute demo, they often leave with a new appreciation for the complexities involved. "Oh, okay. That sounds quite hard to do. Good job." This is where I reply with: “Well, this is why we’ve been working on this for 5 years already and have hundreds of customers.” 😉 Let me brag a bit.

By walking them through the numerous edge cases and intricacies that our product handles, we can show them just how challenging the problem really is.

The Power of Demonstrating Value

This experience highlights why startup founders who are engineers can be excellent salespeople. They understand the technical mindset and can effectively communicate the value of their products. The key is to convey the value of your product in your messaging and demos.

Having at least one feature that is both highly valuable and challenging to implement can make a significant impact. The more features like this you can demonstrate, the better—provided they solve real problems and aren't just complex for complexity's sake.

Final Thoughts

The "build or buy" dilemma is a significant barrier in marketing devtools. Developers' natural inclination to build solutions themselves can lead to underestimations of complexity and overconfidence. By demonstrating the intricate challenges your product solves and highlighting its value, you can shift their perspective. In the end, it's about showing that your solution is not just a convenience but a necessity for efficient and effective problem-solving. Once you've won them over, the next challenge is getting pricing right — which has its own set of hard lessons.

The Biggest Mistake We Made Building Mergify: Navigating the Hiring Minefield

Tue, 02 Jul 2024 00:00:00 GMT

This is part 2 of the "Biggest Mistakes" series. Read part 1: Navigating the Payment System Nightmare.

Building a successful startup is a journey filled with unexpected challenges, and hiring the right people is undoubtedly one of the most daunting tasks. As a tech engineer with no HR background, I’ve faced numerous hiring pitfalls that have taught me invaluable lessons. Reflecting on our journey at Mergify, it's clear that navigating the complexities of hiring has been one of the biggest challenges we've encountered. Here’s what we’ve learned.

Who to Hire: The Temptation of Cheap Labor

When you’re a startup with limited resources, it’s tempting to hire interns or apprentices, especially when they come at a low or even zero cost, thanks to government sponsorships. In France, this is an attractive option many startups pursue, and we were no different. Initially, we hired interns and apprentices, believing that this would provide us with much-needed help without straining our budget.

However, we quickly realized that while interns can be a valuable addition, they often lack the expertise we needed to tackle complex tasks. As founders, we required skilled assistance, not just extra hands for minor tasks. The overhead of breaking down projects into manageable tasks and guiding interns through them often resulted in a net loss of productivity. While we did encounter some exceptional interns who became valuable team members, the general rule is that relying on almost-free resources like interns is unlikely to provide the expertise needed in the early days of your startup.

How to Hire: The Challenge of Assessing Candidates

Hiring is more than just finding someone with the right skills; it’s about finding the right fit for your team and company culture. Despite the plethora of online resources on evaluating candidates, the reality of assessing someone over a Zoom call in just a few hours is incredibly challenging.

We've had both terrific and terrible hires, and in each case, we believed they were a perfect fit at the time.

After conducting hundreds of interviews and hiring more than a dozen people, we’ve learned one golden rule: if you have any doubts about a candidate, don’t hire them. It’s better to wait for the right person than to rush and hire someone who might not fit well with your team.

Finding Candidates: The Perils of Recruitment

The search for talent is a constant struggle. In France, we experimented with various solutions, from Welcome to the Jungle (a nightmare) to talent.io (effective). We also engaged a few headhunting firms, which unfortunately turned out to be a costly mistake. These firms often sent us unsuitable candidates and still kept their fees. The legal obligations in France favor the headhunters, not the employers, making it a risky and expensive endeavor.

For example, we had a candidate that we hired and then paid the fees to the headhunting firm. The employee would stop their trial period and leave. That meant the headhunting firm should send new candidates our way to replace the one that left during the trial period. However, there was no incentive for them to do so as they’d been paid already. Therefore, they didn’t care. We found our candidate in a different manner, meaning the fee was then lost for us. Considering that fees can be 10–20% of the employee's yearly salary, that’s a large amount of money to throw out the window.

Networking and recommendations remain some of the best ways to find talent, but they don’t scale well and often have timing issues; you’d find the right candidate, but they’re not available, or a friend would knock at the door, and you’d not have any budget to hire them.

Additionally, we realized that marketing our company effectively during hiring talks is crucial. Initially, our pitch didn’t resonate, and most candidates would ignore us. By improving our presentation and emphasizing our company culture and values, we started attracting genuinely interested candidates.

After years, we discovered that you want to polarize your candidate early in the process and during their employment to ensure they get 100 % onboard with your venture. Depending on your founder profile, that might be something you do naturally. As tech founders, we were not particularly good at that, but we learned our way through.

The Remote Work Dilemma

Building a remote team has advantages, like accessing a broader talent pool, but it also comes with significant challenges. At Mergify, we embraced remote work and wrote extensively about our experience. Remote work works well with senior staff, but junior employees often struggle without in-person guidance. Sharing the company vision and brainstorming ideas are also more effective in person, which is why we regularly organize in-person meetings.

Regular team-building events, video calls, and asynchronous communication help bridge the gap, but they can’t completely replace the spontaneous interactions that foster innovation. Remote work is great for finding talent, but in-person connections remain essential for a cohesive and innovative team environment.

I would not consider remote work a mistake, but we underestimated its impact on the company.

Lessons Learned and Rules Established

From our hiring mistakes, we’ve developed a few key rules:

Avoid hiring remote junior staff if you are working remotely. They need more guidance and in-person interaction.
Leverage in-person connections for innovation. Remote work makes this challenging, especially for junior staff.
Share a lot of context to drive innovation and execution. Overcommunicate.
Be cautious of headhunters and their fees. Consider delaying payment until the trial period ends.
Avoid working with multiple headhunting firms to avoid finding your candidate with one when you have already paid the other.
Learn to pitch your company effectively. Highlight your values and culture to attract the right candidates.
If you have any doubts about a candidate, don’t hire them.
Don’t hire interns and trainees until you have enough senior staff to mentor them. Consider them a small cost, not a huge win.

Navigating the hiring process is complex and fraught with potential pitfalls, but by learning from our mistakes and establishing clear rules, we've been able to build a stronger, more effective team.

If you’re building a startup, remember that the right hires can make all the difference, and taking the time to find them is well worth the effort.

The Biggest Mistake We Made Building Mergify: Navigating the Payment System Nightmare

Tue, 11 Jun 2024 00:00:00 GMT

In 2018, we embarked on an exciting journey with Mergify, our brainchild aimed at simplifying GitHub pull request workflows. One of the first crucial decisions we faced was choosing a payment processor. Stripe, with its developer-centric approach, seemed like the perfect fit. Within a few days, I had mastered the Stripe API and built the foundational billing system for Mergify. For a while, everything ran smoothly as we scaled our user base. However, we soon encountered a significant roadblock: handling VAT in Europe.

European VAT is notoriously complex, with countless edge cases that can quickly become a nightmare for any business. Invoicing internationally from France presented additional challenges, leading us to the conclusion that outsourcing our invoicing would be the best course of action.

The GitHub Marketplace Misstep

In 2019, the GitHub Marketplace appeared to be an attractive solution. It promised to streamline invoicing while exposing Mergify to a broader audience. Although GitHub took a 15% cut (later reduced to 5%), we were not focused on optimizing margins at that stage.

GitHub Marketplace

However, this decision turned out to be a colossal mistake.

Issues with payments began to surface almost immediately. Problems with GitHub’s payment system meant we often had to ask customers to contact GitHub support, creating a frustrating experience for them. Our inability to manage payments directly, such as retrying failed transactions, was a significant drawback. It became evident that while the GitHub Marketplace was a great tool for acquiring new customers, it was far from ideal for handling payments.

As a glaring example, if a GitHub customer switched from credit card billing to invoice, they would lose access to all marketplace apps, including Mergify. This could abruptly cut off our service, leading to dissatisfied customers and lost revenue. By 2020, we decided to completely transition away from the GitHub Marketplace for payments, migrating our customers back to Stripe. This move eliminated the invoicing problems caused by GitHub and allowed us to regain control over our billing process.

The Paddle Predicament

Despite our move back to Stripe, the VAT issue remained unresolved. In our quest for a better solution, we discovered Paddle, a platform that promised to handle VAT by becoming the merchant of record for our transactions. We quickly integrated Paddle into our system, hopeful it would be the solution we needed. Unfortunately, this decision soon proved to be another costly mistake.

Paddle

Paddle's API was far less sophisticated than Stripe’s, and we found ourselves grappling with numerous limitations and workarounds to integrate our billing system. The added complexity and subpar user experience led us to conclude that Paddle was not the right fit for Mergify.

The Turning Point: Handling VAT Ourselves

Realizing that there was no perfect third-party solution, we decided to tackle the VAT problem head-on. In 2020, we took the plunge and developed our own VAT handling system using Stripe and Python. We detailed this process in a blog post sharing our approach and challenges.

Fortunately, Stripe was also working on solving the VAT issue. By the end of 2021, they released their comprehensive tax product, simplifying VAT and other tax processes. This allowed us to finally switch fully to Stripe, discarding our custom code in favor of their robust solution.

Lessons Learned

The most significant lesson from our journey is that payment processing is not a mere detail—it’s an integral part of the user experience. Even now, I spend several hours each month resolving payment issues, from credit card problems to ensuring invoices are correctly fed into various supplier systems. While automation can handle many aspects, the unique methods and systems of each customer often require personalized solutions.

Our experience underscores the importance of keeping things simple on your side and minimizing friction for your customers. Ensuring a smooth and reliable payment process is crucial for maintaining customer satisfaction and loyalty.

In hindsight, we should have approached the payment system with the same rigor and attention to detail as the rest of our product.

It's a lesson we learned the hard way, but one that has ultimately strengthened Mergify and our commitment to providing the best possible service for our users.

This is part 1 of the "Biggest Mistakes" series. Read part 2: Navigating the Hiring Minefield.