Building small things on purpose

I have started more projects than I have finished. For a long time I treated that as a discipline problem, and I tried to solve it with better planning.

The real problem was scope. I was designing side projects as if they were products with a roadmap, a launch, and a growth plan. Most evenings, that is not the work you can actually do.

The pattern#

The usual sequence goes like this:

1. A problem is interesting.
2. The first version is defined generously, because it is easy to imagine the complete thing.
3. Two weeks pass. The interesting part is done, and the remaining work is accounts, onboarding, settings, and edge cases.
4. Motivation drops. The project becomes another folder.

The mistake is not ambition. It is building the support structure before knowing whether the core idea is worth supporting.

Smaller definition of done#

Basket changed this for me, partly by accident. The first version was defined narrowly: one household, one shared list, claim an item, check it off. No accounts, no sharing links, no settings beyond a name.

That version was finishable. More importantly, it was usable, which produced a different kind of feedback than imagining users.

A narrow definition of done has a second effect: it makes the next decision obvious. After the core works, you know whether the offline behavior is the next real problem or whether the idea was already good enough.

Constraints are part of the design#

Running services on a Raspberry Pi is a useful exercise for the same reason. The hardware is slow, the memory is finite, and everything you add has a visible cost. You cannot add a dependency casually.

That pressure is missing from most software projects. Cloud resources are elastic, so the cost of a careless decision is deferred. On a Pi, it arrives immediately, usually as a service that stops responding.

The constraint does not make the software better by itself. It makes the trade-offs visible, which is the part that helps.

Finishing is a skill#

Finishing a small project is not a lesser version of finishing a large one. It requires a different discipline: deciding what is out of scope, resisting the urge to fix something adjacent, and accepting that the result is good enough to be used.

The benefit is not the artifact. It is the feedback. A finished small thing tells you something a plan cannot.

What I keep#

Three rules I try to apply now:

• Define the first version in terms of a single person using it once.
• Write down what is explicitly not included, and mean it.
• Keep the support structure (accounts, billing, settings) until there is evidence it is needed.

They are not profound. They are the difference between a folder of ideas and a set of things that exist.