Make your delivery process the product

Every line of code we write for a client belongs to the client. That is in the contract. What we keep is the framework the code was built with.

A year ago that would have looked like a services firm giving away its only asset. Today it is the business model.

In August I wrote that the delivery process, not the package, is the scalable software product of the next decade. That post stopped one step short. It did not say which part of the process is the product, what has to be true for a process to count as one, or where it ends up.

The product was always a ratio

SAP, Salesforce and Dynamics did not win by selling finished software. They sold a configurable core, and an industry of consultants did the fitting. On most large rollouts the fitting was the bigger invoice.

Nobody called them services firms. They were product companies, and the reason is simple. The core was sold thousands of times without being rebuilt. The fitting was redone for every client.

That is the test. The product is the part you sell repeatedly without rebuilding it. The service is everything you redo per client. Every software business is a ratio of the two, and the ratio decides what kind of business it is.

The ratio has flipped

Agentic coding has swapped which part is which.

The code is now the per-client part. It is generated against a spec, verified, handed over, and owned by the client. There is no reason to hold onto it, because holding onto it no longer gives you anything to sell twice.

The reusable core is the process. The last post showed where it lives. When a client’s summer intern shipped production code at senior velocity, the human work sat at two ends. Definition before the build, verification after it. Everything in between ran at agent speed.

Those two ends are the product. In the suit metaphor, the measuring and the fitting. The cutting is done by the machine, and Lovable, Replit and Claude Code already sell the machine.

Stage one, lift the process out of people’s heads

A process that lives in the heads of three consultants is a talent story. It becomes a product the moment it is encoded and can be carried into a codebase the people who wrote it have never seen.

Ours is encoded as a library of skills, sixty and counting, that loads into every agent session we run. Part built in-house, part adopted from third-party practice. They govern how the agents plan, tear down a spec, build a phase, test it, review it and ship it. The gates I have written about before, automated review, security scanning, generated test suites and pen testing on staging, are part of that library, not something a person remembers to run.

We found out it was a product when a US manufacturing software vendor asked us the question every prospective client asks. Given an approved specification, what workflow would you follow? The answer we gave was the process itself, slide by slide, and the first thing we proposed to build was not a feature. It was a skill encoding their design system and platform conventions, so anything we generated would feel like part of their product rather than a bolt-on.

The discovery work on their codebase ran at half the days we quoted. The quote was already about a quarter of what we would have estimated a year earlier. Calibrated estimating, which the last post described for build work, turns out to apply to a step that produces no code at all.

That engagement has since become an ongoing one. The founder is moving into a product owner seat, defining what the software should do, and from there we run the build. What he will own is the definition and the acceptance. What we own is the process that turns one into the other.

Stage two, the measuring end

That division of labour exposes the next constraint. Definition is now the slowest step in the whole cycle.

This is also how a service turns into a product, one step at a time. Every step that still needs one of our people is a service. Find it, build the tool that does it, and the ratio moves. The AI interviewer is the first of those tools, aimed at the slowest step we have.

A product owner knows what the software needs to do, but will not write a forty-page document. A vague brief produces plausible, wrong software, and an agent builds the wrong thing just as fast as the right one. We have watched this on every engagement since the code stopped being the bottleneck.

So we have specified, and are now building, an AI interviewer for the measuring end. It is a spoken conversation, and a natural one. Unless you are told, you would be hard pushed to know there is no person on the other end. We already run one for subject matter experts, and people who would never write a document will talk to it for hours. This one asks the questions a good analyst, designer and architect would ask, one at a time, and mocks up screens as it goes so the owner reacts to something concrete. It keeps going until every screen, flow, rule and failure path has been pinned down, but it does not make the owner carry that work. Where a sensible default exists it takes it, flags it, and moves on. It asks only where the answer has to come from the owner. The output is a spec a coding agent can plan from without asking the owner anything the interview should have caught.

Its own specification came out of the same method. I wrote a brief, the model interviewed me one question at a time until the intent was confirmed, and the spec was written from that. The process was applied to itself before a line of it was coded.

Where this ends

Follow the ratio to its conclusion and the shape of the next decade of software is clear.

A product owner talks to an AI interviewer. A full lifecycle runs behind it, specification, tear-down, phased build, gated verification, deployment. The result is deployed and maintained. When the business changes, the owner talks to the interviewer again, and the change is made against a spec that already exists rather than against a codebase nobody specified.

That is not what Replit is. Replit is built for developers, and its interface is the code. A product owner neither understands the code nor wants to see it. Lovable is closer, but it is flat. People build websites and simple web apps with it, and there is no lifecycle behind the preview. End-to-end business systems, the ones that run a factory floor or a buying desk, need the lifecycle baked in, because errors in business logic are silent and expensive. That space is open.

The objection

A process encoded in markdown files and a pipeline is still a consultancy with good templates. That is the argument I expect, and it is half right.

A consultancy sells hours. We sell the same process into every engagement, and hours are what the process consumes. The client-specific work, the skill for their design system, the interview for their spec, is the fitting. The library, the gates and the interviewer are sold again on the next engagement unchanged. The ratio is what makes it a product, not the file format.

There is a limit to the claim, and it is this. Only we have run this process. The encoded library is in use and has been sold. The AI interviewer is being built. The platform is where I think the industry ends up, and we cannot yet point at one. This week we put the process in front of a client with its own engineering team for the first time, to find out whether it raises their velocity without us in the room.

Build the product, then hand over the fitting

SAP, Salesforce and Dynamics followed a sequence. Build the core. Do the fitting yourself, on your own clients, until the market for it is proven. Then let partners do the fitting and sell the core to all of them.

That sequence applies here unchanged. Encode the process. Run it on your own engagements until the results are measured and repeatable. Then find every step that still needs your people, build the tool that replaces them, and let others run what is left.

The platform where a product owner is interviewed by an AI and receives a running, maintained system is what we are building towards. The encoded process is its first stage.

The code is the cheap part. Make the process the product.