Why your next side project should be boring

The default mode for engineers picking a side project is "what's the most exciting thing I could build?" The answer is usually a half-finished framework, a half-finished SaaS, or a half-finished game. The reason these projects don't ship is rarely that the engineer ran out of skill. It's that they ran out of motivation, because the project they picked was too big and too speculative to keep returning to on a Sunday.

A boring side project is the opposite. It's a small problem you actually have, scoped to a weekend, written in the technology you already know. It doesn't need to be novel, marketable, or even interesting to anyone else. It needs to be finishable, and it needs to teach you something concrete in the process.

The teaching is the point. You don't actually learn architecture from a half-built ambitious app, because architecture lessons emerge from finishing — from seeing how decisions made on day one play out by day fifty. A boring project that ships gives you that arc compressed into a weekend. The fifth boring project teaches you more than the third half-finished ambitious one.

There's a second underrated benefit, which is that boring projects build your taste for production-readiness. Real software has logging, error handling, deployment pipelines, security headers, and someone's been-there-tried-that wisdom embedded in its boring parts. A side project that ships forces you to face all of that, in a low-stakes context. Most engineers' first encounter with production-shaped engineering happens on a critical work project, which is the worst possible place for it.

The selection rule we keep coming back to is: pick a problem you've personally hit in the last month. The motivation will sustain itself because you actually want the result. Build something that solves it for you, ship it where only you can use it, and call it done.

If you want a small list to choose from: a script that automates one annoying recurring task, a tiny dashboard that tracks one metric you care about, a Chrome extension that adjusts one site you visit every day, a CLI that wraps a command you keep typing wrong. None of these will impress anyone. All of them will ship.

The other rule is to not over-stack technologies. A boring project is not the place to learn three new things at once. Pick one new tool to use, at most, and use familiar tools for everything else. The point is to ship; new tools are friction.

The piece we'd recommend on this is a long meditation on engineering as a finishing skill rather than a starting skill. The catalog of tiny shipped projects at the end is the most useful part. Several of them will probably feel familiar — small problems you've also had — and that's the signal to copy the approach, not the project.