March 30, 2020
Roads, being mapped.
I have spent all of two weeks with a public roadmap. Some notes thus far:
- I’m at least a little bit incentivized to make things clean and legible for a (largely theoretical) audience, which has forced me to do more planning and writing out of things as opposed to just my doctor’s handwriting scrawl in GitHub Issues, where I had open tickets like “subscriber .biz bad fix”.
- It’s already growing a little overgrown; there are too many fields and metadata to be a breezy read.
- Forcing myself to have this be the single source of truth rather than a PR or Things has worked well so far, even if it means adding some stuff that makes absolutely no sense to the casual observer:
A note on the above item is that I’m growing increasingly intrigued about breaking out email validation into its own API or product as it grows more important (and gnarly/painful.) I am oddly proud of some of the architectural work, but I definitely need to take another look at all of the volume I’m sending Mailgun recently: that bill is starting to dwarf Heroku (and everything else) when I can probably do something along the lines of “if this email is from hotmail assume it’s garbage”.
Internationalization
I am thinking a lot about internationalization. More than half of Buttondown’s revenue comes from non-American users; I have gestured wildly towards internationalization being on my roadmap forever and really not seriously done anything with it, and I think it’s about time to change.
My only experience with i18n/l10n was from my iOS days, which is perhaps why I’ve been so hesitant: it is a pain. Localizing strings is annoying to do from a code perspective and an administrative perspective. I’d limit this purely to public-facing stuff (which is to say: I wouldn’t translate anything on Buttondown’s app, just on the newsletters; localizing the subscriber experience but not the author experience), which definitely constrains the scope somewhat, but still.
I think the first two steps are to identify the cohort of relevant pages and the cohort of languages, and the latter is more or less set in stone: French, Spanish, and Italian. I have no idea what the cost breakdown will be like, which is always, uh, fun. But the impulse to avoid projects that can’t be solved with coding is one I need to break, and this is a good work in that direction.
Feinting towards resilience
I have a status page now! It’s not quite live yet; it still needs a webhook integration with Pingdom that I need to roll myself for reasons passing understanding, and I need to link to it from the main app, but it’s getting there.
(It is very wild that I have to roll my own webhook integration to just get Pingdom talking with StatusPage correctly, but the alternative is jumping my Pingdom subscription to $149/month. I’m all for spending money to save engineering labor, but…that’s a lot of money for very little labor.)
This was spurred by Heroku’s outage last week that I’ve been meaning to read about. Recently, someone asked what I would do if Mailgun went down, and, well, I didn’t have a great answer — which, I suppose, is why the header of this section is feinting towards resilience. Visibility is the first step; building out SES rails is the second step.