Day 526: why developers?

marketing

if you read through my mega stream of consciousness brain dump from yesterday, you know that i’m initially going to be targeting developers/builders who are nerds like me as my target audience rather than commonfolk who have better things to do than sit around talking to computers all day

now this might seem surprising given that one of the major selling points of browserflow is that you don’t need to know how to code to use it. you can record yourself doing stuff or point and click on some commands to have browserflow generate the code for you in the background. it’s magic! so why not focus on that? after all, developers already have alternatives — they can build their own solution using the plethora of libraries and tools out there — so wouldn’t this be more compelling to those who aren’t able to code?

err… not really.

i’ve personally onboarded dozens of people onto browserflow, and there’s a stark difference between those who know how to code and those who don’t. because while browserflow doesn’t require you to know how to code, it’s really difficult to build flows unless you can think like a programmer.

the problem is that browserflow operates at a pretty low level. unlike say, zapier, where you’d say that you want to “send an email to recipient X”, with browserflow you’d say “click on the compose button, click on the input field, type in the recipient name, click on the body, type in the body, click the send button”. (to be clear, for something like sending emails where there are established apis, browserflow is not a good solution — it shines when there aren’t APIs to do something) the point here is that there are many places where things can go wrong. maybe the button you need to click isn’t always there. maybe a popup appears if you’re not logged in so you need to dismiss it before continuing. there are a bunch of things that can go wrong, which is why it’s almost necessary to be able to think like a programmer — breaking things down into the core components, considering edge cases, being able to run through things step by step and update your mental model, etc.

anybody can learn to think in this way, but it’s a skill that needs to be developed. thus, it actually seems quite hard to build a product that is both super accessible and flexible enough to handle a multitude of cases rather than a select few.

this means that while anyone can run flows, only people who have the interest and the skills to think like a programmer will be able to come up with creative and interesting solutions

building for developers holds a ton of appeal for me:

  • since i’m a developer, i can understand my target audience and their problems a lot better

  • developers are used to reading documentation, searching online for solutions, and generally being quite resourceful, which means that they’re a lot easier to support than people who go straight to sending an email or opening a support ticket

    • i want to be able to scale support by documenting things better, not by hiring a lot of people

  • developers who work in browser automation will instantly get the value proposition of browserflow and the work they’d save compared to building their own solution

    • ngl i feel the most seen when i onboard another coder to browserflow and they’re like “dude wtf this is insane” because they understand just how much went into building this behemoth of a product
    • it’s a pretty small niche though so it’d be advisable to try to educate and show examples of how this would be valuable to a larger audience

  • i like people who build and make things in general so it’s exciting to me to help people who want to build cool things on top of browserflow rather than teach someone how to use a particular ready-made solution

tl;dr i <3 developers