Building Is Getting Easier. Owning Still Matters.

AI is making it much easier to build things.

I’m increasingly convinced that means we need to get much better at owning things.

When producing software was expensive, the effort required to build it acted as a kind of accidental filter. Ideas had to clear quite a high bar before they became real systems.

That filter is disappearing.

I can now build something useful in a fraction of the time it would once have taken. Across an organisation, that creates a huge opportunity: more people can test ideas, solve local problems and learn by putting something real in front of users.

I don’t think the answer is to find new ways to stop them building.

The more interesting challenge is being clearer about when what they have built becomes something the organisation is prepared to own.

There is a big difference between permission to experiment and permission to operate.

An experiment can be bounded. Few people may use it. Failure may be acceptable. It can be switched off without consequence.

A service is different.

People begin to depend on it. Data matters. Security matters. Accessibility matters. Support matters. Resilience matters. Cost matters. Somebody needs to know what happens when it breaks, changes or needs to disappear.

Those obligations do not arrive because the code was difficult to write.

They arrive because the thing matters to somebody.

That suggests a different approach to governance.

Make experimentation easy within clear boundaries. Keep the blast radius small. Limit permissions and data. Make ownership explicit. Let people discover whether the idea is useful before asking them to prove that it deserves to exist forever.

Then have a clear threshold.

When an experiment starts becoming a service, the rules change.

That feels more proportionate than forcing every prototype through production-grade governance on day one. It also feels safer than allowing useful experiments to quietly become critical services without anybody noticing the transition.

Perhaps one consequence of making software abundant is that building becomes less of a commitment than owning.

The challenge isn’t to make building difficult again.

It’s to make the point at which we choose to depend on what we’ve built much clearer.