What I would be doing
Tanvir asked me a few days ago what I would build today if Buttondown didn't exist and I was still keen, fully employed elsewhere. This is a fertile question, because now — more than ever — feels like the age of dwarves, both in terms of forging and mining. There are so many good things to be built, and so little time to do it, even though by some axes productivity is higher than ever.
There are a few different ways to answer this question, and I don't think any of them in and of themselves are complete. So I'm going to barrage him (and you) with a constellation of answers, in hopes that it approximates something approaching the truth.
An impossible supposition underpins this exercise. Do I pretend that I still know everything I've learned about Buttondown, or is this an Eternal Sunshine moment where my entire history of company-building has vanished? For the purposes of this: let's say that I was legally barred from ever touching Buttondown ever again, and go from there.
One. Something email-related — but probably not newsletters.
I did not appreciate how weird the email industry was until I really got myself waist-deep in it. Email is the largest and most ubiquitous technology in the world; it predates the internet itself, and despite all of those things, usage only continues to grow. It is, as SwiftOnSecurity put it a while back, the one promise of decentralization fulfilled.
A lot of people ask me, at various stages and venues, how I would hedge against email going away — whether it's the result of LLMs or some other hitherto nascent technology catching on. My answer is simply: I wouldn't. Buttondown is a core business, and my approach to building Buttondown is based on a somewhat opinionated thesis that email will be around forever. I'm not saying that it will be, but I'm saying that our business and my approach to building it relies on that being so.
There are a lot of bad companies in the email space, and a lot of room under the area curve to improve. Deliverability management is a great example; rendering management and things like Litmus are another. The general side effect of having an industry that is first and foremost dominated by marketers rather than by engineers is such that there is a lot of fertile ground that most people abstractly recognize but cannot act upon.
That being said! Assuming I know what I know, I don't think I would want to build a business like Buttondown again. Please don't interpret that as ingratitude or misgivings — it's been a very good time, and incredibly rewarding, both spiritually and financially. But there are two big problems with Buttondown and Buttondown-shaped businesses, the way I want to run them:
- They're dominated by long-tail prosumer dynamics, by which I mean you spend an inordinate amount of time working with and optimizing for a $9/month customer.
- Buttondown is in the business of doing a thing that is risky. Sending an email to 10,000 people carries risk. When you fuck up, there are no take-backsies. Even with payments, you can reverse a charge — you can't reverse an email.
Our stuff is so ironclad at this point that this hasn't been a meaningful issue at scale for a long time. But especially when Buttondown was first growing, I had a lot of sleepless nights worried because I changed something seventeen hours ago in our rendering or sending pipeline and I didn't know if it would subtly break something that we hadn't noticed yet.
Two. Public data.
I am fascinated by the amount of public data that is valuable and ripe for the picking. Shovel is about this, obviously, but there are many, many other examples. It should be much, much easier for you to get both broad and deep information than it currently is. I am baffled by the fact that I cannot, for example, get an email alert when one of my competitors raises pricing.
Three. Developer lifecycle and metrics.
It is no secret to anyone reading this blog that we, as an industry, do not know how to measure productivity. I do not mean this in a "slang for things that make it easier to justify stack-ranking someone" sense. I mean it genuinely: when CI times double, or flake rate triples, that hurts an organization. But we haven't yet developed the knowledge, wisdom, and praxis to understand and quantify how.
Every single company in this space ends up chasing the mirage of DORA, because that's what they can sell into the enterprise — because at least theoretically the enterprise is really the only cohort that cares about this stuff. I don't really think that's true. I think the fact that I have to bust out my dusty notebook filled with git one-liners and figure out what specific commit or dependency ballooned my overall slug size from 100 megs to 300 megs is insane. I think the fact that every single company has to more or less invent observability and anomaly tracking from flour, milk, and eggs is insane. We are very, very early in the arc of building up technology — in both the literal and figurative sense — around all of this stuff.
Four. Weird verticals.
Don't believe the chicanery about every vertical being tapped out and vertical SaaS being a dead play. It is simply untrue — a lie parroted by Yale MBAs who are unable to think their way out of a Shopify App Store roll-up.
If you have any friends whatsoever who aren't in tech, shadow them for a day — or maybe even an afternoon — and you will suddenly discover an entire universe of software designed and sold courtesy of the principal-agent problem. Insofar as I love technology because I think it creates value for people, there are few better examples of this than purely vertical SaaS, and the ability to save a gallerist or a clinician thirty minutes every week. That is virtuous.
It is also trendy to say that vertical SaaS is dead in the age of LLMs. I encourage you to think really hard about what that sentence means, and then see if you still agree with it once you're done.
Five. Payments.
No, no, no, no, no — not like that.
Stripe has finally crossed the chasm into the enterprise, a fact reflected both in their 409A valuation and the nesting structure — matryoshka meets Kafka — of their documentation page. ("To sufficiently model the universe, you must first create a meter event.")
One of our biggest areas of support burden at Buttondown is paid subscriptions, and frankly this is because we have to cosplay as Stripe's support. Stripe's Connect model is beautiful and transformative, and I'm grateful for it, as are many, many companies. But also: we expect authors and yoga instructors who have never heard of Klarna in their life to navigate an increasingly labyrinthine payments menu.
In much the same way, there are very large and robust companies that sit — like remora on the backs of whales — atop Salesforce. The Stripe marketplace and broader ecosystem is oddly thin; the Stripe App Marketplace only has 452 listings. And so on.
I have been on calls that have lasted less than an hour, for which I have billed over $1,000, purely because I know what the difference between an MoR and a PayFac is. I have, sadly and with melancholy, turned down clients who just wanted me to onboard them to billing. There is room to build not just technology but praxis on top of Stripe — and that's convenient for me, because I am already forever cursed with much of the knowledge required.