There's a particular satisfaction that comes from finishing something small and releasing it into the world. Not every project needs to be an ecosystem. Not every idea needs to grow into a platform. Sometimes the most meaningful thing you can build is a tool that does one thing and does it well.

I've been thinking about this lately, partly because I've spent the last few years oscillating between projects of different scales. Big, ambitious things with roadmaps and stakeholders and quarterly goals. And small, quiet things — a script I wrote to automate something tedious, a tiny utility I open-sourced mostly for myself.

The big things taught me about systems, about collaboration, about the kind of patience required to move slowly and deliberately at scale. But the small things taught me something different.

The feedback loop

When you ship something small, you close the loop quickly. You have an idea on Monday, write it on Tuesday, publish it Wednesday, and by Thursday you know whether it was useful. This is not how large projects work. Large projects have long tails — months or years between intention and feedback.

Small projects are an antidote to that. They teach you to trust your instincts because you get to find out quickly if your instincts were right. And when they're wrong — which they often are — the cost is low. You course-correct and move on.

Shipping frequently is a skill. Like most skills, it atrophies without practice and sharpens with repetition.

This sounds obvious, but it took me longer than I'd like to admit to really internalize it. For a long time, I held onto small projects — polishing, second-guessing, adding just one more feature — until they either became something much larger or quietly disappeared into a folder I never opened again.

The permission slip

Part of what makes shipping small things difficult is a misplaced sense of what "done" means. We've absorbed a cultural idea that software should be complete, polished, scalable. That releasing something rough is somehow unprofessional.

But a command-line script doesn't need a README that would survive a code review at a FAANG company. A small web app doesn't need to handle a million concurrent users before it's worth sharing. The right amount of polish is the minimum needed for the current context.

Here's a rough heuristic I use now:

  • Does it do what I set out to do?
  • Would I be comfortable if someone I respect saw the code?
  • Is it more useful out in the world than it is sitting on my laptop?

If the answer to all three is yes, it's done enough to ship.

The compounding effect

There's a compounding quality to shipping regularly that I didn't anticipate. Each small thing builds something — not necessarily audience or reputation, though sometimes that too — but more importantly, it builds the habit and identity of being someone who finishes things.

That identity matters more than any individual project. It shapes how you approach the next idea, how seriously you take your own intentions, how you feel about the work itself.

I've started keeping a running list of things I've shipped — not for anyone else, just for myself. It's a short list. But it's growing.