Day 225: Cloud Browser

Onboarded one of my close friends who works at Google, and after wasting an hour on major shenanigans where we struggled to get Browserflow working on his corporate laptop (Google’s security policies are no joke), I finally got him set up on his partner’s laptop.

It was the smoothest onboarding I’ve had so far. Some of that comes from me having had some practice onboarding people at this point, but most of it’s from how quickly my friend picks things up (he’s brilliant).

After the onboarding session, we discussed his use cases for Browserflow, and I mentioned how others have told me how useful they’d find being able to schedule flows to run in the cloud. He agreed, and I know it, too, even though there’s a part of me that almost doesn’t want to believe it because it means there’s much, much more work to be done.

Building support for Browserflow to run in the cloud feels much like the idea of building Intention on mobile: I know it’s the right thing to do and that it will make a huge difference, but it’s difficult to swallow that fact because it means leaving my comfort zone and entering vastly new territory. With Intention, it would have been learning iOS development, which I haven’t touched in almost five years; with Browserflow, it’d mean setting up servers and managing backend infrastructure.

The catch with supporting running flows in the cloud is that it targets a completely different set of use cases. Running Browserflow locally is great for utilities and power shortcuts (e.g. copying a snippet of an article in your favorite note-taking app, taking a screenshot of an element), and running Browserflow remotely is great for scheduling periodic automations or data scraping (e.g. buying a sold-out item when it comes back into stock, receiving alerts if some piece of data changes, running a data pipeline). Some use cases, like data scraping, can be done on both.

The productivity use cases are interesting, but Browserflow becomes truly magical when it can run on its own without relying on the user’s browser being open.

Oof, it’s almost overwhelming thinking about all the parts that are needed to get Browserflow working in the cloud.

But it doesn’t make sense to get ahead of myself — I need to focus on one thing at a time. Get the local version working great, and I can carry it over to making it run on a headless browser as well when the time comes.

Hm, maybe I should look into working with other people on this? This scope feel ridiculously large for one person.