Growing an open-source side hustle to $2M ARR

Seven years ago, Joel Griffith's side hustle was the first of its kind — an open-source product for executing headless work. He called it Browserless and grew it on the side until it replaced his full-time income three years later.

Now, it's making $2M ARR. Here's Joel on how he did it. 👇

A veteran indie hacker

I'm a “veteran” indie hacker who has been working on Browserless.io for about seven years now. Wow.

I started Browserless in the early days of Indie Hackers, and hopefully some readers here will remember those days. Just in case you weren’t here: Browserless was started to help with the headaches of hosting and running a headless browser.

When we first started, there was nothing that allowed you to run puppeteer, playwright, or other libraries in a hosted fashion, so we were ahead of the market quite a bit. A lot has changed since then, but we’re still here and working in that same space.

Finding the pivot

I was working on a simple React app to help with the problem of tracking friends' and families' wish lists for holidays and birthdays.

A part of this product was pasting URLs of things you’d like or want, and this app would track them in a simple interface. As you can imagine, I hit some pretty heavy JavaScript sites (SPAs) and needed a headless browser to render them.

At the time, Puppeteer had just come out and was all the news, so I decided to pivot into building a product that supported these new libraries that ran over WebSocket, versus older protocols like Selenium or Webdriver. I called it Browserless.

No room for ramen profitability

At the time, I was working as a full-time engineer. I had two young kids and all the other “adult” stuff, like a mortgage. The bar was fairly high. “Ramen profitability" wasn't really an option; if I wanted to make Browserless my full-time job, it had to match my full-time income.

So I did what any sane person would: I worked two jobs — my day job and Browserless.

You see, there’s no way to go from zero to one without some kind of subsidization. You either take “capital” in dollars (loans or venture), capital in terms of quality of life (cutting back your expenditures), or capital in terms of time. These are kind of like a “Law of Conservation of Energy in Business.”

So, my first signup was exciting. But my motivation wasn't fully piqued until I replaced my income with Browserless. That took roughly three years.

Basic but custom

The initial product was quite basic, but custom, given the fundamental nature of how the product works in a technical sense.

I utilized Docker to package all the relative aspects into services, and then had those services “point at each other” to run. Kubernetes was just getting started, so I didn’t utilize it due to the time required to learn it. Today we use terraform to orchestrate all that.

But at its core, we had an open source container image representing the underlying product (it’s still open source and you can see it here). We had an API server, a React front end on Netlify, a simple database, and custom load-balancers written to handle all the odd libraries and networking protocols.

That’s it! You don’t need to use the latest and greatest for this project, though I’ll admit I have shoehorned in new tech as a way to bolster my own growth and deliver products quickly.

Our first month's bill for infrastructure was like $50. Now it’s up in the five figures and growing, but we continuously check that against revenue to make sure we operate in the black and never owe anyone.

Use a familiar stack

It’s okay to throw some time into learning new technologies when building something new, but my rough rule is that you should know 90% of the technologies you use. Especially when you’ve funded yourself via time-capital – which does imply somewhat of a runway. At the end of the day you're building products, not exploring new hobbies.

Time to market needs to be as near to zero as you can get it, so going with stuff you're familiar with and vetted in is important.

Don’t let new tech persuade you from shipping something now. APIs are eternal; implementations are just a detail.

Volume-based businesses

Our business is fairly traditional in that we sell a product, hosted or cloud, that we charge for based upon volume.

Volume-based businesses are tricky to get right sometimes, so it takes a few iterations. We essentially just charge for the amount of time, plus whatever add-ons you use.

Regarding revenue growth, we think about it in two ways, as most businesses do: new user growth and expansion, with the former driving the latter. Once folks use our service and get value, then they’ll likely just need more of it as time goes on. It’s fairly straightforward.

Growth

Content

We’ve found that content, especially “show don't tell” content, is the best way to drive business.

Even if the reader doesn't end up using the service, there’s still a chance they recommend you to their friends or managers who can buy.

Ads

Ads can sometimes work if you know what you’re building and are building against an incumbent. Marketers love this since there’s a successful blueprint out there already on how to grow the company.

I wouldn’t necessarily pay for ads until a few years in, when you’re confident that there’s something there to build a business on. The upfront cost is just too high to capture any value from it.

Open source

Open source can work if you do it properly and in the right direction. You have to understand how licensing works, what licenses to go with, and what not to do — for example, never go from permissive to less permissive, as it’s a downgrade.

I like planning on being too limited first then gradually opening up more and more later. It’s partially an optics strategy, but it also allows you not to lose anything IP-wise early on. Read up on Elastic with regards to this!

Overall I think content is the most important. I like it due to the fact that it breaks up my incredibly code-driven workday anyways, so it’s a welcome change of pace.

Affiliate

The other avenue we’re looking into a bit more is affiliate marketing. This model helps you turn your fans into potential funnel as they get some of the rewards for forwarding new business your way. It’s a great way to grow a business, as there’s good alignment in outcomes.

Decrease time to market

Get your time to market to as near zero as possible. Delay everything that doesn’t necessarily drive this number down.

Refactors? I love them but you need $$$ to stay alive in order to refactor. Moving to a new framework? Not until someone can pay you to do it!

I reject the mentality that everything must be perfect and supported in order to ship. Engineers, especially, can get into these loops of solving the edge-case issues that few, if any, will ever see. Is it a bug if no one experiences it?

Just get the damn thing out the door and see if you get any sign-ups. Quite literally: Nothing else matters until the idea is tested.

Parting advice

Know what you’re good and not good at. Hire smart(er) people for these roles and let them go hog wild.

Take your time hiring and trust those whom you hire. If #1 is important, this is especially important. Hiring to “polyfill” your own lack of support means you have to trust that the “polyfill” is right!

Track, analyze, adjust. Get analytics in your product early, analyze it with your team daily, define success and adjust quickly. Analytics should be a day-one endeavor.

Establish a “northstar”. This took me way too long to get adopted into our culture, and it’s still something we’re chasing down a bit. Of course many IHers will say “revenue,” and that’s fine because you have to get that before anything else matters. But once you’re on stable ground, then figure out what metrics you want to focus on. For instance this can be “time to first API call” or “seconds of time spent” etc. 

Be patient. Expect the first few years to be slow unless you have a marketing or growth person in your corner. There’s lots to learn here, especially if you’re working full-time on the side, so progress will come very incrementally.

What's next?

I want to make Browserless do what others can’t. We have a unique position in how we operate and run headless browsers, where we have the opportunity to make things like reconnections, keep-alives, etc.happen from a systems standpoint.

Similarly there’s a lot of stuff CDP (Chrome’s DevTools Protocol) can do that a lot of folks don’t know about. We’ve actually just released our first in-house library and protocol called BrowserQL so that folks can take advantage of them much more rapidly.

There are even cool things like intelligent proxy routing, request and response APIs, plus more to “make it go fast.” Getting this out into more hands is definitely a priority for us this year.

You can follow along on X and Github, and check out Browserless.