We are officially in Q4 — the time has flown. I'm reading through the changelog entries from this time last year, and it feels like a foreign country. It's also interesting to note which items stuck versus which things did not: building out email filtering was a foundational piece of technology that we now get to reuse in a bunch of different places; meanwhile, our emphasis on integrations and various one-off things barely recouped their implementation cost. (Will I learn any lessons from this? Only time will tell.)

Planning

I have historically been anti-deadline because I think the manufacture of false urgency does little more than occlude and dilute real urgency when it appears. Still, I also know two things: I am prone to snacking style work at the expense of really meaningful, ambitious projects, and I also know that you can't bench the bar all the way to three plates, so we're bringing back some lightweight project planning, by which i mean just scoping out issues on a month-by-month basis:

(This is something I deeply miss from the public roadmap, too. I have plans to bring that back in some capacity, but that's — as you can perhaps divine from "Mature the marketing site" — in November.)

Database

I got to spend the first half of this week putting out database fires. The irony is that I believe the cause of these fires was us trying to flee to the hills. We were experimenting with onboarding to PlanetScale, and the logical replicator we set up was so taxing on our poor RDS instance that the entire thing collapsed. On the one hand, things actually went pretty smoothly considering our database was on fire. API response rate spiked pretty aggressively, but our two core workflows, archive views and subscriptions, both remained rock solid. Still, I took this as an opportunity to go through and polish the performance of some of our highest traffic routes to see if there was any medium hanging fruit left to yoink.

By the way, here's a fun fact that is not immediately obvious: 50% of our traffic by request count and 30% by overall processing time is our RSS feeds. One bit of low-hanging fruit was that we were actually updating in band when a RSS reader that supported analytics hit us. Moving that off thread made the inevitable thundering herd of hourly reader updates slightly more palatable:

Onboarding docs

Now that we've launched the product experience for onboarding, Nick has turned his attention to the documentation. I've had a lot of fun watching him recoil in horror at the size, scope, and messiness of our docs.

A little sidebar: we have a really great customer base to the extent that they're extremely well trained to check the docs first before emailing us. This leads to two second-order effects:

1. Our docs are optimized for search and point lookup, but not narrative. If you want to figure out how to set a specific kind of metadata, you're in luck. If you want to understand what metadata is and why it might be useful, we do a poor job of answering that for you.
2. Our support burden now is basically dominated by the long tail. When you're sufficiently diligent about documenting and surfacing any common requests, all you're left with are the uncommon ones. (This is a topic for another week.)

What's very clear is that if you are a new user to Buttondown who has some but not a lot of understanding and you go to docs.buttondown.com, we do not exactly set you up for success.

/home as platform

I want to end with a very boring screenshot.

The story behind this screenshot is a simple one. A customer was having some deliverability issues, and after poking around, we discovered that the issue was that they have two DMARC records, and a number of European mailbox providers fail validation because that's technically a violation of the spec.

There's a number of ways that we could solve this problem in varying degrees of aptitude. We could not address it at all. We could add a bullet point to some deliverability documentation telling the user to check this, or we could proactively check it ourselves and surface it in an obvious high-visibility place for the user to act upon.

More than anything, the success of the homepage, which has been rapturously received, not to editorialize too heavily, is we now have a place to put those things. Obviously, this can be abused if all we ever surface are cross-sell opportunities and annoying things of that nature. But part of managing a product like Buttondown is dealing with all of these various pieces of exogenous state and finding the right balance between delegating to things like Stripe versus owning the full experience. And now we have a really lovely place to do the middle ground of surfacing information to authors without having to build out a net new flow for each possible circumstance.