Day 213: Browserflow Money Plans

So let’s, uh, talk about money.

The question that this journal supposedly explores, as formulated when I started Road to Ramen, is “Can I make a living build things I love?”

In practice, it’s more like “Just how many times can I talk about the importance of sleep, exercise, and nutrition before I start boring even myself?” I guess I talk about product-related things every once in a while.

What I don’t talk about is the first half of the original question: “Can I make a living […]?” Money.

Two reasons for this:

• I have plenty of runway left
• Building something dope is way more interesting to me than making money

I’m not in a rush to make money, but it does seem prudent to think about how to monetize the products I build so that I make this a sustainable venture. So I’ll use today’s post to think through the different ways to monetize Browserflow!

I see two potential approaches for making money from Browserflow:

1. Charging for the tool
2. Charging for the ecosystem

Charging for the tool

This is the more straightforward of the two and is common in the SaaS world. People pay $X/month in order to use the service.

There are various approaches even within this category, like charging per user (e.g. Figma) and charging for usage (e.g. Zapier):

Overall, the focus is on restricting access to the tool past a defined threshold (premium features, usage, etc.)

Charging for the ecosystem

In contrast, another route I can take is to provide the tool for free and make money off of the ecosystem. This is the approach taken by app ecosystems like the iOS app store, Android app store, etc.

What if I created a marketplace for people to publish their flows and sell them, while taking a cut of each transaction in the marketplace?

Of the two, charging for the tool has stronger appeal because managing an ecosystem sounds much, much harder. I want Browserflow users to be secure, which means that I’d need to either:

• Manually vet flows that are published to ensure they’re not sketchy
• Require flows to be unminified / unobfuscated

Developing a vetting process to make sure flows are safe sounds like A Hard Problem, and I’d just be building my own version of the Chrome Web Store.

If I require all flows to be transparent to the purchaser, then it’d be trivial for them to share the flow off-channel, create modifications, and encourage pirating.

That leaves charging for the tool. The thing is, I want to encourage as vibrant an ecosystem around Browserflow as possible so that people can find flows for all sorts of things. Today, I onboarded a friend who developed a flow to unfollow everyone on Instagram, and I’m sure that’s something many others have wanted (it’s one of the first flows I built as well).

Hahah, I’m losing interest in this topic just writing this post. I’d really like to be able to just build cool things and give it all away for free but unfortunately, our society requires us to earn money to pay for our needs aka justify our existence.

Alright, so it seems like Browserflow would probably need to go the route of creating plans based off of features / usage. Making some commands into “premium” commands would feel a bit strange. Is there a way to restrict usage while still letting people experiment with creating flows and experience the benefits of using Browserflow? Okay, I’m tired and this is boring so gonna punt this untilI I look more into how similar solutions charge for their products and continue this some other time.