On Launching a Side Project (Or: When The Platform Makes Your Idea a Feature)

This is the final post in a series of my journey to launch a side project in 2020. You can find the previous posts here and here.

After working to launch MergeCaravan, I finally felt like the product was ready to be released. I had a few things left to do before doing any promotion.

First, I needed a way to actually charge customers. Stripe’s Checkout product made this super easy and with just a little work I was able to set up support for monthly subscriptions. By leveraging Stripe, I could ignore all sorts of concerns, such as providing a way for customers to cancel. Checkout handles basic billing management so I wouldn’t have to.

Next, I needed to set up Google Analytics to understand traffic and if the product was resonating with potential users. I used a great product called Freshpaint to do this. If you’ve ever used Segment, it’s quite similar. The big difference with Freshpaint is its ‘autotrack’ capability. Basically, it automatically tracks ALL page views, clicks, and input changes. This allows you to retroactively decide which actions might be interesting and then query them later.

With the proper tools in place, I started posting about MergeCaravan in a couple different places. I don’t have a large LinkedIn or Twitter following but felt that posting in those places first would be a good start. If I could just resonate with any developers I know, or their colleagues, that would be a great start. After that, I put together a post for Product Hunt. I tried to add a little bit of color around the frustrations that drove me to build MergeCaravan and added some more information on the upcoming roadmap.

And after all that….

*Crickets*

Although I did get some early web traffic after posting in various places, none of the visitors were converting. Not only were they not becoming paying customers, they weren’t even connecting their GitHub accounts at all.

Hmm. I looked at my homepage and made some visual tweaks, hoping that maybe I could make the product appear a bit more professional. I also went and corrected a bug that only allowed users to connect MergeCaravan to a GitHub Organization and made it possible to also connect MergeCaravan to a personal GitHub account.

And then… a wild customer appeared!

Someone made it all the way through my sign-up process and entered their credit card details. I had 14 days to convince this user that what MergeCaravan provided was worth $10 a month.

To do this, I started by tackling some work around reliability. MergeCaravan needed to consistently do its job and it needed to ‘just work’. I moved some synchronous GitHub calls to a job queue and added some automatic retries. Next, I focused on implementing a feature which dealt with a pain I felt: working hours. I wanted to make sure that MergeCaravan only merged PRs during an acceptable window. The last thing I wanted was for a PR to somehow get merged at 4AM.

Eventually, that user’s 2 week free trial ended and… they converted to a paying customer! 😄

I was feeling good about the direction of the product and the opportunity in front of me.

And then a possibly predictable, yet demoralizing thing happened: Github unveiled ‘Auto merging’ of PRs.

GitHub’s Universe

GitHub’s annual Universe conference happened in December and one of the features they unveiled was the ‘Auto merging’ of PRs.

*sigh*

It was a bit discouraging. While MergeCaravan isn’t identical to what was launched, the provided feature probably satisfies users’ needs enough that they wouldn’t need MergeCaravan.

GitHub’s Auto Merging is an 80% solution. It probably satisfies what most people need. It doesn’t do anything flashy, like preventing merging outside working hours, but it’s integrated in the the Pull Request workflow and makes dealing with PRs a better experience.

This isn’t the first time GitHub has launched an 80% solution. I had a very similar feeling when GitHub launched GitHub Actions. I think that for 80% of cases, GitHub Actions is easier to set up and has the advantages of being more tightly integrated. It’s what makes me generally bearish on CircleCI as a business in the long term. There’s still 20% of cases for which CircleCI will provide a better experience, especially for specialized requirements that Actions won’t support. But that’s a much smaller market compared to all users who need continuous integration.

The Platform Problem

I’ve wondered for a while how a platform like GitHub, which has its own marketplace, balances what it builds against what its partners do. For example, when GitHub launched Actions they were beginning to compete directly with other CI platforms like CircleCI and TravisCI, both of whom have been long time partners.

How do you balance that as a platform? What’s the calculus in their heads? Since I’m not even on the GitHub marketplace, I’m sure MergeCaravan isn’t on anyone’s radar there at all. So it certainly wasn’t a question they were asking themselves as they built this feature.

More broadly, as a maker, how do you properly assess the risk of building a business on a platform, knowing that one day the platform may try to compete with you and probably do a better job?

What Did I Learn

Beware the platform

The biggest takeaway from this experience: really assess the risk of building on a platform and understand how that can cripple your business. This story has played out many times before on many platforms and GitHub is no exception. In some cases, they’ve competed directly with platform partners (e.g., CircleCI) and in other cases they’ve gone and acquired their partners (e.g., Dependabot and Pull Pandas). There’s always a risk that a platform might try to make your product a core part of the platform.

To be clear, GitHub maintains a public roadmap so this wasn’t a complete surprise to me. But it was still disheartening. I knew that for most users, this solution was good enough.

I took too long and was embarrassed

It’s cliche, especially as an engineer, that I would spend too much time working on perfecting building or cleaning up code and not launch soon enough. I knew this going into it. And I still took too long. In grand total, I made my first commit on May 1st and I didn’t feel comfortable launching until August 31st. That’s 4 months, for a small product. Yet, I kept telling myself things that seemed like they could justify delaying. “This doesn’t handle manual merges.” “This doesn’t support Github’s Organization model.”

My design skills aren’t the best, so I thought I needed to make some changes and make my homepage prettier.

The page initially didn’t update automatically, so it had to be manually refreshed for updates. (Oh the horror! 👻)

There were also things that I took my time with, since I believed they were critical. For example, extensively testing the code that determined what branches to merge and when. I felt that getting this wrong could be catastrophic for a user, so doing it right wasn’t negotiable for an MVP.

Getting that first paying customer feels incredible

I don’t know if there’s a good set of words to describe how wonderful it is to build something and to have someone want to pay you for it. Even at $10 a month, just knowing that you’ve provided someone a bit of value is incredible.

I cannot recommend enough getting a customer to pay you for a product you’ve built. Seriously, it’s a hell of a drug.

Onward

I’m glad I launched a product that I built entirely from scratch, even if only with minimal success. Next time, I’ll know to ship sooner and devote more efforts to promotion. (And maybe I’ll think twice before building on a platform that can cannibalize my product.)

2020 was a unique and challenging year. And yet I managed to build, launch, and get customers for my product. Just ship it. That’s what I kept telling myself. I waited, and took too long, and dragged my feet to launch and promote, but eventually I did it. I got there. And I take a lot of solace in that fact.