Simplicity Is a Weapon

Someone I respect once told me something I haven’t been able to shake. “Simplicity is a moat.” Four words. No qualifier, no footnote. He’d seen decades of enterprise systems — the kind of architectures that require a wall-sized diagram and a two-hour onboarding just to explain the deployment pipeline — and his conclusion wasn’t that they needed better tooling. It was that simplicity itself was the competitive advantage.

He was right. And the industry has been proving it ever since — by doing the exact opposite.

Look at what we’ve built. Leviathan AWS deployments with seventeen services talking to each other through a message bus that nobody fully understands. Microservice architectures where a single user action triggers a cascade across four repos, three teams, and two time zones. Dev/prod parity so broken that “works on my machine” isn’t a joke anymore — it’s a daily standup confession. We’ve built cathedrals of complexity and convinced ourselves the complexity was the point.

It wasn’t. It was the cost. And most teams can’t tell the difference.

Here’s the thing nobody wants to say out loud: complexity doesn’t signal intelligence. It signals inexperience. The engineers I’ve watched build for decades — the ones who’ve shipped things that actually survived contact with users at scale — they all converge on the same instinct. Simplify. Reduce. Cut the thing that feels clever but adds a deployment step. Kill the abstraction that exists because someone read a blog post about it, not because the system demanded it.

Occam’s razor isn’t just a philosophical principle. It’s an engineering law. The simplest architecture that solves the problem is almost always the right one. Not because simple is easy — simple is brutally hard. It requires the patience to resist premature abstraction and the experience to know which complexity is essential and which is theater.

Most complexity is theater.

The microservice revolution sold us a lie dressed up as best practice. “Services should be independently deployable.” Sure — in theory. In practice, you get a distributed monolith with all the coordination overhead and none of the coherence. You get teams that can’t make a cross-cutting change without filing tickets in three Jira boards. You get engineers who spend more time on infrastructure plumbing than on the actual product. That’s not architecture. That’s bureaucracy with a Kubernetes cluster.

Monorepo. One repo. Everything lives together — services, shared libraries, infrastructure config, the whole system in one place. Not because it’s trendy. Because it’s the only sane way to build when you actually care about shipping. One PR to make a cross-cutting change. One CI pipeline to reason about. One source of truth that every engineer — and every AI tool — can see in full.

And that AI angle matters more than most people realize. We’re entering an era where your AI assistant is only as good as the context you can feed it. A monorepo gives AI the full vertical slice — frontend to backend to infrastructure to tests — in a single context window. Multi-repo fragments that context across boundaries the AI can’t cross. You’re literally handicapping your most powerful tool because of an architectural decision you made three years ago based on a conference talk.

The teams that will move fastest in the next five years won’t be the ones with the most sophisticated infrastructure. They’ll be the ones with the simplest. Small teams, monorepos, boring tech stacks, AI tools that can see everything at once. Complexity is where startups go to die. Simplicity is where small teams become unfairly powerful.

When I have the choice, I build monorepos. Only monorepos. Anything I launch that needs to work, be traceable, simple to reason about, and fast to iterate on — one repo. Multiple services in a shared repo? Absolutely. But the moment you split the repo, you’ve split the context, the velocity, and the ability of anyone — human or AI — to hold the whole system in their head.

That’s not a preference. That’s a conviction earned from building things that had to survive.

The next time someone shows you a system diagram that looks like a circuit board and presents it with pride — ask them one question: could you rebuild this with half the pieces? If the answer is yes, the complexity isn’t a feature. It’s debt they’re calling architecture.

Simplicity isn’t the absence of capability. It’s the presence of clarity. And clarity — in a world drowning in accidental complexity — is the sharpest weapon you can carry.