Every good technical choice starts with an uncomfortable question: what are the real constraints? Until you answer that, any comparison is just theater. You end up copying a big tech company’s stack and inheriting its problems without inheriting either its scale or the team capable of handling them.
Cargo cult is expensive
Cargo cult is what happens when wooden airplanes appear because someone saw that real airports had runways. In technology, it’s the same thing: adopting Kubernetes, microservices, or that trendy NoSQL database because a famous company uses it, without asking why it uses it.
The problem isn’t the tool. It’s importing the solution without importing the problem. Netflix has concrete reasons for its architecture. You, with three developers and 200 users, probably don’t have the same ones. Copying the ritual won’t produce the result.
Start with constraints, not the menu
Most technical-choice discussions start in the wrong place: with the options. “React or Vue?”, “Postgres or Mongo?”. That’s like opening the menu before knowing whether you’re hungry, how much money you have, or whether you have any allergies.
Reverse the order. Write down the real constraints first:
- Team: what does the team already know? Is it easy to hire people who know X in your region?
- Timeline: can you learn something new right now, or is the deadline next week?
- Operations: who will maintain this at 3 a.m.?
- Data and SLA: what is the cost of losing or delaying a record?
With the constraints on the table, half the options eliminate themselves. The menu gets shorter, and that’s when the conversation becomes manageable.
Trade-offs are calculations, not opinions
No technology comes without a price. There’s the price you can see and the price that catches up with you later. The wrong choice isn’t the one with flaws; it’s the one whose flaws you discover too late.
For each finalist, write down what it costs you: learning curve, operating cost, ecosystem maturity, community size, and lock-in. An ugly table in a text file is already more valuable than an hour of debate in Slack, because it forces every opinion to become a comparable row.
And watch out for the shine bias: the new tool always seems to solve everything because you’ve only seen the demo, never production on a Friday afternoon.
Prefer boring and proven
When faced with a technical decision, bet on boring. Boring technology is technology that has already taken a beating: it has mature documentation, people in the market who know how to use it, and bugs that have been documented on Stack Overflow since 2018.
Postgres is boring. A well-organized monolith is boring. A simple queue is boring. And boring is a compliment here: it means predictable. You spend your innovation budget where it creates business advantage, instead of reinventing data persistence.
The practical rule: make no more than one or two bold bets per project. Everything else should be so unremarkable that nobody needs to think about it.
How much does it cost to go back?
The most overlooked factor in a decision is the cost of undoing it. Some choices are two-way doors—you enter, test them, and go back without lasting damage if you don’t like them. Others are one-way doors: once you cross, you’re stuck, and leaving costs months of migration work.
Switching charting libraries is a two-way door; decide quickly and don’t lose sleep over it. Choosing the primary database, the data model, or a cloud provider with its entire ecosystem coupled to it is a one-way door; that’s where measuring three times pays off.
The more irreversible the decision, the more rigor it deserves—and the more worthwhile it is to pay to keep an exit open, such as by using an abstraction layer or a portable data format. The more reversible it is, the cheaper it is to make the decision and move on.
Decide and write it down: the ADR
A decision that isn’t recorded doesn’t exist—it becomes an oral tradition that nobody remembers the reason for six months later. Write an ADR (Architecture Decision Record): a short file in the repository itself containing the context, the options considered, the decision, and the expected consequences.
It doesn’t need to be pretty. It needs to answer the question someone will ask in the future: “Why the hell did we choose this?” With an ADR, the answer is a commit, not a meeting.
Choosing well doesn’t mean always being right. It means deciding with clear constraints, documenting the trade-offs, weighing the cost of reversal, and leaving a record. That way, when the context changes—as it will—you review a decision instead of doing archaeology. Prefer boring, write down why, and keep building.