I like systems.
I like understanding how something works, finding the bottleneck, improving the process, and making a complicated thing clearer. This is probably why I am drawn to technology, automation, and building products in the first place.
But I have also learned that optimisation can become a trap.
The problem is not optimisation itself. The problem is doing it before you know what matters.
It is easy to optimise something that should not exist yet.
You can optimise a product before you understand the user. You can optimise a workflow before you understand the actual problem. You can optimise your schedule before you have decided what deserves your time. You can optimise a life around goals that no longer feel like your own.
The result can look productive while taking you further away from the truth.
This happens often in startups. People can spend weeks improving onboarding, pricing, conversion, branding, or growth systems before they have proven that the product solves a real problem. Everything becomes more polished, but nothing becomes more necessary.
The same thing happens with people.
We are surrounded by advice about how to become more efficient. Better routines. Better tools. Better calendars. Better habits. More output. More focus. More optimisation.
But efficiency is only useful when you are moving in a direction worth accelerating.
If you are climbing the wrong mountain, getting faster does not help.
Working with AI makes this even more obvious. AI can remove a huge amount of friction. It can make a small team operate with much more leverage. It can turn tasks that took hours into tasks that take minutes.
That is valuable.
But it also makes direction more important.
When execution becomes cheaper, the cost of choosing badly becomes more visible. You can build more things faster, which means you can waste more energy faster too. You can produce endless versions of something without ever asking whether the first version should have existed.
The question is not only: how can we do this better?
It is: why are we doing this at all?
I think good builders learn to delay optimisation until they have earned the right to optimise.
First, understand the problem.
Then, make something simple enough to test.
Then, pay attention to reality.
Only after that should you make it efficient, scalable, beautiful, or automatic.
This sequence sounds obvious, but it is difficult to follow because the early stages are messy. It is much more satisfying to improve something than to sit with uncertainty. Optimisation gives you a feeling of control. Discovery does not.
Discovery asks you to be wrong.
It asks you to talk to people instead of hiding behind a plan.
It asks you to make a version that might be embarrassing.
It asks you to accept that the most important variable may still be unknown.
But this is where the real work begins.
I want to build things that are useful, not merely efficient. I want to use technology to create more agency, not simply more output. I want to be careful that the systems I build do not become so polished that they stop asking the questions that made them necessary.
There is a time for optimisation.
It comes after attention.
It comes after reality.
It comes after you know what is worth making better.