Side Projects Should Start Boring

Side projects should help you build something useful. Too often, they turn into unpaid platform engineering. You start with a small idea:

• a tool
• a website
• a dashboard
• a small service
• something rough, useful, and moving

Then the stack starts growing.

You add:

• Kubernetes because it might need to scale
• queues because it might need async
• event streams because decoupling feels sensible
• CI pipelines
• deployment automation
• observability
• feature flags
• secrets management
• infrastructure-as-code
• staging environments
• dashboards

Each decision sounds reasonable on its own. That is the problem. Before long, the project looks serious. It has structure. It has tooling. It has deployment steps. It has a repo that feels like something from work. But the actual thing still does very little.

I have done this

I have spent more time designing the system around a side project than building the project itself. The architecture looked interesting. The tooling was defensible. The diagrams made sense. I could explain every choice. But the useful part stayed unfinished. That is what makes over-engineering so easy to fall into. It does not feel stupid while you are doing it.

It feels responsible.

You are thinking ahead. Reducing risk. Making the system cleaner, easier to run, easier to change. Those are good things in the right place. But most side projects are not in that place yet. There may not be:

• a future system to maintain
• users
• a second version
• enough evidence that the idea is worth more time

There is just an unfinished idea with too much machinery around it.

Movement is not progress

Tooling feels like progress because it looks like real engineering. It gives you something to configure, optimise, improve, and talk about. It creates movement. But movement is not progress. You can spend a whole evening improving deployment for an app that does not solve its main problem yet. You can tune infrastructure for users who do not exist. You can draw clean boundaries around code that has not proved it needs to survive. You can make the project impressive and still not make it useful.

Why side projects are vulnerable

Side projects are vulnerable to this because there is no pressure. No customer asking whether it works. No deadline forcing you to cut scope. No one asking why you spent three evenings on infrastructure before the first useful feature exists. So the work drifts towards whatever feels interesting. For engineers, that often means infrastructure.

The stack becomes the project. The original idea sits underneath it, half-built. A side project does not need to prove you understand every modern engineering pattern. It needs to move.

Engineering should fit the stage

This does not mean standards do not matter. It does not mean writing careless code or ignoring reliability. It means the engineering should fit the stage of the project. Most side projects are not platforms. They are experiments.

They need:

• a first version
• feedback
• proof that the idea is worth more time

Until that happens, too much architecture is often just a way to avoid finding out.

What I do now

Now I try to start boring. That usually means:

• one app
• one database
• simple deployment
• basic logs
• a README that explains how to run it
• enough automation to avoid obvious pain
• not enough automation to become the work

If a static site works, I use a static site. If a single service works, I use a single service. If a cron job works, I do not turn it into an event-driven workflow. If SQLite works, I do not start with a distributed database.

The first question should not be:

What is the best architecture for this?

It should be:

What is the smallest version that proves this is useful?

That question changes where your attention goes. Back to the thing itself.

Better questions

Before choosing more tooling, ask:

• What does this thing actually do?
• Who is it for?
• What problem does it solve?
• What is the first useful behaviour?
• What can be cut without losing the point?
• What would make this worth continuing?

Those questions are less fun than choosing a stack. They matter more. I want the first version running before I worry about scale, elegance, or long-term architecture. If the project becomes useful, it can earn more complexity later.

Complexity has to earn its place

Complexity should not be added because it is fashionable, interesting, or technically defensible. It should be added because the project has created a real need for it. Add a queue when synchronous work is causing real problems. Add better observability when you have failures you cannot understand. Add deployment automation when manual deployment becomes painful. Add structure when the code is hard to change. Add scale when there is something to scale. Not before. This is not anti-engineering. It is engineering with context. The hard part is not knowing how to build a more complex system. Most engineers can do that. The hard part is leaving the system simple long enough to prove the project deserves more.

The tradeoff

The first version may not scale. It may not use the newest tools. It may not be elegant. It may need rework. Some early decisions may be wrong. That is fine.

Rework on a working project is better than clean architecture around nothing. A simple first version gives you information. It tells you whether the idea works. It shows where the awkward parts are. It reveals the problems that matter. Not the problems you imagined before anything existed. An over-engineered first version often hides that information. It gives you plenty to do, but not enough to learn from.

The real cost

The real cost is not just wasted time. It is momentum. Side-project momentum is fragile. You are usually working around everything else:

• evenings
• weekends
• small pockets of energy

If the project becomes too heavy too early, it becomes easy to avoid. Opening the repo starts to feel like opening a work project. Too many moving parts. Too many services. Too many commands. Too much context to reload before you can do anything useful. So you stop. Not because the idea was bad.Because the machinery around it became bigger than the motivation to continue.

Takeaway

That is the real cost of over-engineering side projects. It turns small ideas into large obligations. Most side projects do not fail because the infrastructure was too simple. They fail because the useful part never got built.