Nov. 16, 2025, 11:02 a.m.
From the upcoming blog post on our open-source funding:
This year, we’ve added two new open-source tools to our stack:
Has become essential for managing our development environments and tool versions across the team. It’s replaced a hodgepodge of version managers and made onboarding new developers significantly smoother. | |
A terrific new linter and formatter for our codebase. |
We’ve started to contract our overall supply chain, and with that we’re phasing out some of the services we use—not because they aren’t high-quality, but because we want fewer moving parts. These are:
ESLint | Deprecated in our stack | |
HAProxy | Removed as an external proxy | Vercel’s built-in proxy |
Keystatic | Removed for content/metadata management | Custom lightweight TypeScript schema |
Just | Phasing out as a task runner | |
RQ | Gradually being replaced for job queuing | Our own Postgres-based job runner |
In general, this shift toward contraction feels pretty good.
Something I’m actively mulling—but haven’t decided—is whether to unify the docs and marketing sites into a single site. This is not that complex of a maneuver. Despite having different design languages, they’re fundamentally the same codebase. They sit on top of Next, use Keystatic and Tailwind, and both deploy to Vercel. They’re very, very similar, so combining them would be relatively low-lift from an engineering perspective. Redirects and similar housekeeping would be annoying, of course.
The benefits all seem minor but legitimate: one fewer codebase in the monorepo, one fewer deploy target, one fewer batch of dependencies to keep updated, and so on.
Second, it lets us more easily link between the marketing and docs material, especially as the distinction between the two gets blurrier.
Third, there are abstract SEO benefits, though they seem fairly marginal. When I squint at this, it looks like a non-trivial engineering effort with real downside risk to achieve definite but marginal improvements—so not exactly a compelling case.
Still, it feels correct, and often that sense of correctness outweighs everything else, even if it doesn’t speak to priority.
Had a good conversation with Nick and a couple others about how we communicate feature changes.
The current situation:
We’re pretty disciplined about publishing changelog entries for every non-trivial public-facing change. Good habit.
Those entries don’t garner a huge amount of readership. This is fine—they're not meant to be top-of-funnel—but it does suggest we’re not doing enough to educate existing happy users about all the lovely things we’re building.
Our monthly email, with its massive engagement, always includes one especially important changelog entry, and that gets lots of positive feedback.
All of this is prelude to the impasse: we want to tell people about changes without drowning them in volume. We publish ~2 changelog entries a week. The monthly email works because the signal-to-noise ratio is so good; if we repurposed it for ad-hoc or even weekly sends, we’d kill the golden goose. In-app education is another option—we already surface some changelog content on the homepage via RSS—but engagement there is “fine” in the same unremarkable way.
People really like periodic batching, so we’re going to try an Airbnb-esque year-end blog post that’s more of a feature roll-up. If that goes well, maybe it becomes a quarterly thing and our main way of communicating new stuff, rather than trying to be pointillistic.
