Rendering; DuckDB; Stripe; DNS
Rendering
Every quarter, I gather a handful of bug reports we've received around email rendering issues in esoteric clients and try and fix as many as I can in one fell swoop.
This is the unsexy side of running an email business. You spend more time in Outlook 2003 than you would otherwise ideally spend.
This time though, I got to spend an afternoon chasing down a Superhuman issue and a couple reasonable Fastmail ones.
Zooming out, two notes I have (that I’m sure I’ve ranted about before in some capacity):
I still dream for a successor technology to Litmus. Its price is prohibitive for all but either very trivial or very flush use cases. It seems like a thing that should be particularly easy with the rise of better browser rendering technologies like Browserbase, and yet I can never quite summon the activation energy to play around with it.
Every now and then we'll get a report for a truly esoteric client, the kind of thing that has 10,000 MAUs total (only 100 of whom are in Buttondown). and I have to gently break the news to the subscriber that we're going to label it a
WONTFIX. this is generally not a thing that I like doing — we do try very hard to at least attempt a diagnosis before consigning it to the trash bin. It's hard to really draw the fault line here, but most clients that fall under this umbrella don't make the task any easier by being closed source and without a public-facing support email.
You also get forced to answer some tricky product questions. Here's one that I'm actively mulling: Fastmail does not support the figure or figcaption elements. It strips those and converts them to divs, which also means that our specific styling for those elements breaks. On the one hand, this seems like capital B bad behavior from them where they're taking completely reasonable and standard HTML elements and corrupting them. On the other hand, our duty to anything loftier than making sure subscribers have a great experience, I don't think there's an obvious answer we can always lean on. (Certainly, if this was Gmail, the answer is do whatever we need to do to format correctly in Gmail.)
DuckDB
Matias has done a thing that I've dreamed about for the better part of a year: he has shipped DuckDB to production. Right now, it's only on a handful of very small surfaces (which do just so happen to be our most painfully slow ones until right this very second), but the performance is very good. Buttondown's largest datasets are pretty much the raison d’etre for DuckDB: append-only time-series data with a reasonable number of facets (think API requests, email events, or page views.) And while those tables are growing prohibitively large to query and aggregate in Postgres without having to resort to the truly fancy stuff, DuckDB just handles them like a champ. I'm going to twist his arm into writing an engineering post on some of the inner workings, but the main thing I'm experiencing right now is a childlike sense of glee in finding all the very slow queries that we run off-thread and then seeing how deliriously quickly they run in DuckDB.
Stripe
I wrote in Unshipping things Replace Stripe's hosted checkout flows, first for fairly trivial use cases, and then for more complex ones, such as purchasing a gift subscription for a friend. It would be incorrect to say that this has been a painless process, but it would also be unfair to blame Stripe for the pain. As far as the incredibly complex and fraught surface that is essentially shipping a payment terminal to an arbitrary browser, the developer experience here is really, really good. My favorite bit is that they now auto-inject a little toolbar to let you auto-fill with a various state space of test cards.
One of the reasons why I've found all of this work tricky is because it is essentially injecting statefulness into what I've always treated as a fairly stateless surface. An archived email is an archived email. You might view it from the lens of a subscriber, which we process server-side. But that's really the only confounding factor. Now, however, we have to explode the possibility space, and a lot of design decisions that we had the luxury of completely ignoring now loom large and angry. How clever and polished do we want to be with the process of paying to view a paywalled page? Do we want to go straight to the content or let authors inject a post-upgrade thank you modal? What kind of notification do we surface to the subscriber? What should the experience be if you are browsing an archive and you've already tried to pay to unlock it, but it's failed and so on?
One of the big sins in Buttondown's codebase is the generalized form of this, which is that subscribers are not users. And while that's very nice from a philosophical standpoint, we are reaching the upper limits of what we can handle without a proper authentication abstraction.
DNS onboarding
I wrote literally four and a half years ago about how difficult DNS onboarding is in terms of support burden, and how desperate I was for something like Domain Connect to really take off and hit the mainstream. In those intervening four years, Domain Connect has, if anything, made negative progress, but we at least are in the final stages of solving the problem for ourselves. Ben has been working on delegation-based DNS onboarding, which is a high-syllable term for you set an NS record to Buttondown, and then we handle the rest for you. This has one drawback, which is that you can't use a root domain as your sending domain for Buttondown. Or rather, you can't delegate your root domain since we're still going to let you do things the manual way, if you so choose. But in exchange for that drawback, we get a lot of benefits. The biggest one is also the simplest, which is users only have to set a single domain, making their lives much easier.
In the long run though, this gives us a tremendous amount of operational flexibility. We can swap custom domains between ESPs. We can programmatically register domains in Google Postmaster Tools at all. We could even theoretically set BIMI on behalf of our users, all without them having to touch their DNS. This has been a very, very fun project to watch from the wings, and I get to dogfood it this coming week!