Day 378: Keep the Lights On, Then Scale
I see two potential avenues for releasing Browserflow:
-
Limited release
- Slowly onboard people by charging them to join the private beta
-
Open release
- Make Browserflow publicly available and post it on Hacker News, Reddit, etc.
After talking with Jeremy and Christina today, I’m going to go with the limited release / slow rollout. Releasing openly is tempting because I know that there’s a good chance that Browserflow would do quite well on Hacker News and get thousands of people using it similar to how the launch for Intention went, but for Browserflow, I want to focus on revenue from the get-go so that I actually get closer to being ramen profitable.
Long-term, I’d like to have a free plan for personal use so that there can be a rich ecosystem of flows for automating workflows across all major sites, but I think it’ll be easier to go from paid to opening it up rather than start out free and then try to find a way to charge.
Jeremy reminded me that charging for your product also attracts a different set of users and that paying users tend to easier to deal with compared to free users, contrary to what one might expect. Many entrepreneurs have observed that it’s much more pleasant to have 1,000 users paying $30/month than 30,000 users paying $1/month.
The challenge with Browserflow is that because it’s a general purpose tool, it’s harder to market. Pretty much every platform related to advertising or buying and selling goods has specific automation tools available for it. Some examples (just google “<service> automation”):
- Poshmark: Closet Tools
- Depop: SalesBot
- Facebook Groups: GroupLeads
- Twitter: Tweepi
Due to Browserflow’s flexible design, it can support any of these sites, but it’s not specialized for any of them. That means that it doesn’t provide deep interface integration with any of these services — it requires loading a flow and running it via the editor or the command palette, which requires a bit of learning. The flexibility works great for long tail use cases (e.g. automating a startup’s internal admin site), but is a drawback for the common, general use cases.
In short, Browserflow is like a spreadsheet (general and flexible) whereas most automation solutions out there are like Quickbooks (targeted and focused). Given that spreadsheets are extremely popular, I’m hopeful that there’s room for a general-purpose solution that works well across a variety of domains.
But for getting Browserflow off the ground, I think it makes most sense to target a niche and expand from there rather than try to introduce it as a general-purpose tool.
The plan:
- Talk to people with business use cases (not personal) that may benefit from automation (e.g. Shopify users, customer support folks at startups)
- Identify a niche to target and create relevant flows
- Publish a case study for that niche
- Market Browserflow for that niche
- Repeat until Browserflow acquires Google
Once I have enough validation and revenue from going B2B, I’d like to be able to provide a free personal plan so that anyone can try it out which will also help for growth. But for now, the plan is to focus on helping businesses!
(This is basically me having the same realization that I already had from my conversation with Shiva months ago. I actually have to act on it though.)