Software Was Never a Solo Act

There is a story the software industry tells about itself, and it goes like this: somewhere, a brilliant individual sits down at a keyboard and, through sheer force of intellect, conjures a product into existence. The garage. The all-nighter. The 10x engineer. It is a story about software as a solo act.

It was never true. It was a flattering simplification of something much messier and much more human: a long chain of people agreeing, disagreeing, misunderstanding each other, and slowly converging on what should exist. The code was always just the last, most visible link in that chain. The real work — the work that actually determined whether the thing succeeded — happened in the space between people, before a single line was written.

We could get away with ignoring this for a long time, because writing the code was so expensive and so slow that it dominated everything. When the bottleneck is typing, you optimise typing. You hire better typists. You celebrate the people who type fastest and most cleverly. The coordination problem was real, but it hid behind the labour of construction.

AI removed the hiding place

Then generation got cheap. Almost free. An AI agent can now produce in an afternoon what used to take a team a quarter. And the moment the construction labour collapsed, the thing it had been hiding stood up in plain view: the hard part was never building it. The hard part was agreeing on what to build.

This is not a small reframing. It changes what software work fundamentally is. When a model can generate any feature you can specify, the quality of your software becomes almost entirely a function of the quality of your specification — and a specification is not a technical artifact. It is a social one. It is the record of what a group of people decided, together, was worth making. It is an agreement.

Enterprise software isn't built by developers. It's built by organisations.

Nowhere is the solo-act myth more obviously false than in the enterprise, and this is the part most of the industry still refuses to say out loud. A serious piece of enterprise software is not the output of a developer. It is the output of an organisation — business sponsors who fund it, architecture that shapes it, security that constrains it, legal that bounds it, procurement that approves the vendors, compliance that audits it, delivery that builds it, operations that runs it. Every one of them holds a piece of what the software is supposed to be. None of them holds all of it. The software exists only when they converge.

Consider a familiar situation — illustrative, but anyone who has shipped in a large organisation will recognise it. A feature is commissioned. The business sponsor wants it live for a deadline. Architecture wants it to fit a platform standard the sponsor has never heard of. Security has a requirement nobody surfaced until late. Each party is acting in good faith, and each is working from a slightly different idea of what "done" means. The feature gets built — quickly, cleanly, by an AI that did exactly as it was told. And then it's wrong, not technically, but organisationally: it satisfies one party's version of the agreement and violates another's. So it's revised, and built again, and revised again. The construction was never the problem. The organisation never actually agreed.

AI made the building near-instant. It did absolutely nothing to make those parties agree any faster. That asymmetry — instant construction, unchanged human convergence — is the defining condition of enterprise software now.

The work moved, it didn't disappear

It is fashionable to worry that AI removes the humans from software. It gets this backwards. AI doesn't remove the humans — it relocates them, out of the keystroke and into the agreement. The work that's left is more human, not less: deciding what's right, reconciling what different parts of the organisation each believe, capturing what was actually committed to. And it is collaborative by its nature, because an agreement only one person holds is not an agreement. It's an opinion. The convergence of many parties is the asset. The code is just its shadow.

Why this is the reason Propel exists

We started Propel from a single conviction: that as AI made building cheap, the ungoverned layer would not be the code — it would be the agreement behind the code. The thing no single party owned. The thing that lived in funding approvals and architecture reviews and a workshop everyone remembered slightly differently. The organisational decision that was never captured as a durable, shared, accountable object.

Propel exists to make that object real — to take the agreement, the canonical and versioned record of what all parties have committed to build, and treat it as the thing of value it always secretly was. Not a document that rots the moment it's written, but a system of record the entire delivery is held against.

Software was never a solo act. We just couldn't see the collaboration clearly while the construction was so loud. Now the construction is quiet, and what's left is the part that was always the point: organisations, agreeing on what should exist, and being accountable to that agreement. That's the work now. We built Propel for it.

What this means for the tools you already use

• Coding tools removed the construction bottleneck. Cursor, Claude Code, Codex and GitHub Copilot made writing the code cheap. None of them made the organisation agree.
• The remaining bottleneck is organisational. Business, engineering and legal deciding, together, what should exist.
• Spec-driven development is the industry’s name for moving that decision earlier. It is the right instinct; a spec only binds anything once someone has actually agreed to it.
• Propel is the system of record for that agreement. Versioned, signed, and the thing the delivery is held against — alongside your editor, not instead of it.