First, my confession: I have a natural attraction to sophisticated things.
Elegant abstractions. Clever architectures. Seamless systems with enough moving parts that drawing the architecture diagram is a week-long activity. Products that make you wonder how the hell somebody built them. I love complexity.
This is an occupational hazard of being an engineer.
But, after 18 years of writing code, I have built enough things now to know that sophistication has no inherent value. None. A beautifully designed system that solves the wrong problem is worse than a crude one that solves the right problem – the crude one is at least useful. The only thing better than a beautifully designed system that solves the wrong problem is a sophisticated one that only partially works, but that's still just wasted time.
This sounds obvious. It isn't, believe me.
The engineering version is easiest to see
Engineers are particularly vulnerable to confusing technical difficulty with value; and, although my background is software, I imagine it's the same across disciplines.
You can build a service with Kubernetes, Kafka, event sourcing, CQRS, eight independently deployable microservices with blue-green deployments and sub-minute rollback, and a distributed tracing system sophisticated enough to fit right in with an airplane's "black box".
Or you can put the whole thing in one process, behind Postgres, hit deploy, and go home.
The first architecture may eventually be necessary, but it may also be complete bullshit. My experience has been it's often bullshit.
We have a tendency to look at complexity as evidence that something serious is happening. A system with twenty components feels more substantial than one with three. A difficult technical problem feels more worthy of our attention than a boring one.
It's so easy to forget (or even to never realise) that users cannot see your architecture diagram.
They do not care how many services answered their request. They do not care whether the recommendation came from an agentic Re-Act loop or a 40-line function with three if statements. They do not care whether your database is horizontally scalable across twelve regions if the page takes four seconds to load. They do not care whether your UI comprises 6 individual micro-frontends if they cannot find the information they need.
They only care that the thing works. More importantly, they care that it does something they actually wanted done. Everything else is irrelevant implementation detail.
I think that one sign of engineering maturity is becoming less impressed by machinery. Not unimpressed, because I do think one must retain a level of curiosity, for intellectual stimulation at least. And not because machinery is unimportant – I have spent most of my career building machinery. I enjoy machinery. I deliberately overengineered a Rebus game PWA that I built for my partner.
But because the machinery is subordinate to the outcome.
Sometimes the correct solution really is a complicated distributed system – SpaceX, as it is, cannot run off one monolith; and sometimes the ugly cron job is the correct solution – you're probably not at SpaceX complexity yet. The important question is never which one demonstrates more engineering ability? It is: what is the least complicated system that reliably produces the result we need at this time?
Everything beyond that needs to justify its existence.
AI is making this mistake fashionable again
AI has given us an entirely new vocabulary for making simple things sound complicated.
Agents. Multi-agent systems. Agent-orchestrated agentic swarms. Agent sandboxes. Memory. Planning. Reflection. Tool use. Computer use. Reasoning loops. Human-in-the-loop.
Some of this is genuinely important. Some of it is simply architecture gymnastics.
There are certainly workflows where an agent that can observe a system, reason about what it sees and choose actions is substantially more useful than traditional software.
There are also workflows where you know exactly what needs to happen.
In the second case, adding an agent may simply turn deterministic software into slower, more expensive and less predictable software. There's a reason why state machines were so revolutionary to software engineering.
I think this distinction will matter more as building sophisticated AI systems becomes easier. When everybody can build the impressive demo, the impressive demo stops being particularly impressive. Distribution, and retention, will increasingly become simultaneously more important and harder to crack.
The question becomes what survives contact with reality.
Does it save somebody three hours?
Does it make a decision-making easier, faster, more testable and defensible?
Does it let one person do work that previously required five?
Does it remove a bottleneck?
Do enough people care enough about the result to pay for it?
Those questions are much less glamorous. They are also the questions that have always truly mattered.
Products have the same disease
There is another version of this where we confuse the amount of product with the amount of value.
- Add a dashboard.
- Add analytics.
- Add collaboration.
- Extend to real-time collaboration.
- Add an AI assistant.
- Add automations.
- Litter the codebase with feature-flag gates.
- Add customisation. Ensure the 2-week old project includes cookie-persisted theme preferences with a Local Storage backup.
- Add seventeen settings because different users asked for seventeen slightly different behaviours.
Six months later the product can do everything except immediately and intuitively explain why somebody should buy it. I learned this afresh with Lucien AI.
I have increasingly come to believe that a good product is less about how much capability you can put into a box and more about how precisely you can aim that capability at something the customer truly cares about.
A feature nobody needs is costly. Somebody has to design it. Somebody has to build it. Somebody has to test it. Somebody has to document it. Somebody will eventually break it. Somebody else will have to understand it two years later while wondering why the heck it exists.
The user also has to mentally parse it.
Complexity propagates.
This is one reason products that feel almost too simple can be so powerful. The simplicity is sometimes evidence that somebody did the difficult work of deciding what did not need to exist. It's much easier to add another button or refactor a modal.
Business might be the most brutal version
Customers simply do not award points for effort. As an engineer, I agree this is rude of them, but apparently they did not get the memo.
You can spend two years developing some astonishing piece of technology and discover that the market values it at approximately zero dollars, give or take a few cents.
Another person can connect three existing services, put a decent interface in front of them, figure out pricing, and build a business worth millions.
In 2021 I and my 3 co-founders spent months building Steward (used to live at joinsteward.com) – a product that was supposed to facilitate endowments for East African schools and facilitate alumnus-alumnus communication and facilitate alumni-school communication and escrow funds and include a project management surface and a company-run scholarship fund. All of these as a freaking MVP! We successfully raised a serious, sizeable pre-seed and had a company retreat in Uganda. Everything from ideation to fundraising and retreat happened in three months. The business shut down not long after.
The engineer in me occasionally finds this offensive.
The capitalist in me thinks it is perfectly reasonable.
The entrepreneur in me wonders why it took so long to learn this lesson.
Value is not proportional to execution scope.
A restaurant is not more useful because its accounting software required a PhD thesis.
A hospital does not care that your scheduling algorithm is mathematically ingenious if patients still wait four hours.
A business buying solar power does not fundamentally want panels, batteries, inverters, monitoring hardware and financing infrastructure. It wants electricity.
A person ordering a medical test does not fundamentally want logistics software, pseudonymous identifiers, laboratory integrations and encrypted records. They want to know whether they are healthy, confidentially and reliably.
The machinery may be necessary to produce the outcome, but the machinery is not the outcome.
I've learned companies get into trouble when they fall in love with the machinery.
Sophistication should be earned
None of this is an argument for making crude things. It is an argument for making sophistication prove its usefulness.
Sometimes the simple solution stops working. Great. Now you've earned some complexity.
Your Postgres database cannot handle the load. Shard it.
Your monolith has become impossible for fifteen teams to work on. Split it.
Database reads are becoming user-blocking. Add a read replica.
The deterministic workflow genuinely cannot handle the variability of the problem. Give the model more agency.
Customers repeatedly need more control. Add the controls.
Complexity introduced in response to reality is very different from complexity introduced in anticipation of a problem that the business might not even survive long enough to encounter.
The former is engineering. The latter is theatre.
And I think this applies outside software too. A sophisticated business model is not automatically better than selling something people want at a profit. A sophisticated strategy is not automatically better than doing one useful thing exceptionally well. A verbose explanation is not automatically better than an accurate one that fits in two sentences.
The sophistication can be valuable. It is just never the source of the value by itself.
Useful is a much higher bar than impressive
Impressive is often easy to recognise. Useful requires context.
Useful to whom?
For what?
Compared with what alternative?
At what cost?
Under what constraint?
For how long?
Iron Man's arc reactor is sophisticated. So is a pencil. Put me in front of a blank sheet of paper and only one of them is useful.
I keep having to re-learn some version of this across engineering, products and business: the goal is not to build the most advanced thing you are capable of building.
The goal is to understand the problem well enough that you know how much sophistication it actually deserves.
Sometimes that will produce something technically extraordinary. Sometimes it will produce a spreadsheet. If the spreadsheet solves the problem better, use the spreadsheet.