Write a Definition of Done Before You Start

Most side projects do not fail. They simply never end, which looks identical from the outside and feels worse from the inside.

A project without a finish line expands

If done is undefined, every new feature is equally justifiable. Auth seems necessary. Then a settings page. Then dark mode. None of it is wrong, because there is no standard against which it could be wrong.

This is scope creep, and on a solo project there is nobody to push back. You are the product manager, and the product manager is the same person who wants to build the fun part.

One sentence, written first

Before the first commit, write a single sentence describing what done looks like. Not a roadmap. Not a list. One sentence you could show someone who would then be able to tell you whether you are finished.

• Weak: a good habit tracker.
• Strong: I can log a habit from my phone and see a 30 day grid, deployed and used by me for a week.
• Weak: learn Rust.
• Strong: a CLI that renames files from a regex, installable with cargo install.

The strong versions are testable. You can hold the project up against them and get a yes or a no. That is the only property that matters.

It has to be written before, not during

A definition written halfway through is just a description of what you already built. Written first, it is a constraint. The order is the whole trick.

This is the same idea as the acceptance criteria in agile software development, scaled down to one person and one sentence.

Make it a gate

In One Project OS a project cannot become active without one. The input is required server side, so there is no starting a project you have not defined. It pairs with the 14 day rule: two weeks of waiting, then one sentence, then you may begin.