July 22, 2019
I’m in the process of working out a two new business models for two new customers. Neither may come to pass, but they’re both fairly interesting in their own right:
- Heavily using Buttondown’s API as a “newsletter as a service” SaaS; automatically generating new newsletters for each premium user, registering new subscribers on their behalf, and sending emails at certain points. Here, the customer would basically be eschewing Buttondown’s UI entirely and just using it for all the other stuff; subscriber validation, email formatting and sending, that kind of thing.
- Using Buttondown to send two emails a year (results of something akin to an annual survey). Here, the customer would be eschewing all of Buttondown’s subscriber-stuff (they’d provide their own list and don’t need management tools) but use the UI and email integrations to send an easy newsletter. Specifically, they don’t want to pay a high monthly cost (this user’s audience is around twenty thousand folks and they don’t want to spend hundreds of dollars a month just for two emails a year) but just pay a single fee per email.
Both of these are new business models to the extent that they are new interaction mechanisms for which I don’t have a great way of quantifying value. My current pricing mechanism is. definitely janky, but I have a good understanding of how to think about its jankiness (you pay if you are getting a large audience, and you pay more if you want to do more interesting things with that audience.). Here, though, there are a panoply of options I can consider:
- Simply say no. This is in many ways the most tempting option — new business models increase the surface area of the application, add more failure cases, and multiply the number of considerations I have to, uh, consider whenever I change something.
- Say yes, no questions asked. This is obviously a terrible idea. I am not optimizing Buttondown for growth; I am not optimizing it for revenue, either.
- Say yes, eventually. Both of these options dovetail with things I’d like to do eventually (I want my API to be more full-featured and I want a more elegant way of expressing pass-through costs), so I can simply let these folks know that they can expect this in, like, spring of 2020. This is, in many ways, the base case: to record the additional demand in a GitHib Issue but not act on it in any serious way.
- Say yes, but charge a lot for it. This is what folks recommend, and it is rationally a good idea. In the first new model (larger programmatic access) I think I can make a pretty legitimate value-anchoring argument; the alternative to me making this functionality available is them building out this functionality, which is going to be an order of magnitude more expensive than the “a lot” I charge (say, $200-$500/month at an annual rate to represent the up-front engineering costs). The second one, though, is for a more price-conscious customer where that is going to be an ~impossible sell.
I feel like I tipped my hand with my writeup of all four options; I’ll generally be going with option three. There is a version of my life in which it is prudent to slave my nights and weekends in an effort to build software, but I am no longer 23 and Buttondown feels best when I treat it as a prized horse rather than a sow. (I don’t know anything about farms. Both of those metaphors might be terrible.)
Still, these conversations are good to have. Besides the requisite navelgazing, thinking about “the future of Buttondown” is a useful way to guide my decision-making in the present.
Speaking of decision-making in the present, this whole “July is a month of marketing” thing really fell by the wayside. I blame, as I often do, extracurricular factors (I’m buying a house!) and that my damaged, endorphin-hungry brain still thinks commit messages are more exciting than blog posts.
But this past week I’ve worked on some uninteresting and important things: bug fixes, a new Google Contacts import flow, and some performance improvements around email validation. And this week will be more of the same: but July has been a listless month, and I’m starting to think that August will be better served with a couple larger projects.