Your AI Customer Can Build It Now. Price the Work They Don’t Want to Own

The buyer across the table has a working prototype. Their team built it in a week, and it handles the happy path in your demo almost as well as your product does. They ask why they should pay you every month.

That is no longer an objection you can dismiss with “software isn’t your core business.” In a recent Hacker News discussion, one seller described customers leaning harder toward building, expecting more features, and showing less concern about maintaining what they build. It is one practitioner’s account, not a market survey. But it captures a question AI founders should be ready to answer.^[2]

The prototype changes the comparison

Traditional SaaS could often compete against the cost and delay of writing software from scratch. AI-assisted development makes the first version cheaper to produce, so the buyer’s comparison shifts. They are no longer asking, “Can we make this?” They are asking, “What would we still have to own if we made it?”

For an agent that processes supplier invoices, the answer extends well beyond extracting fields. Someone must manage permissions, detect duplicate payments, handle unfamiliar document formats, investigate failures, maintain an audit trail, and keep the workflow working when an upstream system changes. A prototype proves that the task is possible. It does not prove that the organization is willing to operate it.

That distinction is your pricing opportunity—but only if your product actually takes responsibility for those obligations. If it hands exceptions back to the customer without context, requires constant prompt tuning, or leaves reconciliation to finance staff, the customer is right to compare its price with the prototype.

Sell transferred responsibility, not exclusive capability

A credible commercial claim is narrower than “our AI is better.” It is: we will reliably run this bounded piece of work, and you can verify what happened. The customer can still build a version. Buying yours means they do not have to staff, monitor, and defend that version themselves.

This is why a feature checklist becomes less persuasive as building gets easier. The useful sales artifact is an operating agreement that makes responsibility visible:

• What counts as a completed, billable result?
• Which exceptions does the vendor resolve, and which return to the customer?
• What evidence can the customer inspect or export?
• What happens when the agent makes a mistake?

Those questions also expose where outcome pricing can go wrong. An invoice marked “processed” is not necessarily an invoice safely entered into the ledger. Define completion at the point where the buyer receives usable value, with explicit rules for reversals, duplicates, and disputed work. Otherwise you have renamed an output meter, not changed the bargain.

Put a ceiling on the buyer’s downside

TechCrunch’s Disrupt 2026 side-events schedule includes a session on moving from cost per token to value per outcome, spanning model routing, caching, reliability, pricing, and the connection between token spend and customer results. That combination matters: you cannot promise a stable commercial unit while ignoring the variable work required to deliver it.^[1]

Suppose you charge $1.50 per invoice that passes agreed validation and reaches the customer’s accounting system, with the supporting record attached. If inference, retries, and routine review average $0.45 per accepted invoice, the remaining $1.05 must cover support, product development, and profit. That is an illustrative unit calculation, not a target margin. More importantly, it gives the buyer a budgetable unit they can compare with the cost of running an internal workflow.

Do not silently absorb every pathological case, or charge the customer for unlimited unsuccessful attempts. Define an exception lane: perhaps invoices requiring policy judgment go to a separately priced review queue, while failures caused by your system are retried at your expense. The contract should tell the buyer which kind of event they are paying for before the first bill arrives.

Make the build alternative part of your sales process

Ask a prospective customer to show you the internal prototype, or describe the one they plan to make. Then help them estimate its ongoing ownership cost. Include the employee time spent handling exceptions, security and audit work, integrations, regression testing, and the consequences of an error—not just model calls or the developer’s first week.

This is not an invitation to inflate a spreadsheet until your quote wins. If the workflow is low-stakes, rarely changes, and already has a capable internal owner, building may be the better choice. Saying so gives your pricing a boundary. Your strongest customers are those for whom reliable operation is valuable but maintaining another internal system is not.

There is another reason to make this comparison explicit. In a separate Hacker News discussion, a commenter described conversations with organizations interested in running their own inference infrastructure because of concerns about token costs and control of data. That is an anecdote, not evidence of widespread migration. It is a reminder that buyers may treat infrastructure dependence as a cost even when your monthly fee looks attractive.^[5]

Keep the customer free to leave

If your economic case depends on trapping the buyer’s data, prompts, and workflow history, you have not solved the build-versus-buy problem. You have postponed it. Offer exportable records, clear data-retention terms, and a documented handoff path. Those features make the decision to buy safer because the customer knows they can revisit it.

The post-seat pricing opportunity is not to charge for everything an agent touches. It is to identify a unit of completed work, take responsibility for delivering it, and show the buyer both the result and the billable event. When a customer can build the prototype, the moat is no longer the ability to make software appear. It is the willingness—and demonstrated capacity—to keep a consequential workflow running.

References

2. The problem is not AI code, but not knowing about system architecture or intent | Hacker News — https://news.ycombinator.com/item?id=49880312
3. TechCrunch Disrupt 2026 Side Events schedule: NMI, Backblaze, PeakXV Partners, Augment, and more to host — https://techcrunch.com/2026/09/17/techcrunch-disrupt-2026-side-events-schedule-nmi-backblaze-peakxv-partners-augment-and-more-to-host
4. Sites in ChatGPT | Hacker News — https://news.ycombinator.com/item?id=49927747

Generated by AI · OpenAI · gpt-6-sol