The Pattern #11 -You're wasting time
Most smart people I know are optimising things that don’t matter yet.
I’ve noticed it everywhere.
Engineers debating architecture before users.
Creators polishing branding before distribution.
Founders perfecting pricing before demand.
Builders refactoring code nobody uses.
It’s a pattern I keep seeing.
People optimise before reality has pushed back.
Before users complain.
Before something breaks.
Before there’s friction, load, or demand.
Optimisation becomes the work — not because it’s needed, but because it’s safe.
Trust me, I fall for it too sometimes.
Why this happens
Early optimisation is especially tempting if you’re competent.
A few reasons why:
Optimisation feels like progress
It’s concrete. Bounded. You can “finish” it.Feedback is uncomfortable
Shipping invites judgment. Optimising delays it.Polish protects identity
If it’s not done yet, it can’t fail yet.You get to stay in control
Reality is messy. Optimisation happens on your terms.
It all looks productive. It feels responsible.
And most of the time, it’s a mistake.
Optimisation is often fear disguised as productivity.
A lesson I learned early on
Early in my career at a B2B startup, we were serving real customers with real expectations.
The product was live.
Money was coming in.
The system had to stay up.
We ran it on small servers.
No Kubernetes.
No clustering.
It worked.
It handled the load we had, shipped features quickly, and kept the business moving.
Around me, there was plenty of discussion about the “right” language and the architecture we’d need when this scales.
But that wasn’t today’s problem.
Today’s problem was revenue.
We hadn’t earned the right to optimise yet.
“Revenue is the strongest form of validation — and it rarely cares how modern your stack is.”
Competent engineers optimise for business survival first, technical elegance second.
Don’t take my word for it — history is full of companies that scaled despite their early tech choices, not because of them.
When optimisation does make sense
There isn’t anything wrong with optimisation.
I just have a problem with premature optimisation.
Optimisation makes sense when:
Something is being used
Something is breaking
Something is slow because of real demand
A constraint is proven, not imagined
In other words:
“Optimisation is a reward you earn after something survives contact with reality.”
A simple test
Before you optimise anything, ask:
Has anyone actually used this yet?
Has anything broken yet?
Am I fixing a real constraint or an imagined one?
Would shipping faster teach me more than refining longer?
If nothing hurts yet, optimisation is probably avoidance.
The Pattern to remember
Good engineers don’t start with the stack.
They start with the problem.
Whether you’re a founder or an engineer:
Build.
Ship.
Measure what hurts.
Optimise only what reality forces you to.
PS: If you haven’t checked out hudeyfajama.com - what are you even doing here?
Plugs
A collection of interesting links I’ve found from trawling the internet
Surah Hud - Qari Sheikh Abdul Muhsin Al Qasim
Cool Products - Cool website with cool products
OpenClaw/ClawdBot - you’ve probably already seen this
The Engineering Trap - why some guy left ChemEng