The End of Software Built by Strangers

People who do not understand the work are still deciding the software everybody else has to use. The distance between knowing what must change and being able to change it is collapsing. The people closest to the work are about to inherit the tools.

As Fast As You Can Think and The Individual Contributor Age are about the cost of implementation falling. This is the next consequence. If a person who understands the work can now make the thing, why is a stranger still choosing it for them?

I have spent a career at the join of technology, strategy, and transformation. A reasonable buying decision becomes an unreasonable Tuesday with depressing regularity. The failure is often not the software. It is the distance between the person who chose it and the person who has to live in it.

We have been building software backwards

Watch how a system arrives in a large organisation.

Somebody names a problem. A case is written. Requirements are collected. Technology evaluates options. Vendors demo. Procurement negotiates. An executive approves. Months later a system lands, and the people who use it every day find that it does not quite understand what they do.

The workflow has too many steps. The words are wrong. The exception that happens every Tuesday is missing. A task that should take seconds needs three screens. So people adapt. Spreadsheets. Workarounds. An unofficial system running beside the expensive official one. Then somebody commissions another programme to repair the damage of the last one.

We gave the authority to choose software to the people who could buy it, not the people who understood how it should work.

For a long time that bargain had a logic. Software was expensive. Expertise was scarce. A central decision was how you kept the spend from exploding. Those economics are changing. The structure built on top of them has not.

The proxy tax

Take a customer service operator who has used the same CRM for five years. They know which field lies, which integration fails, and which customer needs a different path from everyone else. Ask what they would change and they will tell you in minutes. They may already have drawn it.

Until recently, turning that knowledge into a working application required somebody else. A product manager to interpret it. A designer to represent it. An engineer to implement it. A programme to decide it was worth the queue. Each step added delay. Each step added interpretation. Understanding became a description, then a specification of the description, then an implementation of the specification. By the time the software arrived, something essential had usually been lost.

Call that the proxy tax: the cost an organisation pays when the person who knows what should happen cannot shape the thing that makes it happen. It is not only money or engineering time. It is lost context, compromised decisions, and work that never reaches a roadmap because it is not large enough to fund.

The person who knows can finally make the thing

A domain expert can now describe a problem, get a working application, look at it, change it, and test it against their own Tuesday. Not on a quarterly release. Sometimes in an afternoon.

That does not make them an engineer. It does not give you secure architecture, careful data handling, accessibility, or a system you can own on a bad day. Outside the building, the same shift is already putting new people into the market, which is the argument of The Entrance Exam Is Gone. Inside the building, the point is sharper.

They no longer wait for someone else to decide their problem deserves a solution before they can try one. The first version is wrong. They change it. A colleague finds an exception. They put it in. A customer behaves differently than expected. They adjust the experience. The product gets closer to the domain because the person shaping it does not have to keep explaining the domain to a stranger.

The specification stops being a document passed between strangers. It becomes a working conversation between the expert and the thing they are making.

That is the part worth caring about. Not that a machine can write code. That knowledge can become a working capability without the chain of translation that used to separate the two.

A lot of software only existed because building was expensive

A surprising amount of enterprise software is there because a specialised alternative used to cost too much. Companies bought something approximate, then spent years bending people and process around the gap. The software was the fixed point. The business moved.

What happens when a team can make a more useful interface for its own workflow, and the cost of that is lower than the cost of accommodating the generic one? What happens when the organisation can compose the function it actually needs from services, APIs, data, and reusable capabilities?

Not every vendor disappears. Systems of record, transaction engines, infrastructure, regulated platforms, and shared services still need serious engineering. A great deal of software sits above that foundation. Interfaces. Dashboards. Workflows. Reports. Approval journeys. Admin layers. Products whose main advantage was that somebody else had already paid to build them.

When software is easier to make, being the company that made it stops being a sufficient reason to buy it. The question for a vendor is no longer only whether the feature list is complete. It is whether the experience is meaningfully better than what the customer can now make for themselves.

Stand beside the expert

The mistake from here is to hand everyone a coding tool, call them empowered, and leave. That wastes the moment.

The value of an experienced technologist does not vanish when implementation gets easier. It changes shape. I do not think the useful version of my job is a distant technology function, waiting for requirements to arrive. I want to stand beside the person who understands the domain. Challenge the assumption. Show what is possible. Design the architecture that makes the idea reliable. Coach the decision they have not met before. Sometimes build with them. Sometimes build the shared ground so they can build without me. Know when to speed an experiment up, and when to stop something dangerous from being deployed.

The aim is not to turn everyone into a professional developer. It is to put technical judgment in the room at the moment it matters, without taking authorship away from the person who understands the problem.

The technologist becomes a multiplier of domain expertise, not a gatekeeper to its execution. Done properly, the people you work with get more capable without you. That is a different model of transformation from the one that takes the problem away and returns with a system. It is also the practical case for a lab that sits with the work, which is what Automate is for.

The best product team may already be in the business

Every organisation already has the people. The campaign manager who knows where creative production actually breaks. The analyst who can see which number is lying. The operations lead who has memorised every exception. The person on the phone who can say exactly why the current experience fails the customer.

We have treated them as stakeholders, subject-matter experts, end users. People to interview before somebody else goes away and builds. For a growing class of software, that distinction is obsolete. They are not only a source of requirements. They are potential product creators.

Give them modern tools, trusted data, an engineering partner, access to the right systems, and permission to try. They can express what they know in working software, then challenge it, change it, and teach someone else to build on it. The organisation does not only acquire a tool. It keeps a capability with the people who do the work. A vendor implementation walks out of the building. This does not have to.

Centralise what must be dependable

None of this is an argument for dropping engineering standards. The opposite. As more people can create software, the foundation matters more. Identity, permissions, data contracts, observability, testing, accessibility, security, and an owner. Those cannot be improvised every time somebody has a good idea.

Not every application deserves the same scrutiny. A temporary internal dashboard is not a payments platform. A prototype is not a production system holding customer data. The craft is knowing the difference.

A central technology team still has an essential job. It stops being the owner of every decision about what gets built. It owns the ground that makes distributed creation safe. Shared capabilities. Reliable integrations. Reusable skills. Clear boundaries. A fast path from experiment to production. The things that stop every team from relearning the same lesson every week.

Centralise what must be dependable. Distribute what should be imaginative.

That is a more interesting ambition than handing everyone a chatbot and calling it transformation. Inside a large organisation, the other risk is using the new capacity to preserve the old structure, which is The Bureaucracy Is About to Become Autonomous. The foundation should make creation easier, not administer it back into a queue.

For decades, turning an idea into working technology belonged to people with the training, the budget, and the institutional door. Everyone else had to persuade them. That produced extraordinary things. It also meant people with exceptional knowledge spent careers inside tools they could not change. For too long, software happened to the people who use it. The people closest to the problem are finally getting their hands on the solution.

Related: The Individual Contributor Age, As Fast As You Can Think, and The Bureaucracy Is About to Become Autonomous.