Overengineering and the Lost Art of Common Sense

05 Jan, 2026

There is a spectrum in software.

On one end you have Pieter Levels shipping real businesses with everything in a single index.php. On the other end you have teams building dozens of microservices, or worse, hundreds of “serverless” Lambdas, for a product that has maybe 100 concurrent users on a good day.

And somewhere along the way, a lot of us forgot that the middle exists.

For most of my career I felt this, but I rarely said it out loud.

Partly because I always had this quiet insecurity in the background. I never went to university. I do not have a fancy computer science degree. So when the room got excited about “proper architecture”, I swallowed my thoughts. I assumed I must be missing something. Or that one day someone will expose me as the guy who does not really belong here.

Classic imposter syndrome.

But I am getting close to 40 and I think I care less now. Not in a cynical way. More like, I finally trust my own experience.

So here it is, on record.

Most startups do not need an overengineered system.

Not “some”. Not “many”. Almost all of them.

Now, I am not saying microservices are bad. Serverless is not bad either. These are tools. Powerful ones. If you need them, use them.

But they should not be the default, especially early in a product’s life.

The problem is that a lot of teams adopt “Netflix architecture” before they have Netflix problems. They pay the cost of complexity upfront, and they do it in exchange for benefits they might never receive.

Because architecture has a cost.

Every extra service is another thing to deploy, monitor, secure, debug, version, document, test, and keep alive. Every boundary creates friction. Every abstraction adds distance between cause and effect.

At small scale, “distributed systems” often means “distributed confusion”.

And then there is the biggest myth of them all.

The idea that if you start super modular, everything will be easy later.

That your microservices will behave like Lego blocks.

That if the business pivots, you can just rearrange the blocks and keep building.

In real life, this is often a lie.

Tech debt accumulates in microservices too. Sometimes faster.

You still ship rushed decisions. You still cut corners. You still make assumptions under pressure. The only difference is that now those assumptions are spread across 20 repos, 40 deploy pipelines, and a web of contracts that you are scared to break.

And when the business changes direction, those “clean boundaries” are usually the first thing to fall apart.

Because pivots do not respect your architecture.

A pivot changes data models. It changes workflows. It changes what “a user” even means. It changes the shape of the product.

So the neat “lego blocks” you carefully built start fighting the new reality. Then you either glue them together with ugly hacks, or you rebuild them anyway.

Meanwhile, the product is still trying to find basic fit. The users do not care about your event bus. They care about whether the thing works, whether it is fast, whether it is reliable, and whether they can trust it.

There is a moment in a startup where you start believing you are building a spaceship, when you are still trying to get the wheels to stay on a bicycle.

I get why it happens.

Microservices, serverless, Kubernetes, clean architecture diagrams. They signal seriousness. They look like competence. They make you feel like you are doing things the “right” way.

And sometimes they also protect you socially.

It is hard to get criticized for following the current norm. If everyone is doing it, it must be correct.

But reality is more boring, and more useful.

Most products should start as a simple monolith. One deploy. One database. One place to look when things break. One codebase where you can refactor without negotiations between fifteen repositories.

Then, when the pain becomes real, you earn complexity.

Not because it is fashionable, but because it is necessary.

You can always split later when you have proof. Proof of traffic, proof of team size, proof of scaling constraints, proof that a boundary is paying for itself.

The common sense approach is not “everything in one PHP file”.

And it is not “a rabbit hole of AWS services”.

It is building the simplest thing that can grow, and only paying the price of complexity when you are forced to.

If this sounds obvious, that is exactly the point.

It is weird how often software culture drifts to extremes. Like we collectively forget that trade-offs exist, and that good engineering is usually boring.

So yes, I am saying it.

99% of startups will never need a microservice architecture.

They would be better off somewhere in the middle.

Maybe it is not a revolutionary take.

Maybe it is just what we used to call good judgment.