The Client Doesn’t Pay for Your Perfect Architecture

There are two major schools of thought among developers.

Those who talk about hexagonal architecture, clean code, elegant patterns, strict separation of concerns.
And those who ship.

I’m exaggerating on purpose. But the debate does exist.

And I’ll say it loud and clear: I’m a bad developer.
Five years at Epitech taught me to code, but I don’t enjoy it. So I’m not the best.
Still, I outperform most of your devs, because this weakness is my biggest asset for my clients.

The Myth of Perfect Code

We’ve all come across this profile:

• 14 layers of abstraction,
• 12 interfaces for a single implementation,
• a “future-proof” architecture,
• zero visible features for the client.

Technically, it’s impressive.
Conceptually, it’s clean.

But meanwhile, the client is still waiting for the button to work.

The client doesn’t see:

• your refined dependency injection,
• your well-placed design patterns,
• your exemplary variable names.

They see:

“Does it work?”

On the Other Hand: the Cowboy Coder

Then there’s the other profile.

The one who writes fast.
Sometimes dirty.
Sometimes redundant.
But functional.

The product ships.
The client is happy.
The business moves forward.

And often, it’s that code that brings in the money.

The Truth Lies in Between

Saying that only the result matters would be wrong.
Technical debt exists. It’s real. It costs a lot.

But hiding behind “the perfect architecture” to delay delivery is also a form of avoidance.

The Pareto principle (which I’ve loved since my teens) is useful here:

20% of well-placed effort produces 80% of the value.

The extra 80% of effort to make the code “academically pure” doesn’t always produce 80% of additional value.

Sometimes, it produces 5% of intellectual comfort.

What the Client Really Buys

A client doesn’t buy:

• a pattern,
• an elegant structure,
• a well-organized repository.

They buy:

• a solution to a problem,
• time savings,
• cost reduction,
• a competitive advantage.

Architecture is a means.
Not an end.

But Be Careful: “Functional” Is Not an Excuse

The opposite argument is just as dangerous.

“It works” is not a sufficient argument if:

• nobody can maintain the code,
• every change breaks something else,
• scalability is impossible,
• refactoring becomes prohibitively expensive.

Throwaway code in production is a time bomb.

True maturity means knowing where to put the effort.

A Simple Rule

Before adding a layer of abstraction, ask yourself three questions:

1. Does this need really exist today?
2. Does it simplify future maintenance?
3. Will the client get measurable value from it?

If the answer is no to all three…
You may be coding for yourself, not for the product.

What I’ve Learned Over Time

A good developer is not the one who writes the most elegant code.

It’s the one who knows how to:

• ship fast when needed,
• structure when necessary,
• simplify instead of complicating,
• arbitrate between speed and cleanliness,
• and above all, stop the architectural masturbation.

Perfect code doesn’t exist.
Useful code does.

And in a project:

usefulness must always come before technical ego.

Stop reinventing the wheel.

And for God’s sake, stop reinventing the axe that will chop the wood to reinvent that goddamn wheel.

Churn out code that works, not code that shines.