Your stack is not the bottleneck.

By Muhammad Umar·April 7, 2025·5 min read·Issue #2

Engineers love a stack decision. It is comfortable work. There are trade-offs to weigh, benchmarks to read, opinions to collect. It feels like the most important decision you will make.

It is rarely in the top five.

Every project I have seen go badly went badly for boring reasons. Unclear scope. A decision nobody made. Three weeks of building the wrong thing because a five-minute question went unasked.

What actually slows projects down

• Nobody can say in one sentence what the thing is for.
• The person who knows the answer is in a meeting until Thursday.
• Scope grows quietly, one "while you are in there" at a time.
• The work is done, but nobody owns getting it in front of users.

None of that is a technology problem. All of it is a communication problem wearing a technology costume.

What to do about each of them

It is easy to name those and leave them there, as though they were weather. They are not. Each has a small, unglamorous remedy, and the remedies are cheap enough that skipping them is a choice.

Nobody can say what it is for. Write one sentence: who it is for, what changes for them, and how you will know it worked. Send it to the person paying and wait for a reply. The sentence is not the point. The reply is. If it comes back edited, you just avoided building the wrong thing. If it comes back with a question you cannot answer, you have found the real gap.

The person who knows is unavailable until Thursday. Do not wait, and do not guess silently. Write down the assumption you are proceeding on, in a place they will see, and carry on. You will be wrong sometimes, but being wrong in writing on Monday is recoverable in a way that being wrong quietly for three days is not.

Scope grows one “while you are in there” at a time. Say yes to the request and no to the timeline in the same sentence. Not “we cannot do that”. Say “we can do that, and it moves the date to the ninth”. Almost every scope problem I have seen came from someone accepting work without repricing it, usually to avoid an awkward five seconds.

Nobody owns shipping it. Put a name and a date on the launch itself, as a task, in the same list as the work. Unowned final steps are how finished software sits in a branch for six weeks.

None of that requires authority, a process document, or anyone else to change how they work. That is deliberate. Remedies that need organisational buy-in do not get applied by the person who noticed the problem.

So how do you choose?

Pick boring tools you already know, and spend the saved energy on the parts that are genuinely hard.

My defaults have not changed much in years: TypeScript, Next.js, Postgres, whatever hosting deploys on a push. Not because they win every benchmark, but because I can move fast in them without thinking, and every hour I do not spend learning a new tool is an hour spent on the actual problem.

The best stack is the one that gets out of your way.

When this advice is wrong

There is one exception worth respecting: the decisions that are expensive to reverse. Your data model. Where your source of truth lives. Anything that touches money or auth. Slow down there. Everywhere else, choose in an afternoon and move on.

The other exception is the one nobody admits to. “Boring tools you already know” quietly becomes “the tools I knew in 2019”, and a stack you chose for speed turns into one you keep for comfort. The tell is when you find yourself building something the ecosystem now gives you for free. Choosing fast is not the same as never choosing again.

The test I use

If I am wrong about this, how much does it cost to change my mind? Cheap to reverse means decide now. Expensive to reverse means write it down, sleep on it, then decide.

That sounds like a platitude until you actually sort your decisions with it, at which point the list turns out to be lopsided. Almost everything is reversible. The handful of things that are not tend to share a property: something else comes to depend on them while you are not looking.

Read down that table and the pattern is clear enough to state as a rule: a decision is expensive to reverse in proportion to how many things outside your control depend on it. Your CSS framework has no dependents. Your URL scheme has every integrator who ever wrote against it, and they will not be recompiled because you changed your mind.

Which is why the advice is not really about caring less. It is about spending your care where reversal is impossible instead of where it is merely inconvenient.

The novelty budget

There is a second rule I would defend, and it constrains the first: one new thing per project.

Every unfamiliar tool costs you two things. The obvious one is learning time. The one that hurts is diagnostic ability. When something breaks in a stack you know, you have a short list of suspects and you work it. When two pieces are new, you cannot tell whether the bug is in your code, in the tool, or in your understanding of the tool, and the search space multiplies rather than adds.

So spend the budget deliberately. If the genuinely new thing is the problem domain, keep every tool boring. If the new thing is a technology you have decided is worth learning, pick a problem you already understand completely. Doing both at once is how a two-week project becomes a two-month one, and the postmortem always blames the technology when the real cause was spending the budget twice.

The takeaway

Nobody is going to ask what you built it with. They are going to ask whether it works, whether it shipped, and whether it solved the problem. Optimise for that.