The trick isn’t discipline. The trick is picking a small enough problem that discipline isn’t required.
Scope first, everything else second
Every side project fails at the scope step, not the execution step. If it feels like “a couple of months of evenings” when you start, it’s actually a couple of years and you’ll quit at month three. Cut the scope. Then cut it again.
The good version of a small project ships. The excellent version of an ambitious project sits in a ~/projects/incomplete/ folder forever.
Boring stack
Whatever you’re most fluent in. This is not the time to learn a new framework. If you’re doing it to learn a new framework, that’s fine — but then the project is “learn the framework,” not “build a thing.” Don’t try to do both.
Postgres for storage. A boring framework for the app. A boring deploy target. Every hour you spend on infrastructure is an hour you’re not spending on the actual thing you wanted to build.
Time-boxing that actually holds
A hard stop is better than a rule about “how many hours per week.” Sunday at 8pm, close the laptop. If the feature isn’t done, it isn’t done — pick it up next weekend. What breaks side projects is not slow progress; it’s the creep from “just one more hour” to “just one more weekend” until your other life is suffering.
Publish it before it’s ready
Not before it works — but before it’s polished. The polish absorbs infinite time, and until it’s public nobody can tell you which polish actually matters. Ship a v0.1 that does one thing, put it somewhere real, and let feedback tell you what to fix next.
Half the polish you were planning turns out to be for edge cases nobody hits. You couldn’t have known which half until it was live.
The graceful abandonment
Most side projects should be abandoned, and that’s fine. Two failed side projects that each took a weekend taught you more than one over-scoped project that took nine months and didn’t ship. The point is to be building things, not to have every thing you build become a success.