Buttondown's core application is a Django app, and a fairly long-lived one at that — it was, until recently, sporting around seven hundred migration files (five hundred of which were in emails, the "main" module of the app). An engineer pointed out that the majority of our five minute backend test suite was spent not even running the tests but just setting up the database and running all of these migrations in parallel. I had been procrastinating squashing migrations for a while; the last time I did so was around two years ago, when I was being careful to the point of agony by using the official squash tooling offered by Django. Django's official squashing mechanism is clever, but tends to fall down when you have cross-module dependencies, and I lost an entire afternoon to trying to massage things into a workable state. This time, I went with a different tactic: just delete the damn things and start over. (This is something that is inconsiderate if you have lots of folks working on the codebase or you're letting folks self-host the codebase; neither of these apply to us.) rm rf **/migrations/* worked well for speeding up the test suite, but it was insufficient for actually handling things in production. For this, I borrowed a snippet from django-zero-migrations (a library around essentially the same concept): from django.core.management import call_command from django.db.migrations.recorder import MigrationRecorder MigrationRecorder.Migration.objects.all().delete() call_command("migrate", fake=True) And voila. No fuss, no downtime. Deployments are faster; CI is much faster; the codebase is 24K lines lighter. There was no second shoe. If you were like me 24 hours ago, trying to find some vague permission from a stranger to do this the janky way: consider the permission granted. Just take a snapshot of your database beforehand just in case, and rimraf away.

Humane Inc. started in 2018; it raised around $250M over five years before coming out of stealth mode with an AI pin that people did not like very much, and today they announced their sale (or, to be specific, the sale of their patent library) to HP for $116M. Here is a hype video from July 2022, over a year before they ever announced — let alone released! — a product. I don't think we draw many interesting lessons from Humane. They feel like a relic from a younger, more Juicero-drenched era: even while they were in stealth mode there was an obvious perfume of vaporwave about them, and I think there's nothing inherently wrong with taking big, ambitious, VC-subsidized swings at gnarly problems that don't quite pan out. The two relatively novel things that come to mind are: "Huge amounts of capital" is a good way to finance infrastructure, and a poor way to finance design. [1] Any company that releases a $700 product for consumers and then neuters it with two-weeks' notice for non-existential reasons is, in a meaningful way, evil. At risk of veering into ad hominem, I think any company that releases a music video before it releases a product is obviously doomed — and one thing that a nigh-infinite runway tends to do is justify poor decisions under the auspices of long-termism. ↩︎

What a start to the year! January was a bit more flat-packed than I think Haley and I would have otherwise liked, but all with great things. (Highlights include: first weekend trip with Lucy, signing a lease on an office, and Third South's annual offsite.) A roundup of writing from the past month: A quick note on nominative determinism, and where Buttondown got its name Lots of media reviews: Catch Me If You Can, Book of Clouds, Becoming Trader Joe (!), We Own This City, Bringing up Bebe, Planes, Trains, and Automobiles, A small snippet on truncating timedeltas in the Django ORM Not as much fun writing in January than I had in the past few months; I promise my backlog of topics is longer than ever before.

Guillermo posted this recently: What you name your product matters more than people give it credit. It's your first and most universal UI to the world. Designing a good name requires multi-dimensional thinking and is full of edge cases, much like designing software. I first will give credit where credit is due: I spent the first few years thinking "vercel" was phonetically interchangable with "volcel" and therefore fairly irredeemable as a name, but I've since come around to the name a bit as being (and I do not mean this snarkily or negatively!) generically futuristic, like the name of an amoral corporation in a Philip K. Dick novel. A few folks ask every year where the name for Buttondown came from. The answer is unexciting: Its killer feature was Markdown support, so I was trying to find a useful way to play off of that. "Buttondown" evokes, at least for me, the scent and touch of a well-worn OCBD, and that kind of timeless bourgeois aesthetic was what I was going for with the general branding. It was, in retrospect, a good-but-not-great name with two flaws: It's a common term. Setting Google Alerts (et al) for "buttondown" meant a lot of menswear stuff and not a lot of email stuff. Because it's a common term, the .com was an expensive purchase (see Notes on buttondown.com for more on that). We will probably never change the name. It's hard for me to imagine the ROI on a total rebrand like that ever justifying its own cost, and I have a soft spot for it even after all of these years. But all of this is to say: I don't know of any projects that have failed or succeeded because of a name. I would just try to avoid any obvious issues, and follow Seth's advice from 2003.