A bootstrapper's story with Julien Danjou, founder of Mergify
For the first year, Julien Danjou and his co-founder had two hours a week to spend on Mergify, on top of full-time jobs. His advice for every technical founder since: split your time exactly 50/50 between building and marketing, and be strict about it.
Julien Danjou is the co-founder of Mergify, a GitHub app that automates pull-request workflows with a merge queue, built and bootstrapped alongside his co-founder Mehdi while both held full-time jobs. He'd already self-published books on Python programming before Mergify, which is where he says he first learned marketing as a skill in its own right.
We get into what it actually took to get engineers to trust a tool they could technically have built themselves in a weekend, why having almost no time forced better decisions than having more money would have, and why open source ended up being their most durable growth channel — not as a product decision, but as a way of directly saving other open-source maintainers the time Mergify's own founders never had either.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What made bootstrapping a dev tool specifically hard, versus bootstrapping something else?
When you build a tool to solve your own problem, like any engineer would, that's exactly what makes it hard to sell to other engineers — they look at it and think, that's cool, but I could build that in a week, so why would I pay for it every month. Early on, your product has to pass that bar: it has to be sophisticated enough that trying it and deploying it is genuinely faster than someone building their own version to fit their exact need. Until maybe a year ago, I'd still get on calls where someone would say that's cool, but I don't see the point, and I'd spend the next 30 minutes doing a live demo, showing what happens on the failure paths, proving it engineer to engineer. There's a lot of unglamorous work — edge cases, failure scenarios — that goes into proving the value once you get past the 'I could build this myself' reaction.
How did Mergify actually start?
Mehdi and I both had full-time jobs and met working on an open-source project. We migrated that project from a different platform to GitHub and felt naked without the tooling we'd had before, so we built our own automation using the GitHub API and a merge queue — which is still what Mergify does today. Colleagues on the project got interested, so we gave them access, and after a few months enough teams were talking about it being useful that we thought, let's connect Stripe and see if anyone will actually pay. We found our first real paying customer on a Hacker News-adjacent community, and then found pitch.com, which is still a customer today.
What did the very first version actually look like?
Mehdi did most of the grunt work on the first MVP, and it wasn't much — there's no line of code left from it today, it was a Python script with a lot of race conditions and edge cases left unhandled, just a proof that the idea was doable. That took about a month. Since we're both backend engineers who barely know CSS, the hack we used was reporting everything back to GitHub in markdown, so we never had to build a dashboard or write any frontend code at all — everything lived on top of GitHub itself. It took about six months of part-time work, not six months full time, to get to something people were actually willing to pay for.
How did having almost no time and no money change how you made decisions?
When you're bootstrapped with a job on the side, you might have two hours a week, so you can only do one thing, and it has to be the thing most likely to keep the company alive for the next week — everything else just doesn't get done, because you don't have the choice. I tell people internally at Mergify now, when they feel overwhelmed with too much to do, that we started with two hours a week between us. Working 12 hours a day doesn't actually work in the long run anyway. I think one downside of having a lot of money is you can throw it at any problem and see if it sticks — when you're resource-constrained, you're forced to be extremely focused and make the right call, because you have to, not because you're disciplined.
How did you avoid the common trap of engineers building features nobody asked for?
The trap we didn't fall into is the classic one: you're both engineers, you build things you personally like, people don't come, so you assume it's because you're missing a feature a competitor has — but the actual root problem is usually that nobody knows you exist, because you're not doing marketing. What we did instead, especially more recently, is talk to customers before building: ask an existing customer what feature they want next, since they're the one giving us money, and sometimes propose an idea back to them to see if it lands. We've also started pitching things we haven't built yet — a landing page with a real card form, where people are told we don't charge them, but if they're willing to enter a card for a trial of something that doesn't exist yet, that's validation to go build it.
Which marketing channels actually worked for you, and which didn't?
We tried almost everything and kept what stuck. Paid ads never worked for us, mostly because we simply don't have the budget as a small bootstrapped company. SEO works well for us — we get a lot of traffic and we're easy to find on search engines. Conferences are something we're experimenting with now; it's new enough that I don't have a verdict yet. Word of mouth, backed by case studies that validate you're legitimate, works, but slowly. By far the best channel for us has been open source — we provide Mergify free to open-source projects on GitHub, and that's brought in a lot of our best customers indirectly.
What does "open source as a growth channel" actually mean in practice for you?
Open-source projects are like your own bootstrapped project — they don't have time or money either. In our case, we're not giving them money, we're giving them time: if you want to merge pull requests properly, you have to make sure they're up to date with the base branch, ask contributors to rebase, wait for CI, and do it all again for the next one. It's boring, manual git operations with no real value in doing it by hand, and if you're only spending a few hours a week on a side project, saving that time is worth a lot. We now have a few hundred, maybe close to a thousand, open-source projects using Mergify for free, ranging from one or two maintainers to projects with 50 to 100 contributors, including teams at places like AWS and Red Hat.
How does that translate into actual paying customers?
Mostly word of mouth carried by engineers moving between companies or projects — someone browses GitHub, sees a PR merged by Mergify on another repo, and looks it up, or a colleague from a previous company or open-source project mentions it. One of our biggest customers came from an engineer who was already using Mergify on their own open-source project on GitHub and asked their manager if they could bring it into the company — they called us, and it was as simple as subscribing. Being at Red Hat when we started gave us a big network of open-source engineers, which helped validate the idea early and spread it to projects like Ceph, which has used Mergify for a long time. Open source doesn't put money directly on the table, but it's a real lever — it's how you end up inside the company that eventually pays you.
What's your one takeaway for a technical dev tools founder?
If you're a developer building a dev tool, which is most likely the case, don't skip the other half of the job. Mehdi and I split it explicitly early on — he'd be CTO and do the technical work, and I would do everything else. That's been true for about three years now; I don't write code anymore, and I review less and less of it. My advice is to be strict about a 50/50 split even if you're a solo founder: half your time on the fun part, building the product, and half on marketing, sales, whatever actually brings people to it — because that's usually the part you don't want to do, but it's the most critical thing to learn if you don't already know it.