When your customer can build it themselves: move the offer downstream

A&A perspective

When your customer’s own staff start building their own tools, the move is neither to cut your price nor to retreat into harder technology. It is to shift the step at which you sell one notch downstream. Three steps. First, split the work you currently take on into "finished once it is generated" and "picked up by someone after it is generated". Second, remove from the offer any item in the first group that even one person on the customer’s side could build. Third, reprice the second group — on both rate and term — around two things specifically: the work of saying the output is not wrong, and the work of restoring it when it breaks. That is this article’s answer.

A&A perspective

The reason for splitting this way is that in-house building takes a step, not a job. What the customer became able to do is generate. For the generated thing to carry real work, somebody still has to supply the grounds for calling its output correct, and somebody still has to put it back when it stops. And the volume of the second kind grows with the number of people inside the company who can build. So as in-house building spreads, the amount of work a service firm can sell does not shrink; the place where it can be sold moves. Discounting to stay at the same step means the price falls while nobody is standing where the volume went. What follows sets out the two accounts this reading rests on: one for the generation step moving into customers’ hands, one for what expanded instead inside a company that made generation fast. Connecting the two to the pricing of service work is our hypothesis; neither source states it. The sheet at the end turns that hypothesis into a decision.

A&A perspective

What a service firm should read here is not the elapsed time but who did the building. Fifteen minutes is a participant’s own account; it does not mean the same job takes fifteen minutes for anyone. What matters is that both an owner with no software background and an IT director who had long insisted he did not need AI built tools fitted to their own problems. Those two are exactly the people who, until recently, would have asked a small service firm for a quote. From the service side, then, the territory where quote requests stop arriving is starting to be defined not by technical difficulty but by whether the person who knows the problem best is standing nearby. Note that this article is Anthropic publishing an account of its own free workshop tour, attended by US businesses that signed up for it. It is not evidence about demand in the Japanese contracting market.

A&A perspective

This article is about software development inside one company, and it does not claim that the same ratios apply to service work. One structural point still carries. When generation got faster, the work did not disappear; it moved to the side that checks, selects and restores. What grew in that account was CI job volume and, with it, the number of test-selection and result-ingestion decisions the service had to make. The human headcount did not grow with it: the source says engineers were added only in nominal numbers, and the whole redesign took one engineer three weeks. What shrank was not time spent writing code but the degree to which writing code was the limit. On ownership the article says the opposite of growth — "ownership was murky. No one wanted to own another piece of infrastructure." Translated to service work, what grows after a customer can build their own tools is the work of deciding whether the output can be trusted and the work of putting things back when they stop. That translation is our hypothesis, not something the source states.

A&A perspective

None of those three is generation. They are a design in which new hires review every summary, a line drawn so that only a person presses send, and a redaction procedure plus a registry of every workflow. Each one decides who is responsible for what, and each needs a different skill from building. From the service side, none of them is done once, and each grows in volume as more people inside the customer start building. A registry decays in proportion to the number of builders; a checking design has to be rewritten every time the underlying work changes. So discounting to stay at the generation step is costly not because the going rate falls but because you are not standing where the volume is accumulating.

A&A perspective

To actually move the offer, list the tasks and answer two questions per line. The first: can one person on the customer’s side finish this alone? If yes, the line leaves the offer. Leaving the offer does not mean refusing the work; it means removing it from the quote and, where useful, keeping only a short session on how to build it. The second: if they cannot finish it alone, what is it sold as? Give it a broad name like "technical support" and the customer cannot tell it apart from what they can already build themselves, and you have no grounds for a price. The reason is specific to this kind of tool: when the same input can produce a different output twice, the customer cannot infer from the result which part of the work you did. A deterministic deliverable advertises its own scope; a generated one does not, so the name has to carry it. Name it so the deliverable is visible: acceptance criteria design, data-scope design, recovery scope, registry upkeep. The specificity of those names comes from the failure shapes in the sources above. An error of the form "a floor-area multiplier instead of real wall measurements on an early bid" is the kind of check nobody writes until an output has been wrong in a way the customer can price. Designing acceptance criteria therefore means putting into words how this customer loses money when the output is wrong — not operating anything. The registry row rests on the same kind of reading, but the step beyond the source is ours. What the source records is HireEffect building "PII redaction and a registry of every Claude workflow before rolling it out to staff" — a list compiled ahead of the rollout, not a catalogue of what staff later built. Our argument is the next step, and the source does not make it: once several people in a company can create workflows on their own, that list becomes something anyone may add to rather than a fixed set of procedures, and a list of that shape decays instead of holding. The decay is what you are paid to arrest.

A&A perspective

There are situations in which moving downstream is the wrong call. First, where nobody on the customer’s side builds at all. In the examples quoted above there was always at least one builder, whether the owner or the IT director. In an organisation without that person, the generation step itself remains sellable. Second, where regulation or internal policy does not permit in-house building. Third, where a builder exists but is fully occupied by their actual job. Move the offer downstream for a customer in any of those three and you are stepping off a step that still sells. A fourth caution comes from the same source: nearly two-thirds of attendees asked for hands-on implementation help after the workshop, which is demand for the build step itself, not for the downstream work. Reading that demand as transitional rather than durable is our assumption, not the source’s.

A&A perspective

Avoiding that error does not require judging the customer as a whole; it requires one question per engagement: can one person inside their organisation see this task through on their own time? If yes, it leaves the offer. If no, record the reason. The reason will be one of four: nobody builds, policy forbids it, nobody has the time, or they want to be taught to build it and will pay for that. The fourth is the one that does not end in a decline — it is the entrance described in the next section, and it only becomes revenue if the downstream product already exists. The third changes over time, so the same customer can give a different answer six months later. That is why the question belongs to the engagement rather than to the account. The split and the question set out here are a framework we propose, not a measured method.

A&A perspective

That fact carries two implications for a service firm. One is that the supply of teaching grows as generation gets easier; a room where one in five attendees already taught other small businesses suggests teaching itself is moving towards being hard to differentiate. The other is that the person you teach is also your prospective customer. Teach them how to build and they can carry the generation step themselves. Whether your revenue ends there or connects to a downstream product depends on whether the downstream product existed before you taught them. So workshops and guided sessions belong after the offer has moved, as its entrance, rather than in place of moving it. This is our reading; the source says nothing about the economics of teaching.

A&A perspective

The limits of the sources, stated plainly. Both articles are published by Anthropic about Anthropic, and neither is an independent audit. The tour report describes a self-selected group of US businesses that signed up for a free workshop. The "in about 15 minutes" and "in days rather than months" figures are participants’ own accounts, with no population or difficulty stated. The CI article observes software development inside one company and does not claim the same ratios hold in service work. The reading that "the constraint moves downstream", the split between territory that goes in-house and territory that does not, and the design of where to price downstream work are all frameworks we propose rather than measured methods. The strongest counter-evidence sits inside the same CI article: it reports that redesigning the downstream service itself took three weeks for one engineer where a year earlier it would have taken closer to a quarter. Faster generation can make the downstream work cheaper too. We have not shown why verification and recovery would not compress in the customer’s hands the same way the build step did; that it stays outside the customer is an assumption in this article, not a finding in either source. We present no engagement record or customer outcomes of our own.

A&A perspective

The next step is to take your three most recent engagements, write out the tasks line by line, and answer for each whether one person inside the customer could see it through on their own time. If more than half the lines come back yes, it is time to rewrite the names of your products. Carving out the first sellable unit is handled in our published piece "Choosing your first paid AI service: how a solo founder carves out one sellable unit of work". The customer-side build-or-buy judgement is handled in "Use existing tools or build a system of your own?". For the whole flow from acquisition to retention, "AI-native GTM: a practical guide for solo founders and small teams" is the map. If you cannot settle which downstream step becomes your product, that is a question for the advisory stage.