68
29 Comments

How I've Grown My Headless Browser Business to $1,000/mo
IH+ Subscribers Only

Hello! What's your background, and what are you working on?

Hey friends! I'm Joel Griffith, founder of browserless. I'm a full-time software engineer, married father of two, failed jazz trumpet player, and a soloprenuer on probably my sixth project. I'd go so far as to say that I'm a serial failure, as the prior five or so projects I've attempted generated poor or no revenue, which I think is important for folks to hear since this is sometimes like winning the lottery.

browserless is simply a headleass-browser service, full stop. You've probably heard about headless Chrome if you frequent Hacker News — if not, it's a way to run a web browser without any sort of graphical interface. This has quite a number of usages including web scraping, testing websites, generating screenshots, and printing PDFs. browserless makes it trivial to do all of these things without spending a lot of time on getting Chrome set up properly. If you search around popular headless libraries you'll no doubt see all the issues people face when trying to do just that.

Since I launched roughly three months ago, it's been steadily growing, and as of right now I'm seeing about $800 a month of recurring revenue from about 15 paying customers.

browserless homepage

What motivated you to get started with Browserless?

It might come as a shock, but I actually never set out to build browserless. I was originally working on a wishlist app where users could just paste in links to different things they wanted from online and then share them with their friends and family. I had a Node program that would load the user-submitted sites and scrape all the appropriate details — pretty simple. Then I tested this with a big name-brand site which immediately failed because they were running what's called a single-page app that had no content whatsoever in their intial HTML. This was a pretty big showstopper, and required me to run a web browser to load their page in order to scrape content.

At about the same time Chrome released a headless mode, which I then wrote an open-source library for in order to use on my wishlist project. This library, called navalia, got some good traction on GitHub and eventually caught the eyes of chromeless and then puppeteer.

As I became active on those projects I noticed a trend of developers having frustrating experiences trying to get them to work in production environments. It wasn't easy or quick to get headless Chrome running on Heroku or AWS, and when you were successful, things like fonts didn't look good or work at all. I began searching for any sort of headless-browser provider that I could both personally use and recommend to these users — but none existed.

All of these different events culminated when I was talking with Matthew Mueller, founder of StandUp Jack, when he just flat out said, "Why don't you just make a headless service that does this?" This was the "aha" moment that propelled me into breaking ground.

What went into building the initial product?

Since I had a pretty good understanding of what was going on under the hood with these projects, I knew exactly what to build, and I wanted to be finished in a few months or so, since I didn't take any sort of funding.

I also didn't want to pay for any outside help as I had literally $0 for this effort. This type of mindset resonantes with me well because it forces me to move quickly and not churn on trivial things like framework choices and tech stack. I remember constantly saying to myself, "It doesn't have to be perfect — it just has to work." I think this is really important for engineers, since we all seem to be indoctrinated with "crafting only beautiful, elegant code." No way, man. If it works, is secure, and generates revenue, then that's all that really matters.

From that I decided to not try and learn anything new technology-wise for this project. I used tools that I could move as fast as possible with, which for me meant JavaScript all-the-way-down since I'm primarily a front-end dev. Scaling and account management were the only things that really remained, and thankfully there are some great resources for those.

I used Stripe for payment processing, DigitalOcean for all the hardware needs, GitHub for version-control, and Docker for hosting images and doing builds. The biggest unknowns for me were payments and hardware. Stripe made the payment processing dead-simple, especially with their test environments and subscriptions. DigitalOcean also became a big component as it allowed me to manage new instances every time someone signs up or cancels, which meant I wouldn't be left holding the bag for unused hardware.

However, the biggest struggle by far for me was time. I have a wife, two young kids, and a full-time job as a software engineer; so time was extremely scarce. For this you have to be incredibly scrappy and leverage everything you can: working after everyone's asleep, coding when you're on a flight, and organizing on your phone when you can't actually program. Even when I was commuting to work I'd listen to Indie Hackers interviews and try and absorb as much as possible when I couldn't actually program. I think I'm on my third listen through all the prior episodes, and I'm still picking stuff up.

I can recall several instances where I woke up on my laptop after having fallen asleep from working on browserless. This obviously isn't sustainable, but sometimes you have push with everything you've got.

browserless pricing

How have you attracted users and grown Browserless?

The first batch of initial users were developers I had worked with on puppeteer, chromeless, and navalia. Having the first few customers already lined up helped me validate that the idea was sound and motivated me to launch. Once I launched I posted on most of the usual culprits: Hacker News, reddit, and on a few GitHub issues. I immediately found out that because the audience for this service was small, larger sites just didn't seem to care much. I made no front pages and didn't get featured anywhere. What did work was answering people's questions on StackOverflow and Github — even if it didn't mean a conversion right away, it started creating some backlinks into the site, which at least helps with SEO.

After about a few weeks I started seeing more and more users from those libraries I mentioned buying subscriptions. As a matter of fact the first customer bought the most expensive plan I had, so that kept me motivated to ship. The following days after I started getting inquiries from CTOs and developers, some of which bought a subscription right away, others I just answered questions for. I tried doing ads for a time, which did result in more traffic but was expensive compared to the value being generated. Since then, I've done almost no advertising whatsoever.

Once I had some "wind in my sails" with a few customers, I started to write more frequently about how to do certain tasks with headless Chrome on Medium. Occassionaly I'd showcase how browserless makes it easier to do these tasks, which resulted in a few more conversions and inquiries. I don't think this process is necessarily scalable in the long term, however my feeling is that word-of-mouth will spread a bit and headless Chrome will begin to gain more traction over older technologies.

There are a few featuers coming up that I think will help new users get started a lot more quickly and have better developer ergonomics, which I believe will help spread the word. The benefit of this type of business is that there's almost no competition out there, so I haven't seen a lot churn in users. However, the downside is that browserless isn't something you'll generally know of or need until you find the problem it solves. Because of this, I'm really trying to focus on a highly polished product and documentation so that it continues to stand out.

One thing I'd like to stress to others is that if the niche for your product is small, don't expect to get a lot of big attention, at least initially. Even now browserless only sees roughly 50 users a day, which is nothing, quite frankly. I think what's important is that it solves a problem these people are facing, so those 50 users are already far into the conversion funnel. Because of this, you don't need 100k users a day to make your product successful (though it does help), you just need to know the problem well and where to find the frustrated users.

Month Customers
November 2017 6
December 2017 13
January 2018 20

What's your business model, and how have you grown your revenue?

I pretty much stole the model used by projects like Ghost and Sidekiq when it comes to monetization. Essentially, browserless makes money in one of two ways:

  1. Selling a corporate licenses so users can use their own infrastructure.
  2. Selling hosted plans in various tiers.

Hosted plans account for the majority of my income from browserless. My hypothesis is that most developers don't really want to spend large amounts of time pulling images and getting infrastructure ready for this type of work. They've run into a problem and just need something that works quickly, as it's not their core business or a problem they're solving. With hosted plans it takes around five minutes to get everything running, which is entirely automated, and then they're good to go.

Hosted plans obviously have a smaller margin, since browserless needs to lease infrastructure. Whenever a new user signs up I use the DigitalOcean API to launch a droplet and provision it with all the software required. This ensures there's enough scale to meet demand, and it helps me better predict costs and long-term profit. Because of this strategy I probably over-lease hardware, since not every user will utilize 100% of their account, but it ensures that there's availability and helps keep sessions isolated, which is always a concern.

Initially I struggled with charging users, as I'm sure many people here can understand. Because of this inhibition I ran a closed beta that ran for nearly three months… when I only intended it to be for one. I wish I had started charging sooner, and I can recall one user even mentioning to "Let me know so I can pay you for your awesome service." Engineers, myself being guilty as well, seem to focus so much time and effort on solving the problem that they forget all the other things about running a business — namely making money. It's one of those lessons I think most people have to learn, even though they've been told many times. I definitely had to learn the hard way.

Month Revenue
November 2017 340
December 2017 650
January 2018 1000

What are your goals for the future?

The best and worst thing about browserless is how new and unknown it is. Since this is likely the first headless-browser service, there's no outline of what to do. Because of that there's a good deal of education that goes into how the service works, and initially I didn't expect that to be a hiccup, so I'm hoping things like the new serverless workflow will help to alleviate that.

I also want to continue growing the service to larger consumers that use headless browsers for their infrastructure. I can't count how many hours I've spent in my day job trying to debug or fix headless workflows, which is something that costs companies a lot more money than any of the browserless plans.

Forecasting growth month-over-month, it'd be nice to get to 100 paid users by the end of the year. I'm doubling down on my documentation and blog/content-marketing to help achieve this plus more cold emails to companies I know could benefit from the software.

I think the final thing is that allowing 3rd-party integration from different platforms would be fantastic, and is something that serverless would help with. Zapier and even IFTT will easily be able to integrate once browserless is more externally accessible, which I feel will open up the doors to more users.

browserless docs

What are the biggest challenges you've faced and obstacles you've overcome?

Pretty much what everyone else has said here: "Charge your users." It was quite difficult to keep pushing on nights and weekends when money wasn't coming in, though it could've been if I'd done things properly. There's no better feeling than seeing that first deposit hit your bank, which is the biggest form of validation I think there is.

The biggest challenge I think I'm facing now is finding users. I know the problem is there, and I know folks are looking for answers, but it's a matter of education and getting the message just right. I'm trying to make some lemonade with this lemon by documenting best practices and common gotchas. Creating a community around browserless will likely be crucial to its success, and is something I'm trying to find an outlet for.

Have you found anything particularly helpful or advantageous?

If you're reading this: you've already found a helpful resource! The advice from folks on Indie Hackers has been priceless, and I can't imagine the amount of time I've saved because of it. There's also a wealth of great technology out there that can springboard your efforts quite quickly. I'd definitely recommend using Stripe, DigitalOcean, Docker, Github, and Netlify to help you achieve your projects goal. They're dirt cheap for paid plans and worth every penny for what you get.

I also feel that there's definitely an element of chance in getting something that generates income. I just happened to have a need for a library, wrote one, found users, and had the foresight to make it a business. This doesn't happen often, so if you see something out there that's trending and that you're good at, jump on it while you can.

What's your advice for indie hackers who are just starting out?

Sort your favorite open-source projects' issues by comments or reactions, and see what's missing that you could build and monetize. As an example, what if the Ghost blogging platform was just an open-source blog? You could have easily created a hosted version and started monetizing it yourself, and those guys are killing it. I'm sure there's a ton of other databases, frameworks, and other cool things that could be made into proper hosted services — it's just that no one is doing it.

The other piece of advice I can give — and it's been been given numerous times here — is to just go and do it. Build something that you wish existed but does not, and build it well. Not only will you have passion, but you'll also walk in knowing what exactly to build. For me I've always found headless browsers to be really interesting, and knew exactly what I myself would want as a developer, so I built just that.

Where can we go to learn more?

You can check out more browserless updates on Twitter at @browserless. Or you can follow me directly at @griffith_joel! Thanks for having me.

and
  1. 1

    If it could happen to you lottery numbers, i think you are the lucky guy. Because i never win in this game. I always read about strategies but i think i loser =D By the way, found it on https://bovegas.com/blog/big-wins/movie-lottery-winnings

  2. 1

    you should consider combining your service with proxies

  3. 1

    I used Phantombuster before after I had endless hassles getting Chromeless to work on AWS. There is definitely a market for this sort of product. Good luck with this. I have a project coming up which needs to do scraping, so I'll give it a try some time in the future

    1. 1

      This comment was deleted 6 years ago

  4. 1

    Hey. I’m sorry to be the one who asks this, but I don’t understand why people would need this. I appreciate they do but I dont understand why. Can you give me an example use case? I read your site but there was none in there.

    1. 1

      Great question -- It's definitely a challenge with this project since most people won't need it until they run into the problem. A great use-case is taking screenshots of your website. Most service just let you specify a URL, which works for the majority of cases, but what happens if you need to click-through to get to the site you need to capture? It's cases like this where you'll need to run headless Chrome yourself and tell it what to do and when/how to screenshot.

      Another case is screenshot resolution -- again something that most services have limits around. If you need high-DPI screenshots then you're left with running Chrome on your own infrastructure and managing it.

      This is where browserless steps in to help. It's quite tedious to manage Chrome, get it setup properly for linux systems (which most servers use), and ensure it operates like one would expect. The value browserless adds is that you can do any of the cases above without losing an incredible amount of time getting it setup.

      Hope that clears it up. I'm working on making this more clear in my site and in documentation, so great question.

  5. 1

    If it works, is secure, and generates revenue, then that's all that really matters.

    Having seen how things can go wrong for businesses that don't at least think about security, I think it's great that you called it out here.

    1. 1

      Yeah, security is something that keeps me up at night. Even when you think you've got it you're probably overlooking something trivial. More needs to be said about securing web-apps

  6. 1

    Congratulations Joel, this looks like an awesome and much needed product. Have used Navalia and was as happy as one can be with a headless browser library so I'll definitely check this out next time I need to run large numbers of headless scripts.

    Do you think it's possible that developers could write headless scripts so extensive that they could essentially create unofficial APIs for some web apps? As an example of what I mean, I tried to write a headless script to order online groceries a little while ago, with the ultimate goal of me being able to hand a script some product names and have it order all those products using the supermarket user interface. I ran into a lot of issues and gave up since I didn't really need it but I couldn't see why it wasn't technically possible. What do you think?

    1. 1

      It's definitely possible -- but challenging. Site continuously change and update, so things like selectors and what not will break frequently. I think there's a lot that can be done in this regard to capture issues, like taking snapshots of where failures happen. Definitely a hard problem

      1. 1

        I think diffbot.com deals with this problem using machine learning. None the less, indeed a hard problem. But user generated content (scripts) can easily be incentivized for the developers to continuously maintain them as they break.

        1. 1

          It's not quite the same problem I was referring to, I want to create APIs from sites that can be used to replicate user actions rather than just extract data (although diffbot and its ilk are very impressive). This would in a lot of cases require the bot to log in as well so I'm not sure how that would work regarding security? User generated scripts is a good idea for sure.

          1. 1

            Ah I see, so an API to control any website... One example I can think of is an API to control say an ecomm site like Amazon and place orders like a real user?

            1. 1

              Exactly like that yes, seems like a difficult but doable thing.

  7. 1

    I remember seeing this posted on HN and probably other places, glad to hear it's going well!

    1. 1

      Same here: saw Joel on a Github issue. It may have been PhantomJS :)

  8. 1

    Delighted to see you here Joel. Just wanted to say thanks for your help when I was trying browserless, my app has since moved away from needing screenshots (for now), but will probably be back in the future. For anyone reading this, browserless absolutely took the pain out of running headless chrome on heroku, I was battling it for weeks before Joel's plug and play app made it easy. This is starting to sound like an over the top plug, but just wanted to say congrats Joel, I haven't been back in the slack chat of September sprint since I got a new phone, is it still going strong?

    1. 1

      Chip! Thanks so much for the kind words! Our Slack channel is still going well, there's a good few core folks there that are always discussing stuff and offering advice. It's been really refreshing to be a part of.

      1. 1

        That's great. I must pop back in! All the best going forward anyways. 👍

  9. 1

    There are may be only a few people who want to scrape with headless Chrome, but there are many people who want answers to questions that can best be answered by scraping with headless Chrome.

    As a developer, here's something that would be interesting to me: build a serverless marketplace on top of browserless. Developers post scripts that answer particular questions (like what is the price of a particular item on Amazon vs. Walmart). The services those scripts provide are then sold at some rate. Revenue is split between browserless and the developer.

    1. 1

      Huh, that's incredibly fascinating. I haven't given much thought to a market-place can see the value since most folks are just rinsing/repeating failures of the past.

      It'd be cool to subscribe to a serverless workflow via a webook and updates can happen seamlessly when scraping begins to fail (as it does). That way we're isolating consumers of the function from the implementation details.

      Man this is sounding better the more I think about it.

      1. 1

        You could take this even further - a marketplace where developers write the "scripts" and maintain them, business analysts or just non technical users pay for the scripts that are pretty much gauranteed to work since there's a dev behind it. Dev gets a cut you get a cut for the platform, win win :)

      2. 1

        If you're looking for a partner in building something like this out, I've got some spare cycles and think it could be pretty fun.

  10. 1

    Hey Joel,

    This was an interesting write up. Answering questions on StackOverflow and Quora is a great way to produce real value and introduce your product at the same time.

    My question for you is: what issues did you run into while building this business? Payments (Stripe), Hosting (Docker/Heroku etc.), VCS (Github/BitBucket) all already have great products filling those needs. While building your product, was there any particular issue that took significantly longer than others?

    1. 1

      Awesome awesome question: I think that there definitely needs to be more done around account management and authorization. Those problems are extremely hard to get right, and tend to be insecure when dealing with authorization. Also knowing where your audience is can be tricky, and the answer is generally to build it yourself. That takes years and isn't something that's easy for everyone to do, so having a way to find users and know how to approach them would be an interesting problem to tackle. Unfortunately I'm still a beginner in that regard so it's hard for me to know what the solution there looks like.

      On the technical side managing your app's topology is pretty challenging. I have a good mental model of how browserless works, but to try and describe it to someone else would have me looking like a conspiracy theorist! Kubernetes and docker are steps in the right direction, but it'd be nice to have some sort of static artifact that describes your architectures dependencies would be interesting to tackle.

      1. 1

        Regarding user auth, did you look at providers like Auth0 or Firebase?

        When Meteor.js was introduced, one of my favorite features was the ability to drop in a simple Spacebars tag ({{> loginButtons}}) and instantly have a preconfigured user system. I always thought it might make a good standalone product.

        If you did check out solutions like Firebase or Auth0 (or any others), what did you find lacking?

        1. 1

          I very briefly took a look at Auth0 and Passport (since the infra is written in node). For reasons that probably aren't accurate I felt that I would move quicker if I just did it myself. If Auth0 had a "quickstart" guide that wasn't more than 5 steps I likely would have gone with them. Stripe really knocks it out of the park with this: their quick guides are amazing.

          Firebase is something that's still in the back on my mind begging to be looked at. I'm not sure exactly what problems it solves and need to investigate further.

          1. 1

            For reasons that probably aren't accurate I felt that I would move quicker if I just did it myself. If Auth0 had a "quickstart" guide that wasn't more than 5 steps I likely would have gone with them.

            I've avoided their service for this reason as well.

            Firebase is an entire mBaaS and as such has a wide array of products. Though, like Auth0, setting up accounts is not as easy as it was with Meteor.

  11. 1

    This is much needed product. As a developer, I understand it is not easy to run browserless scraping on services like Heroku.

    There are few ways you can grow.

    1. provide free trials option
    2. For indie developer/freelancer from Asia $30 is high price. so may not adopt it. You can provide small price package.
    3. Provide more details how to integrate with different programming languages like Java, python etc.
    1. 1

      Thanks so much for the feedback Keyul. I'm definitely pursuing a pay-as-you-go model which should land in the coming weeks. I'm hoping that this will engage some of the smaller use-cases vs large enterprise clients.

      I'll definitely keep you posted!

    2. 1

      This comment was deleted 5 years ago

Create a free account
to read this article.

Already have an account? Sign in.