I always have something running on the side. Not because I think every project needs to become a startup, but because building things is how I learn best. Reading documentation only gets you so far. Actually putting something into production teaches you the rest.
Over the years I have started a lot of side projects. Some are still running, some I shut down, some never made it past the first weekend. Looking back, the ones that stuck had a few things in common.
It solves something I actually have
The projects that lasted are the ones where I was the first user. PingDock started because I wanted simple uptime monitoring without paying for a SaaS tool. PrintRadar exists because I needed to track 3D printer prices. When you use your own product, you know exactly what is missing and what does not matter.
Projects built around "this could be useful for someone" tend to lose momentum fast because there is no feedback loop.
The stack is boring
Every time I tried to use a side project as an excuse to learn three new technologies at once, the project died. Now I pick a stack I already know and maybe add one new thing. For most of my projects that means Laravel or Nuxt, MariaDB, and a VPS. Not exciting, but it ships.
It can run cheap
If a side project costs me 50 euros a month in infrastructure before it has a single user, I will eventually shut it down out of guilt. The best side projects run on shared infrastructure, need minimal resources, and can sit idle without costing anything meaningful.
Scope is small on purpose
I scope the first version to something I can build and deploy in a weekend. If the idea needs three months of work before it does anything useful, it is probably too big for a side project. Ship something small, see if it sticks, then grow it.