Day 449: Schlep Hunting

Paul Graham has a great essay called Schlep Blindness where he describes the reason why people often miss working on great ideas: they unconsciously shirk away from dealing with schleps, tasks that are tedious and unpleasant.

Paul’s essay focuses on the cost of schlep blindness for entrepreneurs and how to overcome it, but there’s another aspect to schleps that’s worth calling out. If you solve a problem that is tedious and unpleasant, that makes it all the more likely that someone will pay you to solve that problem for them. In other words, if something is annoying, then it’s a sign that there might be a good business opportunity there.

With Browserflow, I’ve long shirked away from building the cloud offering because it’d require me to manage many more things compared to providing a tool that only runs locally. I’d need to make sure my servers are up and running, that scheduled tasks are executed properly, that requests aren’t being blocked due to the IP coming from a cloud provider, etc. Basically, there’s a lot more to pay attention to.

But solving these problems means that people who don’t want to spend time on them would find the service more compelling.

This is the premise behind every successful API product. Here are a few in the browser automation / scraping space built by indie makers that manage headless browsers so that you don’t have to:

• Browserless: $45k MRR
• Scraper API: $1.5M ARR (2019)
• Scraping Bee: $30k MRR

Even though they provide similar offerings (at least the latter two; Browserless is a bit different), they’re able to succeed because they solve a real pain point. No one wants to spend hours and days managing their own headless browsers and proxies.

When I look at the existing offerings out there, it feels like Browserflow’s scope may be way too large because it’s a superset of the services listed above. Not only would I need to take care of handling headless browsers (and eventually proxies), I’d need to run commands on top of it. Hopefully this means that it’ll be able to address an even larger market (i.e. people who aren’t technical enough to build on top of an API), but it’s also possible that I may be way better off focusing on a specific use case (e.g. how visualping is focused on monitoring web changes) rather than providing a general platform. We’ll see!