frontend

Keeping Side Projects Small Enough to Finish

Thoughts from the intersection of code, craft, people, and progress.

How useful constraints turn an interesting idea into a completed project.

Side projects usually begin with one good idea and then acquire authentication, themes and a roadmap nobody requested. Keeping the scope deliberately small protects the interesting part and gives the project a realistic chance of becoming something other than a well-organised repository.

A side project should be allowed to be smaller, stranger and more personal than paid work. Its value is often the freedom to follow an idea without first proving it belongs on a roadmap.

What makes this interesting is not the fashionable part. It is the effect on the person doing the work after the initial excitement has worn off.

Optimise for the next decision

Engineering choices are rarely permanent, but they can make the next choice dramatically easier or harder. The useful question is not whether an approach is perfect. It is whether it leaves the team in a good position when reality changes.

I look for feedback loops, visible trade-offs and a cheap route back. Small releases expose assumptions while they are still affordable. Clear defaults reduce accidental variation. A little discipline early is usually kinder than a rescue project later.

The best technical decision often buys clarity before it buys capability.

Good engineering creates options. It solves today's problem without quietly charging tomorrow's team an unreasonable fee.

The details will change from project to project. The underlying habit of paying attention travels well.