How I Structure a Side Project So It Actually Ships
I have started around thirty side projects and finished nine. The nine had nothing in common in subject or stack, and everything in common in shape.
Ari Bennett
Software engineer and writer
I have started roughly thirty side projects and finished nine. The nine had almost nothing in common in subject or stack. They had everything in common in shape.
Write the last screen first
Before any code, I write down what the finished thing looks like when somebody else uses it. One paragraph, present tense, no technology in it. "You paste a link, it tells you which of your pages point at it, and you can export the list."
If I cannot write that paragraph, the project is not a project yet, it is an interest. Interests are fine. They just should not get a folder on my machine.
Scope by what you can hold, not what you want
The projects I abandoned all died in the same place: about two weeks in, when the amount of unfinished structure exceeded what I could hold in my head between sessions. Side projects get worked on in ninety minute pieces separated by days. Anything that needs a long mental warm-up before you can be useful will lose to the warm-up.
So I keep a hard limit for the first version: one kind of thing, one screen that lists it, one screen that changes it. Everything else is version two, written on a list I do not open until version one is used by a real person.
The first hour rule
The first hour of a new project goes to the parts that otherwise become excuses later:
- It runs, and there is one page with real words on it.
- It stores something and reads it back.
- It is live somewhere with an address, however ugly.
An unpublished project is a hobby with a countdown on it. Once a real address exists, every session afterwards ends with something visible, and visible progress is the only fuel that survives a busy week.
Keep a session log
At the end of every working session I add three lines to a text file: what I did, what broke, and the exact next action. Not "continue on the export feature". Something like "add the header row in the export function, it is currently missing".
This one habit has done more for my finishing rate than any tool. Restarting is expensive, and the cost is almost entirely in remembering. A precise next action removes the remembering.
Decide what done means before you are tired
Done is not "no more ideas". Done is a written condition you set while you still had perspective: one real person can complete the paragraph you wrote at the start without asking you a question.
When you reach that, ship it, tell people, and then decide with clear eyes whether version two deserves your evenings.
Most side projects do not fail from a lack of skill. They fail because nobody wrote down the point at which they would be finished.
What I stopped building
I no longer build the settings screen, the theme switcher, the plugin system, or the abstraction that will make the second feature easier. Every one of those is a way of feeling productive while moving further from the paragraph.
The unglamorous truth is that finished projects are mostly made of restraint.
Written by
Ari Bennett
Software engineer and writer
I build web software for a living and write about the parts that are hard to search for: the trade-offs, the dead ends, and the small habits that make a codebase pleasant to come back to a year later. A decade in, I still keep a paper notebook next to the keyboard.
More about the writer
