I’ve shipped technically excellent software that delivered zero value. The code worked perfectly. The product was doomed anyway.
And this is when I learned that the best code is the one we didn’t write.
It sounds like laziness. It isn’t.
It means: before you build, figure out if building is actually the answer. Most of the time it isn’t. Most of the time there’s an existing solution — a library, a SaaS tool, a boring off-the-shelf thing — that does 80% of what you need and costs nothing to maintain.
The teams that build the most are usually the ones in the most trouble. Every line of code is a liability. It needs to be understood, tested, maintained, migrated, and eventually deleted. In an early startup — three or four people, no dedicated PM, everyone wearing multiple hats — that debt accumulates fast. The more you write, the more you own. The more you own, the harder it is to move.
The instinct to build is strong in engineering cultures. Talented engineers see problems and want to solve them. That’s a feature at big scale. But when the scale is small, it becomes a bug.
A client once requested a very custom search — bespoke indexing, Elasticsearch, the works. We looked at the requirements and said: simplify the use case slightly and you can use Algolia. Simple. A few weeks. No custom indexing, no maintenance overhead. Twenty percent of the price.
They pushed for the custom solution. We didn’t have much say. After all, we were just contractors. So we built it.
The wiring was intricate, required indexes you couldn’t explain without diagrams. We spent months on it, the project went over budget, but the client was happy. For a while.
A few months later the requirements got slightly different again. Tiny things. They spent months trying to make the code fit. It worked, until the next tiny change. And a few changes later — they simplified the requirements — back to exactly where we’d told them to start.
They kept Elasticsearch. At that point… it could’ve been Algolia. Months and significant cash wasted, to end up where they could’ve started.
So now, every time someone asks me to build something my first reaction isn’t “how should we build this?”. It’s “Do we really need this? And if so — how can we simplify this?”. I ask the same question in interviews — which is what the last post was about.
Some people read that post and concluded I want engineers to be PMs. Well… no. I want them to ask questions before they start building. The PM isn’t the only one allowed to wonder if what we’re about to build is actually the right thing to build. I don’t think that one can build great software without understanding what needs to be built and why.
If you don’t ask, you’re building whatever you think is best, not what the product needs. So you’ll invent problems and then engineer solutions to them.
And if that is the case — then how are you better than LLMs?
