Product & MVP

The Software Decisions That Cost the Most Are Made Before Any Code

The code is the cheap part. The choices upstream of it, what to build, for whom, on what foundation, are where projects are quietly won or lost.

5 min read23 Aug 2026

The Software Decisions That Cost the Most Are Made Before Any Code
The Software Decisions That Cost the Most Are Made Before Any Code
Reading Progress0%

Code is cheap now. Decisions aren't.

Ask a team why a software project went sideways and they'll point at the build. The framework, the bug, the integration that fought back. Look earlier and the real cause is almost always a decision made before the first line of code, back when it was cheap to change and nobody treated it as important.

Modern tooling and AI have made writing software faster and cheaper than it has ever been. That's shifted where the risk lives. When building is cheap, the expensive part is choosing what to build.

A team can now produce the wrong thing faster than ever. Which means the upstream decisions, not the execution, are what actually determine the outcome.

The four decisions that cost the most

Four early choices carry most of the weight. What problem you're actually solving, which is usually fuzzier than anyone admits. Who you're solving it for, precisely enough to say no to everyone else. What you're deliberately leaving out. And what foundation you're building on, the data model and architecture that are trivial to change in week one and brutal to change in month six.

Get these right and average execution still ships something good. Get them wrong and heroic execution just ships the wrong thing, well.

Why they're hard to reverse

These decisions are expensive precisely because they compound. A data model is a set of assumptions everything downstream comes to depend on. A target user shapes every feature that follows. By the time the cost of a wrong early call is obvious, months of work sit on top of it, and undoing it means undoing them too.

That's the trap. The cheapest moment to fix these is exactly when they feel least pressing.

The cheapest time to change the foundation is the moment it feels least urgent to.

How to slow down in the right place

The answer isn't to slow the whole project. It's to spend disproportionate care on the few decisions that are hard to reverse, and move fast on everything that's easy to change later.

Name the assumptions out loud. Write down what you're choosing not to do. Pressure-test the foundation before you pour anything on it. It looks like going slower at the start. It's the only thing that reliably makes the rest go faster.

Software rewards teams that are careful early and quick later, and punishes the reverse. The build will always feel like where the work is. The decisions before it are where the project is actually decided.