A few weeks after Lucy was born, I was chatting with my brother-in-law, who has two kids aged four and two. I told him that I thought the furor about changing diapers was a bit overblown (no pun intended): it's not pleasant, but it's certainly not particularly difficult or onerous compared to all the other duties of dealing with a newborn.
His response has stuck with me, and now that Lucy is old enough and agile enough to reach out from under her and grab her own diaper (sometimes the clean one, sometimes the used one) it is newly fresh in my mind:
That's because right now it's a one-player game. Very very soon, it will become a two-player game.
Progress is easy to make when there is no counterparty; the reward of progress is a counterparty which, at times, seems as though its main goal is to thwart your advances in any direction.
In the before times, meaning not just before Lucy but before I was working on Buttondown full-time, a four-hour work block felt luxurious and vast. An entire feature could be built; whole swathes of surface area could be mapped and given flesh. And, in a certain way, this was true: the rate of change relative to the gestalt was much more rapid than it is now, even though now it is not just me but a whole team, all of whom I consider better and more productive writers and engineers than I am. This is not for any interesting or idiosyncratic reason: now we have to think harder about scale and performance, now we have to think harder about accessibility and localization, now we must be much more cautious and paranoid about security and reliability, now we have to answer twenty (valid, rational, and positive-value) emails before even getting to the greenfield.
There are ways of combating this, of course. An underrated method to keep your overall surface area small is to shift your biases towards disjoint surfaces: rssrsssrssrss, for instance, is the kind of thing that would have been an order of magnitude more difficult to build within Buttondown than it was to do outside of it. (I suspect that this will become increasingly true over time, as the collective industry matures.)
But one thing that is easy to take for granted — one thing that I really did not internalize until much later — is that there is a certain freedom in those first few halcyon periods of a codebase's life, when the streets are empty and the cost of breakage rounds down to zero. Success begets friction; every incremental user is a strip of papier-mâché.
(This is also, in lieu of a crisper ending, why I think the phrase "a startup within a larger company" is a scam; one cannot be so neatly separated from the other.)
