Hi Joel! What's your background, and what are you currently working on?

Hey everyone! I’m Joel Griffith, a Portland, Oregon based Software Engineer (now turned entrepreneur) that’s been working a ton on this thing called browserless. browserless is, at its essence, what I call “chrome-as-a-service.” What that means is that when a developer needs to have programmatic control over a web-browser as part of their service they can use us to provide it. We take care of installing the browser, running it in a streamlined fashion, and other small details like making sure fonts are installed properly. Right now, the #1 reason users use it for is generating nice PDF files from their website, which can be a pretty hard thing to do.

This service is incredibly useful for a number of things, such as capturing screenshots, PDF generation, and data-gathering. Unsurprisingly there’s a lot of players out there already, however, practically none of them offer on-demand programmatic access 24/7. It currently generates revenue in two ways: an old-school license model and a monthly subscription for “hosted” access.

Currently, I’m working on a new usage-based account type that does per-second billing. This has been an incredibly interesting feature, and often requested, since it’s really cheap to get started ($0.00008/second!).

‍

What's your backstory and how did you come up with the idea?

Back about a year or so ago, I was trying lots of ideas out to see if I could come up with a side-project to generate some residual income. I had a lot of skill as an engineer, but not a lot of business or marketing sense, so I was trying lots of stuff and was having a hard time gaining traction. Truth be told, the idea originally came from me working on a wish-list app that you could build from multiple providers (think of something like an Amazon List, but across all retailers). Doing this required me to build a scraping-engine so I could get photos, prices and other things that would make the lists more interesting and friendlier. This was all going swimmingly until I ran into Target :)

For those that don’t know, Target runs what’s called a single-page app. This means that, when your browser goes to a page on Target, their web-servers don’t return anything interesting in their initial HTML payload. It’s only after the JavaScript runs that anything useful is finally rendered. But therein lies the problem: you had run JavaScript and a whole browser to effectively see what the final page looks like.

Having run into that I started to look for something that gave me programmatic access to a headless browser that I could use for my nice new web-app. Spoiler-alert: there weren’t any. This was a refocus event for me, and I switched gears to writing browserless. And since I knew exactly what I wanted, it pretty much built itself (well, aside from the many hours I poured into the project).

‍

How did you build Browserless?

Looking through my git history shows an initial commit back in August of last year! In the end, I wanted the final product to have two forms: a docker image which you could license and run anywhere, and a monthly subscription model where we host all the tech for you. Mike Perham (founder of SideKiq) was a huge inspiration for this model, and I’ve followed in his footsteps quite a bit.

With that in mind, I built out the core of the infrastructure into one containable unit (open-sourced here). At its center, it’s just a small web-server that proxies traffic into headless-chrome, but adds some nice features like queueing and a really nice debugger (check it out here!). Once I arrived at this stage I had the help of a few other developers test it out. This part is somewhat crucial as it helped validate the idea before I started to build anything regarding billing and accounts. These early users, whom I met whilst commenting on GitHub issues and helping out in StackOverflow, eventually became the first customers later down the road.

It’s hard to say exactly how long all this took, as past mistakes and experience sort of “rolled” up into this final product. Once I had everything in place it took about 2 months to fully build out. I’m a father and a software engineer by day, so finding the time was the real commodity in low-supply. I heavily relied on other vendors like Stripe, DigitalOcean and Sendgrid to get payment, infrastructure and emailing handled, which aren’t core differentiators to what I was doing. As far as tech goes it’s all JavaScript and Redis… and that’s it!

Launch day turned out to be sort of anti-climactic. I had a few core users that I mentioned earlier that helped validate the idea, but sites like Hacker News and Product Hunt didn’t really seem to care. Even then, posting it on high-visibility issues and StackOverflow posts got customers trickling in. It wasn’t until I started writing content that I started gaining some traction, with a best Practices post even getting its way up to the front page of Hacker News. Finding customers and knowing where to go next are still things I’m learning and getting up-to-speed on, but it’s starting to take more shape and I’ll definitely be writing more about it.

Which were your marketing strategies to grow your business?

I tried all the ones you tend to hear about: posting on big-name sites like Product Hunt and others. For better or worse the user-base for this project is quite a niche, so big audiences tend not to like it as much.

What really worked well was posting it on more niche sites like IndieHackers, web-development sub-reedits and (again) GitHub issues! This isn’t scalable, or really a pursuit I’m willing to keep up with, however it got a few users using the product which helped start a positive feedback mechanism and encouraged me to keep working on it.

Since then I’ve been trying to keep up on our blog and write about doing common things with headless browsers. These can be as boring as getting Chrome to run properly on Linux, or as cool as how Codepen has used the service for their product.

‍

What were the biggest challenges you faced and obstacles you overcame?

Taming Chrome and getting users! Chrome (which is the defacto headless browser) is just crazy-hungry for resources, so babysitting it and providing a web-service around it is crucial. Some folks don’t even put things like concurrency-limits around it and just let their apps go crazy running Chrome jobs, but there’s such a high-risk of it bringing down your entire stack if you don’t contain it. This is why having something open-sourced is extremely helpful: just because I maintain the project doesn’t mean I know everything about it and can fix everything. The community sort of gathers around the best-in-class and helps to make it better.

Getting users and understanding their feedback can especially be challenging when starting. I think it’s important to know that not everything is a rocket-ship, and that if you enjoy the project and it’s fun when you can make sacrifices elsewhere (like growing crazy fast). No one wants to sell their soul for money…. or at least they shouldn’t!!

Technically speaking the greatest challenge was the debugger. Chrome comes bundled with a remote-debugger that’s incredible, but getting all the other pieces working (like user-submitted scripts, type-ahead, linting, error-handling) is a lot to manage. Overcoming that was a big win for me, as I now solely use that tool for writing any new scripts.

‍

Which are your greatest disadvantages?

I’m definitely a build-your-own-solutions type of developer, which I’m trying to un-learn. Time is a more precious commodity than money, and all those other services out there can offer you back time in exchange for money, so trying to learn the difference between building and buying has been a challenge for me.

I think another disadvantage is that we’re slightly ahead of the market. Headless Chrome is still relatively new, and developers are still figuring it out, so I think I’m just a tad bit ahead of where others are. This can be good if you’re already established, it just means it’ll be slower to grow.

The last one I can think of is that it’s just me for right now :) I can only do so much, and will need to start thinking about hiring others and building out the business in terms of people. I’m actually pretty excited for this as it’ll be totally new to me.

During the process of building & growing Browserless, which were the worst mistakes you committed?

So many mistakes were made. Some that come to mind:

• Not building an audience earlier
• Not having a good strategy for content marketing
• Being ahead of where the market was
• Documentation was lacking
• Not sleeping enough

I love that there’s a lot of good things too. I definitely shipped early, often, and listened to users a lot. I think this helped bring browserless up to speed on where other cloud-providers are, but wish I would have spent more time on polish and documentation.

‍

If you had the chance to do things differently, what would you do?

I think I’d not get so caught up in the roller-coaster of running a business. You can literally be on the front-page of Hacker News, and the next day lose your top 3 customers. The market is incredibly volatile, especially in tech, so you’ll need a tough stomach to weather the storm.

I’d also tell my former-self to write more than is necessary or comfortable. It makes you spell things out in a different way and challenge your beliefs that you hold, plus it helps you get on another folk’s radar. At the very least you’ll get some notoriety about what you’re doing, and it’ll likely open doors down the road. Plus, you might earn a few customers while doing it.

Lastly, I wouldn’t optimize the service for every use-case under the sun. Certain sets of customers just aren’t worth all the time that they can potentially pull out of you. You have to optimize for the best customers out there, which means being open to pivots or changing who you market to.

‍

Apart from mistakes, what are other sources for learning you would recommend for entrepreneurs who are just starting?

Podcasts blogs and books! Seriously, just pick one and start doing it habitually! Personally, I need to read more, but when I’m driving, working, or even painting a fence I’m also listening to podcasts. You don’t have to absorb 100% of what’s being said in order for something to sink in and make a material difference.

However, at some point, I recommend stopping the noise and getting to work. It can be a little depressing to hear how John quit his job as a crayon-maker, and is now making $75k a month selling C# books for 2nd graders. That’s an outlier and you shouldn’t let it stop you from shipping. The #1 reason I see people fail to make money or get customers is that they haven’t built anything yet. By all means, validate and understand the market, but then get your product on the shelf so people can find it!

‍

Where can we go to learn more?

You can totally find me hanging out in the following places, and thanks so much again for having me!

• Browserless Twitter
• My personal Twitter
• Browserless Blog
• Puppeteer Slack Group
• Browserless Slack Group