A funny thing happens in the cycle of building a company. First, you don't even bother documenting changes because the company is so half-baked and amorphous as is that there is no point, let alone people to read it. Then, as you grow larger and more capital S serious, you have a changelog or a blog collecting product updates that is still fairly haphazard, but at least serves the basic goal of keeping people informed. But then, as you grow increasingly serious, the importance of these changelog entries grows in weight and overhead. They suddenly need code snippets, OG images, copy passes, and need to be part of an overall schedule so as to maximize their efficacy and legibility to your growing customer base.

We're at that phase now, and it's a good phase. It forces us to think hard about why and how the most important things that we build get shipped and explained to you, dear reader. But the trade-off of doing that is a lack of legibility into all the smaller stuff: things that might have a customer impact but can't get communicated because they are too small to warrant the rigamarole of a blog post.

At the same time, we also started running into this internally. We're now at the phase of a company where we're shipping so much stuff that any one person doesn't have a full end-to-end understanding of what has changed in a given day. This too is a natural and healthy part of the process, and one thing that I've been doing to make sure my understanding is as strong as it can be is to begin every morning by writing down in plain English all of the Git commits that we merged from the previous day.

Anita had the great idea that we should simply turn this into a public page as well: and we have done just that. It is the changelog page reborn from the ashes. I hope you enjoy it.