AI Makes Developers More Productive. Propel Makes the Organisation Better at Building Software.
Almost every AI tool in software today is aimed at the same target: making the implementer faster. Cursor, Codex, Claude Code, the whole category: they take the person or the agent writing the code and make them dramatically more productive. This is valuable, and we're not here to dispute it. But it's worth noticing what it is and isn't, because the distinction determines where the durable advantage in AI-native software lives.
Making the implementer faster is, in the end, a commodity. It's the same benefit for everyone, available to everyone, improving every month regardless of who you are. When your competitor has the same coding assistant you do, the productivity of the individual developer stops being an advantage and becomes table stakes. The real question — the one these tools don't touch — is whether the organisation around the implementer is any good at building software.
Two different jobs
There's a difference between making the person who builds faster and making the system that decides what to build, agrees on it, and verifies it work better. The first is about the implementation. The second is about everything surrounding the implementation, and that surrounding system is where most software succeeds or fails.
Consider what has to go right for a piece of software to be worth building, quite apart from how fast it's coded. Someone has to decide it's worth doing. The people who'll use it, pay for it, and be bound by it have to agree on what it is. Constraints have to be surfaced and respected. What gets built has to match what was agreed. And the knowledge of all of that has to survive so the next change doesn't start from zero. None of that is implementation. All of it is the system around the implementation, and a faster coding tool improves none of it. You can have the fastest developers in the world and still build the wrong thing, ship something nobody agreed to, and lose the knowledge the moment the team moves on.
What "the organisation" means depends on who you are
This is the same underlying idea whether you're a ten-person software house or a €40m enterprise. But the organisation it makes better looks different in each.
For an agency, the organisation is sales, the analyst, the project manager, the developer, and the client, all working from the same agreement. When those five are aligned on one live, shared understanding of what was scoped and agreed, the project makes money. When they're not — when sales promised one thing, the analyst understood another, and the client remembers a third — the project bleeds margin no matter how fast the code gets written. Making that whole chain work from one agreement is what protects the economics.
For an enterprise, the organisation is business, IT, architecture, security, legal, suppliers, and increasingly AI agents, all working from the same organisational knowledge. When those parties share one record of what was decided and why, the enterprise can build more of its own software while keeping control of it. When they don't, capacity turns into sprawl. Making that whole system work from one shared truth is what turns raw building capacity into a real advantage.
Different players, different economics, same principle: the value isn't in the implementer going faster. It's in the system around the implementer being coherent.
Why this is harder to copy
Here's why the distinction matters strategically and not just philosophically. Making the implementer faster is easy to replicate: it's a model and an interface, and the whole industry is racing to provide it. Making the organisation better at building software is not a feature you can bolt on. It requires holding the agreement, the decisions, the constraints, and the evidence as one connected thing across every party and every stage. That's a fundamentally different kind of system than a faster editor.
The AI coding tools make the person doing the implementation more productive. That's their job, and they're good at it. Ours is the harder, more durable one: the deciding, the agreeing, the verifying, the remembering. That is what separates an organisation that is good at building software from one that is merely fast at typing it, and no model release commoditises it.