Following the Spec vs Doing It Right: Where Developers Draw the Line

At some point in your career, you will run into this situation.

A client gives you a full set of designs or specifications. Everything looks defined. Layouts, flows, maybe even technical expectations.

But as you go through it, you start noticing things.

Some parts do not scale well.

Some flows feel inconsistent.

Some decisions will likely cause issues later.

Nothing is completely broken, but there are clear weak points.

So the question becomes:

Do you follow the spec exactly, or do you improve it during development?

The Reality: Specs Are Not Always Perfect

Most client-provided schematics are not built with full system awareness.

They might come from:

• Designers focused on UI
• Product owners focused on features
• Stakeholders focused on business goals

All valid perspectives, but not always aligned with:

• System performance
• Maintainability
• Scalability
• Edge cases

That is where developers start seeing gaps.

Blindly Following the Spec Has a Cost

If you strictly follow everything without question, a few things can happen.

You might ship something that:

• Works visually but breaks under load
• Is harder to maintain long-term
• Introduces avoidable technical debt
• Creates friction for future features

And when issues show up later, the responsibility does not disappear just because you followed instructions.

You were still part of building the system.

Improving Without Overstepping

On the other hand, going off-spec without communication is not the move either.

That creates a different set of problems:

• Misalignment with stakeholders
• Unexpected behavior from the client’s perspective
• Broken trust

So the real skill is not choosing one side.

It is knowing how to improve things without losing alignment.

What Professional Engineering Looks Like

From my perspective, improving the system is part of the job.

Not to impress anyone, and not to overcomplicate things, but because that is what engineering is.

If you see:

• A performance issue
• A flawed data flow
• A UX inconsistency that affects usability

Ignoring it just to “follow the plan” is not really professionalism.

At the same time, improvement should be intentional and communicated.

Something as simple as:

“I noticed this part might cause issues later. Here’s a small adjustment that keeps the intent but improves stability.”

That alone changes the dynamic.

Small Improvements Compound

You do not need to redesign everything.

Most of the time, the impact comes from small decisions:

• Adjusting API structure
• Fixing inconsistent naming
• Improving data handling
• Smoothing edge-case behavior

Individually, they seem minor.

Together, they shape the quality of the system.

It Is Not About Being Right

There is a difference between improving something and trying to prove a point.

Good developers:

• Suggest improvements clearly
• Respect constraints
• Stay aligned with goals

The goal is not to “win” the argument.

The goal is to build something better.

Balancing Ownership and Responsibility

This is where the role shifts from “coder” to “engineer.”

You are not just implementing instructions.

You are responsible for how the system behaves once it is live.

That means:

• Thinking ahead
• Questioning when necessary
• Improving where it makes sense

But always within context.

Final Thought

You do not have to choose between following the spec and improving it.

You can do both.

Follow the intent, respect the requirements, but do not ignore what you know as a developer.

Because in the end, professionalism is not just about delivering what was asked.

It is about delivering something that actually works well.

Author

Jose Albert Arnedo

Full-Stack Engineer focused on ERP systems and SaaS platforms