Three years ago, a fintech startup called us desperate.
They had 8 weeks to launch their MVP before their Series A round. The previous team had spent 6 months building a “scalable architecture” with microservices, event sourcing, and a custom orchestrator.
The system didn’t work. Nobody understood how to debug it. Every change broke something unexpected.
We asked them: “How many users do you expect in the first year?"
"About 5,000,” they replied.
We threw everything away and rewrote it as a simple Rails monolith. We launched in 8 weeks.
Today they have 50,000 active users. Same code. No architecture changes.
The myth they sell us
There’s a toxic narrative in our industry that goes something like this:
“Serious systems are complex. If your architecture doesn’t have at least 15 services, 3 message queues, and a diagram that looks like the Tokyo subway map, you’re not doing real engineering.”
It’s a lie.
Complexity is not a sign of sophistication. It’s a sign that someone made rushed decisions, or worse, decisions to impress rather than solve.
The uncomfortable truth: Most technology projects don’t fail from lack of talent. They fail because someone decided complexity was inevitable.
It’s not.
A scene we’ve seen 100 times
A senior architect walks into a meeting room. Opens their laptop. Projects a diagram with 47 boxes, 83 arrows, and colors that don’t mean anything consistent.
”This is our architecture,” they say proudly.
We ask: “What problem does this solve that a monolith couldn’t solve?”
Uncomfortable silence.
”Well, it’s just that… eventually we’re going to need to scale…”
Eventually.
That word has killed more startups than any competitor.
Complexity has a real cost
We don’t talk enough about the hidden cost of complexity. It doesn’t show up in the initial budget, but you pay for it every day:
Onboarding: A new developer takes 3 months to make their first confident commit. In a simple system, it takes 3 days.
Debugging: A bug that would take 20 minutes to find in a monolith takes 6 hours when distributed across 8 services with inconsistent logs.
Velocity: Each new feature requires touching 5 different services, coordinating 3 teams, and updating 12 configurations. What should take 2 days takes 2 weeks.
Burnout: Your senior team spends more time fighting infrastructure fires than solving business problems. They leave after 18 months.
Each layer of complexity is a mortgage on your future velocity.
And like any mortgage, the interest compounds.
The questions you should ask yourself
If you want to know if your project has unnecessary complexity, ask yourself these questions:
Can you explain your architecture in 5 minutes to someone intelligent but unfamiliar with your domain?
If you need more than 5 minutes, or if your explanation includes more than 3 acronyms, you have a problem.
Can a new developer make a significant change on their first day?
We’re not talking about changing a color. We’re talking about adding an endpoint, modifying business logic, or fixing a real bug.
If the answer is “no, they first need to read 40 pages of documentation,” you have a problem.
Is deployment an event or a non-event?
If your team gets nervous before a deploy, if you need a “maintenance window,” if you have a 15-step runbook… you have a problem.
Do you need external documentation to understand the code?
Code should be self-explanatory. If you need a wiki, a Confluence, or a 500-line README to understand what a module does, your code isn’t clear.
The paradox of simplicity
Here’s the part nobody tells you in bootcamps:
Building something simple is harder than building something complex.
Anyone can add layers of abstraction. It’s easy. It’s tempting. It makes you feel smart.
Anyone can introduce a new framework because “it solves this specific problem we have.”
Anyone can create a 15-step process with approvals, gates, and checkpoints.
But reducing a system to its essence, eliminating everything non-essential, maintaining clarity under pressure, saying “no” to features that add complexity without proportional value…
That requires real seniority.
That requires courage.
A real example: The Basecamp case
Basecamp has millions of users. Their application handles thousands of requests per second.
Do you know how many services they have? One. A Rails monolith.
Do you know how many engineers they have? Less than 10.
How is this possible? Because every technical decision goes through a brutal filter:
“Does this make the system simpler or more complex?”
If the answer is “more complex,” the answer is no. Unless the value is so obvious there’s no debate.
They don’t have microservices. They don’t have Kubernetes. They don’t have a 20-person DevOps team.
They have a system that works, that’s predictable, and that any developer on the team can fully understand.
How to recover simplicity
If you’re already in a complex system (and let’s be honest, most of us are), how do you simplify it?
There’s no silver bullet, but there is a process:
1. Identify the core
What’s the one thing that really matters in your system? What’s the 20% of code that delivers 80% of the value?
Everything else is a candidate for elimination.
2. Remove layers
Every abstraction, every service, every library must justify its existence.
If you can’t explain in one sentence why it exists, it probably shouldn’t.
3. Consolidate decisions
Fewer options, more consistency.
Do you have 3 different ways of doing authentication? Choose one. Migrate everything.
Do you have 5 different libraries for making HTTP requests? Choose one.
Every inconsistent decision is cognitive complexity your team has to carry.
4. Measure the impact
Before adding something new, ask yourself:
“Does this make the system easier or harder to change?”
If the answer is “harder,” the benefit better be enormous.
Simplicity as a competitive advantage
Teams that master simplicity have an unfair advantage:
They deliver features 3x faster because they’re not fighting their own infrastructure.
They make fewer mistakes because there are fewer places where things can go wrong.
They scale better because adding capacity is obvious and predictable.
They attract better talent because senior engineers are tired of dealing with unnecessary complexity.
And they sleep better because deploys aren’t scary.
The courage to say “no”
Simplicity requires courage.
Courage to say “no” to the VP who wants microservices because they read an article on Medium.
Courage to say “no” to the architect who wants to introduce GraphQL because “it’s the future.”
Courage to say “no” to your own ego that wants to use that shiny new technology.
The question isn’t “can we do it?”
The question is “should we do it?”
And most of the time, the honest answer is no.
One last story
A few months ago, a CTO showed us their architecture. It was beautiful. Perfect diagrams. Cutting-edge technology. Everything distributed, everything scalable, everything “cloud-native.”
We asked: “How long does it take you to add a new field to a form?"
"About two weeks,” they replied. “We have to update the schema in the data service, modify the API gateway, update the frontend, sync the teams…”
Two weeks to add a field.
That’s not engineering. That’s bureaucracy disguised as architecture.
The uncomfortable conclusion
Complexity is not inevitable.
It’s a choice.
And like any choice, it has consequences.
Next time you’re tempted to add a new service, a new framework, a new process… ask yourself:
“Does this make the system simpler or more complex?”
If it’s more complex, it better be worth it.
Because simplicity is not a constraint.
It’s a competitive advantage.
And in a world where everyone competes to add more, the winners are those who have the courage to add less.