The senior engineer's side-project trap

If you list the folders in my side-project directory you find about a dozen repos. Some are real products. Most are graveyards.

I am the trap I am writing about.

What I tell myself

Every side project starts with the same story. This is the one. The market is real. The stack is right. I have enough hours on a Saturday. I am 14 years into the career. I know which patterns work, which APIs to call, which databases to pick. I have all the parts.

For about three weeks the story is even true. The schema lands. The API ships. The SPA authenticates. The Postgres has row-level security and the BullMQ jobs run on a Redis I configured properly. It looks like progress.

Then I never write a marketing page. I never talk to a customer. I never decide who would actually buy this. The repo dies between branches.

Why it dies

The 14-year senior is rich in components and poor in product validation. The thing that’s hard about shipping a SaaS is not building Auth, Billing, multi-tenant data, queues, and observability. I can do those in my sleep and most of the time I do, in side projects, in my sleep, on Saturdays.

The thing that’s hard is finding a customer who will pay you and then doing the unfun work of keeping them happy. That work is invisible from inside the IDE. It does not look like a commit.

So I confuse “I have all the parts” with “I should ship it.” I do not. I have a really nice playground.

Reframing helped

The breakthrough for me was naming what side projects actually are. They are architecture playgrounds.

I learned NestJS in a side project. I learned Prisma migrations in another. I learned BullMQ vs RabbitMQ vs Postgres LISTEN/NOTIFY by running all three in different repos until I had opinions. I learned multi-tenant Postgres patterns by getting them wrong on a personal Saturday before getting them right at work on a Monday.

That work paid for itself. Not because the side project became a SaaS. Because the next Tech Lead conversation I had at $work was sharper. Because when a junior asked me about queues, I had a concrete answer, not a Wikipedia page. Because the architecture I shipped at $work used patterns I had practiced on my own time.

That payoff is real. It is not the founder fantasy. It is engineering compound interest.

What changed in my behaviour

Once I named it, two things changed.

I stopped pretending the playground was a product. No more landing pages on a domain I will never market. No more pricing pages on apps with zero users. The playground does not need a Stripe integration to teach me Stripe. I can read the Stripe docs. The signal that a side project should become a product is a user asking to pay me, not the SaaS template having a /pricing route.

I stopped feeling guilty for not shipping. A guitar player practising scales does not feel guilty for not headlining. They are practising. I am practising. The output of practice is not a record. It is the ability to play.

When a side project SHOULD become a product

There is a path to product, but it starts somewhere else. It starts with a problem you are personally annoyed by, in a market you understand, with one specific person who would write you a check. Not “B2B SaaS for HR.” A specific HR director at a specific company who told you the thing they hate.

I have only had one of those moments. The rest were architecture practice.

Take

Side projects compound your engineering. They rarely compound your career. Both can be true.