Cheaper Software Means More Software: The Demand Argument

Every previous drop in the cost of building software increased the number of people building it. That's the strongest argument that this wave won't reduce engineering employment, and it deserves to be examined properly rather than deployed as reassurance.

The mechanism, stated plainly

When a good gets cheaper, consumption of it usually rises. Sometimes it rises enough that total spending on it increases despite the lower unit price — the pattern named after Jevons, who noticed that more efficient coal engines led to more coal being burned, not less.

For software specifically the mechanism is concrete. Every organization holds a queue of things that would be worth building at a lower price and aren't worth it now:

• The integration that would save the ops team six hours a week, quoted at three engineer-months.
• The internal tool everyone works around.
• The reporting that finance rebuilds by hand each quarter.
• The migration off a system everyone dislikes.
• All the products nobody attempted because the build cost exceeded the expected return.

That queue isn't hypothetical — you can go read yours. It's the accumulated set of things where value was real but less than cost. Lower the cost and some portion of it becomes worth doing.

Why it held before

Compilers removed the need to write assembly. High-level languages removed enormous categories of manual memory and control-flow work. Open-source libraries removed the need to build most infrastructure from scratch. Cloud removed the need for a team to run hardware.

Each of those was a large multiplier on individual output. Employment rose across all of them, because the set of things worth building expanded faster than the cost per thing fell.

→ The important detail: in each case, the expansion happened because there was unmet demand waiting. The mechanism isn't magic. It requires the queue to exist.

Where the argument is weaker than it sounds

Three honest caveats, none of which are usually mentioned when this argument is made.

Demand is bounded in some places. A company with a stable product, a fixed internal backlog, and no growth mandate has a queue that empties. The induced-demand story is about the economy in aggregate; it says nothing reassuring about a specific team whose backlog is finishable.

Redistribution is not the same as retention. Growth in total employment is compatible with substantial displacement — different people, different skills, different places, and the transition is not costless for whoever is on the wrong side of it. "The sector grew" is cold comfort to someone whose specific role went away.

Past patterns aren't guarantees. Previous automations removed steps within a process a human still directed. This one is aimed at larger portions of that direction. That may turn out to be a difference of degree — the previous transitions also felt qualitatively new at the time — or it may not. Anyone certain either way is over-claiming.

⚠️ The condition to actually watch

The argument stands or falls on whether the queue of unbuilt-but-valuable software is deep. Two observations that would suggest it is:

• Organizations continuing to fund new engineering initiatives as per-project cost drops, rather than banking the savings.
• The set of things being attempted broadening — smaller companies building custom software, more internal tooling, projects that previously never cleared the bar.

And what would suggest it isn't: cost per project falling while total engineering spend falls with it. That's the signature of a bounded queue, and it's observable in your own organization long before it shows up in any aggregate statistic.

What follows for an individual

The demand argument is a reason for cautious optimism about the aggregate and provides no protection at all for any particular role. Both halves are true simultaneously, which is why it gets misused in both directions.

✅ The practical read: expect more software to be built, expect it to be built differently, and expect the composition of who builds it to shift toward specification, verification, and judgment. Position for that shift regardless of whether the aggregate number goes up — because the aggregate isn't what pays you.

The takeaway

Cheaper building has historically meant more building, and the mechanism is real: every organization has a queue of things worth doing at a lower price. That's genuine grounds for expecting the sector to grow. It is not grounds for expecting your particular job to be untouched, because growth and displacement happen at the same time. Watch whether your own organization funds more as projects get cheaper — that local signal tells you more than any forecast.