Day 705: Community > Revenue

product

Whenever someone asks me “how’s Browserflow going?”, I usually tell them about how nice it’s been getting so many more users and customers from the Hacker News launch and also about the question that’s been plaguing me ever since that launch: Who is Browserflow’s ideal customer?

This is a question that’s come up many, many times over the course of Browserflow’s development (Day 160, Day 166, Day 512, Day 516), but the urgency of figuring this out has increased after the launch because I realized that it determines everything about how I build Browserflow: the business model, the pricing, the marketing copy, the feature set, how I spend my time, etc.

During the launch, I heard from people who wanted to use Browserflow more but felt that the pricing was too expensive. Here’s what the pricing was at launch (only showing the extension pricing at annual pricing here because most people were interested in that rather than the cloud offering):

The idea here was to charge according to how much value someone would get from Browserflow. Execution time was a proxy for “value received”, so I’d charge more based on how much someone automated using Browserflow.

I’ve had several customers start from the Basic plan and work their way up to Startup as they used Browserflow more and more, so I know that this is a workable pricing strategy. But it comes with a significant downside: It discourages people from using Browserflow.

Since users are charged more the more they use Browserflow, unless they’re on the Startup plan (which is justifiable for businesses but prohibitively costly for individuals), they’re incentivized to automate as little as possible in order to stay under their limit.

Due to this, people are discouraged from investing in Browserflow and taking full advantage of it because it’d mean paying more. This exchange from the Browserflow Discord captures this sentiment well:

I understand the feeling he’s expressing. When you know that using the tool more would mean having it become more expensive, you’re less likely to want to learn the tool.

So what kind of tool do I want Browserflow to be? A hammer you keep in your toolkit or a chainsaw you have to rent (costs more the more you use it)? Looked at a different way, do I want Browserflow to be a tool for creators or a tool for consumers?

I’ve been chewing on this question for weeks now, and it feels like in the short-term, I’m making a tradeoff between revenue and user growth. With the “charge more for more usage” model, I think I’d get much more revenue because businesses who start relying on Browserflow would be willing to pay more for the increase in value they’re getting. With the alternative of not limiting usage, I think I’d get more users, especially those who are interested in investing in the tool and getting a ton of value from it.

Here are the personas of the two kinds of users I feel like I’m choosing between:

  • Creator

    • Technical or has experience tinkering with no-code tools
    • Requires less support / self-sufficient / willing to read through documentation
    • Skews more toward individuals
    • More price-sensitive

  • Consumer

    • Non-technical
    • Requires more support
    • Skews more toward businesses
    • Less price-sensitive / willing to pay more

After being basically paralyzed by this decision and not making any meaningful progress on Browserflow for several days, I realized that I just need to make a decision and move forward with it because the alternative of doing nothing isn’t working. It’s also a reversible decision, although the longer I go down one path, the harder it will be to switch.

My decision: Build Browserflow for the creator. Community > Revenue.

Something that helped me feel confident in that direction is getting a large influx of new French users a few days ago. One of them responded to my onboarding email and told me that he found Browserflow from this YouTube tutorial created by a French growth marketer:

That blew my mind! I have no idea what he says in the video because I don’t speak French, but I’m super stoked that someone found Browserflow valuable enough to create a 12 minute video to share with his audience.

In the long-term, I think focusing on creators will pay off more by fostering more of a community around Browserflow. The more people that use Browserflow, the more they’ll share Browserflow with their friends and audiences, and the more it’ll grow. It’ll make marketing much easier and more fun compared to doing outbound sales from LinkedIn or running ads.

And that aligns with the way I’d prefer to spend my time as well: I’d much rather create tutorials and documentation that helps every user rather than providing 1-on-1 support to a few businesses. I’m more excited about democratizing automation so that any motivated individual can benefit from Browserflow and automate their work than helping a few large companies automate their processes. At that point, I might as well just start an automation consulting business because those customers don’t care about the implementation — they just want something that works, regardless of whether that’s using Browserflow or custom code.

The kinds of things I’d like to see as Browserflow matures:

  • Users can search any website in a gallery of user-created flows and see automations they can run on that site

  • A community of passionate users creating flows and sharing them (David Bieber continues to be archetypal user in that regard)

  • Users creating video tutorials and blog posts about how to use Browserflow

  • A marketplace where the consumers (non-technical users) can request flows they want and creators can fulfill them

    • I would be incredibly excited if I could help people make a living from Browserflow in the same way that Zapier consultants make a living from Zapier

  • When people ask how something can be automated or complain about some tedious task, someone chimes in with a mention of Browserflow (I see this happen with Zapier pretty frequently)

So what about pricing? I landed on a way to structure it in a way that encourages usage while still providing an incentive for power users to upgrade (this shows annual pricing):

The key change is that all of the paid plans now allow for unlimited usage, but there’s a limit on how long a single run could be. I think 10 minutes for the Standard plan might actually be too generous because the vast majority of flows will fall under that limit, and this might mean that there’s too little incentive for people to upgrade to the Professional plan. That said, it should still encourage the heaviest users (e.g. business customers automating hundreds of tasks from a spreadsheet overnight, for instance) to upgrade.

In other words, this plan isn’t optimal for revenue because (1) most people will happily be able to do everything they want on the Standard plan and have no incentive to upgrade and (2) many people would be willing to pay much more than $49/month in order to get unlimited usage (I know this because I currently have customers who pay $149/month in order to get unlimited desktop usage, and I’m pretty they’d be willing to pay even more based on the value they’re getting). So, I’m leaving money on the table, but this whole post is about being okay with that with the acknowledgment that I’m doing this intentionally in order to encourage more people to use Browserflow. If I wanted to optimize for revenue, I’d probably get rid of the $19/month plan, have the Standard features cost $49/month and set unlimited max execution time per run at $99/month. But that’d price out the individuals, so I’m not doing that.

In the future, it might make sense to lower the barrier to entry even more for people to invest in Browserflow by increasing limits on the Free plan, creating a plan at an even lower price point (e.g. $9/month), etc. but this feels like a good starting point.

Automation for all. Let’s goooooo!