My colleague recently noted that "Building is no longer the constraint. Judgment is." It's a compelling view of a world where AI and low-code tools have enabled on-demand software. For an agile startup or a tech-native scale-up, this is the new reality.

But for the rest of the business world, the banks, insurers, and service organisations, we see a very different story. For these organisations, building isn't a minor hurdle. It remains the bottleneck.

While the technical act of writing code may have become easier, the organisational act of delivering software is more complex.

Three different worlds

To understand the differences, we have to consider three distinct environments.

1. The agile frontier

Here, software is the heart of the business. Barriers to entry are low. The biggest risk is exactly what my colleague described: having poor judgment and building the wrong thing very quickly.

2. The institutional fortress

In sectors like banking or insurance, development isn't just slow. It's a gauntlet. Here, the bottleneck isn't a lack of tools. It's a wall of:

  • Governance hurdles: Months of RFI, RFP, and 100-page requirement documents before a single line of code is even considered.
  • The credibility gap: A reliance on "big name" consulting firms that deliver expensive strategy decks but leave before the actual solution is built.
  • The ERP trap: A belief that massive, rigid systems are "safe", even though any small change requires a small army of high-priced consultants.

The paradox: Faster tools, slower delivery

In highly regulated worlds, AI and low-code don't always lead to speed. Sometimes, they trigger a defensive reflex. For a non-technical executive with an accounting, finance, or law background, a tool that generates code "instantly" can feel like a security risk.

A lack of understanding and trust, especially regarding data privacy, can stall a project before it even starts. As a result, organisations get stuck documenting a problem for months, only to deliver a solution for a world that has already moved on.

3. The service business

These are the organisations running on multiple separate systems that don't talk to each other. Here, the bottleneck isn't just the cost. It's that leadership often doesn't realise that a solution is even possible.

The awareness gap: These businesses don't need "better judgment" on software features, nor are they necessarily over-regulated. They need to know that orchestration and automation can fix operational chaos without breaking the bank.

Bridging the divide

My colleague argues that advantage belongs to those who build with discipline. I agree, but discipline looks different in a "Fortress" or a "Service Business" than it does in a "Frontier".

Frontier
Discipline is judgment. Deciding what to build, and what not to build.

Fortress
Discipline is governance. Deciding how we allow things to be built, safely and quickly.

Service business
Discipline is awareness. Knowing what's possible, and where orchestration creates leverage.

If we don't bridge the gap between technical potential and bureaucratic reality, we aren't innovating. We're just creating faster ways to fill out the wrong forms.

Whether you can build in an hour or a year, clarity is the only way to survive. In the Frontier, you need discipline to stop from building the wrong thing fast. In the Fortress, you need discipline to simplify the process so you can build the right thing at all. In a Service business, you need to know what's possible.

What do you think? Is the "cost of building" truly dead, or are we just trading technical debt for "governance debt"?