People misunderstand what “following industry standards” actually means.
It makes sense for stacks, security, architecture, deployment patterns, all of that exists for a reason.
But somewhere along the way, developers started applying the same rigidity to ideas.
A client explains what they actually need, and instead of exploring the possibility properly, we compare it against what every other app in that category already does.
A clinic asks for a form system.
Immediately the discussion becomes:
“Here’s how clinics usually handle forms.”
“Here’s the common workflow.”
“Here’s the standard approval process.”
And suddenly the project becomes another clone of existing software.
Every App Starts Looking the Same
But most of the time, we already have the tools to automate the exact thing they’re struggling with.
Why should a clinic manually process half their workflow if the system itself can:
- accept or reject requests,
- generate tokens,
- create queues,
- assign flow priority,
- automate updates,
and reduce operational work entirely?
This isn’t some impossible future-tech idea anymore.
We already have AI models, agents, automation pipelines, code generators, workflow engines the barrier is rarely capability now.
The real limitation is imagination mixed with fear.
"Safest to build"
A lot of project discussions quietly become:
“What is safest for us to build?” instead of: “What actually solves their problem best?”
And clients notice it.
Recently, a client genuinely doubted whether something was even possible because their previous developer had rejected almost half the ideas during planning itself. They were told it was “against industry standards.”
I almost laughed.
Not because every client idea is good, it isn’t.
Sometimes clients absolutely suggest things that would become bloated, unstable, or painful to maintain. That’s where experience matters. Good development is also knowing what to stop.
But rejecting ideas just because they don’t resemble existing products is different.
That’s not engineering discipline. Sometimes that’s just creative laziness hidden behind professional language.
The Real Job
The irony is that many developers today are not building from scratch anyway. Most are already extending systems, frameworks, APIs, templates, or existing architectures.
So if we’re already standing on abstractions built by others, why pretend flexibility is impossible?
The job is not to force every business into familiar software patterns.
The job is to understand what is realistically achievable, and push as close to that boundary as possible without turning the product into chaos.
That balance matters more than “industry standard” ever will.