I wrote last week that my singular mission was to work on Panoply (multiple newsletter support) and get it to a dogfood-ready stage. Lo and behold:
I am in fact sending this newsletter through my account which has Panoply enabled. 1
Working on Panoply last week was revealing.
Approximately 10% of the time was spent on delivering the thing that was in that screenshot: a modal with all of the different newsletters for a user, and then a tiny backend endpoint to change the “active” newsletter to the thing you click on. This was easy and painless: I had, in a rare feat of foresightedness, planned out the necessary database changes over the past few months, and done all the legwork in migrating the plumbing, so that the PR to “create” Panoply was only around one hundred lines. 2
This was something that wasn’t strictly necessary (you’re still only ever looking at one newsletter at a time!) but felt right to do. When the choice I have as a developer is either “spend five hours revising this long-standing technical assumption” or “spend two hours building out a lot of janky verifications & edge-case handling”… well, I can’t say I always choose the former, but here it was the right option.
This isn’t something that can really be caught in how I forecast work, which is why I am trying to shy away more from providing estimates to folks. Sometimes I want to spend twenty hours on something that I can spend three hours on; sometimes the opposite is true.
Anyway. Panoply is going to be live for around a dozen people by the end of the week. There’s still manual labor involved: I haven’t built out the UI around combining multiple newsletters, and I want to make sure that it’s worth it. I might end up deciding that multiple newsletters is a premium feature, for example; I might end up figuring out that only, say, 1.5% of my user base actually has multiple newsletters and it’s worth handling them through just an “email me!” CTA rather than building out interface that I then have to maintain.
Even typing that out — I might end up deciding that multiple newsletters is a premium feature — is a reminder that I’m overdue for a re-examination of my business model, which is essentially unchanged since launch. I don’t foresee the thresholds model ($5/mo/thousand subscribers) changing, because that has a scaling elegance that I really enjoy, but “Buttondown for Professionals” is slowly getting subsumed to become just “Buttondown with a custom domain”.
A thing I have been toying with is all premium-y features (API, analytics, custom domain, paid newsletters, multiple newsletters, etc.) for a slightly lower monthly price point ($19?) that I could be pretty aggressive about upselling into annual subscriptions ($199!). I am… pretty bad at thinking about pricing, so we’ll see.
As mentioned last week, I spent the past three and a half days ensconced in the Portland sunshine. I missed forty-seven emails, a couple alerts, six Twitter DMs, a GMail outage, and a lot of development time.
It was also the first truly offline vacation I’ve had in a while, and it was glorious. Shifting back into work mode is always a little rough, but it reminds me of how fortunate I’ve been that most of Buttondown’s users and customers are extremely nice. I’ve had two people already say that they hoped I had a good vacation; I had one say that they were happy I hadn’t responded because it meant I was finally getting a break.
In light of the whole “you can’t measure what you don’t track” thing, I really want to write a small script around the Gmail API to track some customer service KPIs based on my daily email sending & response rates. This might become a self-defeating exercise — especially given that I don’t track anything right now particularly well — but I think it would be a revealing experiment!
This is a truncated work week — and I’ll have lots of other things going on outside of Buttondown as well — but my only two goals are to get Panoply out into the wild and to catch up on my inbox.
After that, though:
Is using a codename to refer to an internal thing, given the minuscule size and scope, insufferable and dumb? Definitely. But it’s also a little bit fun. ↩
“A hundred lines” is a really good size for a code change, even if its one that I don’t adhere to often in Buttondown. It’s easy, but non-trivial, to internalize and review a hundred lines of code; when changes get larger than that, they’re hard to review holistically, but when they get smaller than that, the friction of reviewing and approving changes feels prohibitively restrictive. As such, I try to make technical debt or bug fix changes as small as possible (or, ideally, self-reviewing, through tests) whereas I try and make design or feature changes around a hundred lines. ↩