Most startup-y advice doesn’t apply to Buttondown, mostly because, well, Buttondown isn’t a startup.
It’s roughly the shape of one, sure, and it’s matured to the point where I feel weird calling it a “side project” — but the closest thing to a canonical definition of a startup is a company optimized for growth and Buttondown is (or should be) optimized more on durability.
I tweeted a couple weeks ago about how another one of my projects, Spoonbill, has remained pretty much untouched for the better part of the past year — and it remains completely unscathed. That’s intentional! That’s by design.
Durability comes in many forms:
- The thing has to be cost-efficient enough (or bring in enough revenue) to run indefinitely. Spoonbill is completely free for users, but it only costs around $25/mo. in Heroku costs (and ~$5/mo in AWS) — I can live with a perpetual annuity of that size.
- It has to be, you know, stable. Minor bugs and edge cases are fine (there’s a weird thing Spoonbill has where if you haven’t confirmed your email with Twitter lots of things explode) but the core functionality needs to be resistant to pretty much everything.
- Speaking of which, the core functionality has to be there. An EC2 instance serving “Hello World” can last millenia (or at least the lifetime of EC2), but that’s not really worth much. There’s a lot of stuff I’d theoretically like to work on with Spoonbill, given enough time, but the core functionality it offers is implemented and stable.
- The thing has to be performant and scaleable enough that the natural accumulation of stuff (rows, users, tech debt, etc.) brought upon by time won’t require the proverbial rolling-up of sleeves.
Buttondown’s main chunks of functionality have been done for a while, and the accessory pieces that I have planned for the new year are nice-to-haves, not need-to-haves.
My rough prioritization framework looks something like this, given that I only have an hour or so every day to work on a project:
- Resolve any questions or concerns a customer has. (Nothing has been better in terms of generating goodwill and improving the codebase than treating customer service as sacrosanct.)
- If there’s a bug, fix it.
- If there’s a way to make an existing thing a little bit better (whether it’s polishing up an accessory view or finally clearing out a
TODO:comment or whatever), do that. - If I have a surplus of energy, start working on a new feature.
- Otherwise, I dunno, make a Manhattan and read some Ada Limón.
Things that this framework deprioritizes:
- New features
- Growth
- Marketing
- Tech debt (which is to say, new features and growth)
Which is fine! I think there needs to be a playbook to make things on the internet that last on the order of generations rather than years. I’m working on sussing out a plan to guarantee a promise that Buttondown will last forever in some form or another; in the meantime, the least I can do is make sure what exists is sturdier and more resistant to the weather of the world than it was a week ago.
And there are still bugs, sure — there were always still be bugs — but the big ones are gone, and the small ones keep getting smaller.
A shorter way of phrasing this entire thing: I’m starting to come around to the view that concrete is more impressive than glass.
Happy Sunday.
I hope you watched the end of that Vikings game, because, I mean, jeez. Wow.