Not everything should be automated
On judgment, automation, and knowing where to draw the line
I was talking to a colleague the other day about scale. More specifically, about its cost.
What do we lose as things become more efficient, more automated, more standardized?
As things scale, a lot of the ad-hoc decisions disappear, for better and for worse. Easier to manage, but harder to adapt. Less chaotic, more predictable. And while everyone is tired of chaos, it’s also where a lot of creativity, judgment, and entrepreneurship come from. When everything is optimized for efficiency, you start losing things that are harder to measure.
We see this in different ways all the time, across products we use and processes we interact with daily. A few examples that came up in our conversation:
Conversations about scale that turn into rigid buckets, instead of asking what actually needs judgment versus automation
Automation decisions being made far from where the real context lives
Edge cases slipping through the cracks because the system wasn’t designed to handle them
The cost of fixing automation when it’s set up wrong being higher than the cost of doing it manually in the first place
Processes designed to work for everyone, but that no longer feel owned by anyone.
So what is it then? Should we stop automating and making things sustainable? No, not that either.
When we scale decisions too early, we lose local judgment. When we standardize everything, we flatten important differences. And when we optimize for everyone, we often end up serving no one particularly well.
With this conversation, I realized how my mentality changed the same way over time without even putting into words: not everything needs to be uniform to be scalable.
Core flows should scale. Repetition should be automated.
But edges matter. Exceptions matter. Context matters.
Earlier in my product career, I used to look for one ultimate solution. One framework. One formula that would work for everything. Over time, I realized that this mindset misses a lot of important edges. Some things shouldn’t be fully formalized. Some things need room to be handled differently.
How do you decide what to standardize and what not to?
A good rule of thumb:
Standardize what removes unnecessary work.
Automate what’s repetitive, predictable, and doesn’t require judgment.
Automating the obvious
An example of automation done right is order tracking and status updates in food delivery apps.
Once an order is placed, the system automatically updates the user when the restaurant accepts it, when the courier is on the way, and when the order is nearby. These updates follow rules, happen in real time, and don’t require interpretation. Same with ETA calculations, route updates, and basic delivery notifications.
In these cases, automation works because the task is repetitive, predictable, and low-stakes. Users don’t expect a conversation or an explanation. They just want quick information.
Standardization gone too far
On the other hand, an example of over-standardization is how food delivery apps usually handle customer support.
When an order is late, missing items, or incorrectly prepared, customers are routed through predefined support flows. Refunds or credits are decided by rules rather than the specific situation. In edge cases, users feel stuck. The solution works fast for common problems, but breaks down when the issue doesn’t fit the template. It is efficient, but frustration comes from not being able to explain what actually happened.
These are exactly the moments where users expect judgment, and where rigid standardization feels most painful.
Trying to be everything
But be careful not to go too far the other way by focusing on edge cases too much and making the product overly flexible for everyone.
A well-known example of over-flexibility is Evernote. What started as a fast, simple place to capture notes gradually expanded to support many different use cases: tasks, documents, scanning, collaboration, templates, teams. In trying to be flexible enough for everyone, the product accumulated features that most users didn’t need. The result was a heavier product, where basic note-taking became slower and less obvious. The core job of the product, helping users remember everything, became buried under endless options meant to cover edge cases.
They tried to build a product that had something for everyone instead of focusing on a few core user profiles. Over time, many users left for simpler tools that did one thing well. And Evernote just stopped being the go-to choice.
Flexibility only works when the product doesn’t lose sight of what it’s for.
If standardizing something removes repetitive work while preserving judgment, it’s worth scaling.
If it saves time but removes human judgment and nuance, be careful.