Key takeaways
- The cost of building software has collapsed; the cost of deciding what to build has not.
- When execution is cheap, the expensive mistake is building the wrong thing well.
- Judgement, taste and problem selection are the scarce inputs — not implementation speed.
- The practical consequence: spend proportionally more on definition, and make the first build smaller.
For most of the history of software, the binding constraint was construction. Ideas were cheap and plentiful; turning one into working software was slow, expensive and uncertain. Every methodology we inherited — estimation, sprints, phased delivery, change control — exists to manage the risk of that construction step.
That constraint has moved. Not disappeared, but moved. Building the thing is now the fastest and most predictable part of the process, and the slowest part is deciding what the thing should be.
When building was expensive, the costly error was underestimating. You would commit to a number, discover the work was twice that, and spend the difference. Everything in a delivery process was designed to catch that.
When building is cheap, that error still exists but it hurts less. The expensive error is different: it is building the wrong thing efficiently. Shipping quickly, competently, and to specification — a product nobody wanted.
Speed is only an advantage if you are pointed in the right direction. Otherwise it is an efficient way to be wrong.
This is not a new observation. What is new is the ratio. When implementation took nine months, spending three weeks on problem selection felt proportionate. When implementation takes six weeks, three weeks of thinking looks like half the project — and gets cut first, precisely when it has become the most valuable part.
It is worth being specific about what got cheaper, because the change is not uniform. Writing code got dramatically cheaper. So did scaffolding, boilerplate, integration glue, tests, and the long tail of mechanical work that used to fill a schedule.
What did not get cheaper: understanding a business well enough to model it. Noticing that two stakeholders mean different things by the same word. Knowing which of the forty requested features are load-bearing. Deciding what to leave out. Judging whether a problem is painful enough that someone will change their behaviour to solve it.
Those are all judgement, and judgement has not been automated. It has been made more valuable, because everything around it got faster.
If you accept the argument, the consequence is mechanical: shift effort from the first build toward definition. Work out what to build before you build it, and treat that as a deliverable with a plan at the end of it. Make the first build smaller than feels comfortable, because its job is to answer a question. Agree in advance what would tell you to change course. And recognise that the riskiest assumption in most projects is commercial, not technical, so test it first.
None of this is novel advice. It is that the arithmetic behind it has changed enough that ignoring it has become considerably more expensive.
It also makes the work better. Less of a project is spent on mechanical implementation and more on the part that matters — sitting with someone, understanding what they are actually trying to do, and working out the smallest true version of it. That was always the good bit. It is now also the valuable bit.
It is also how we work. Every Rabblepop project opens with a scoping sprint that produces a written plan before any production build, and the first release is deliberately smaller than the idea that arrived. If you want to test the argument on something you are planning, that is where it starts.