Your Customer's Engineering Team Is Now Your Competitor

In 2021, running a model with GPT-3-level benchmark performance cost about $60 per million tokens. By late 2024, comparable performance was available for $0.06 per million tokens. Andreessen Horowitz put the thousand-fold drop on one chart in its “Welcome to LLMflation” analysis.

The obvious response is to cut prices. That may be necessary, but it misses the more dangerous change.

A cheaper model does not merely lower a vendor's cost of goods. It also lowers the cost of the customer's alternative. If an AI product consists mainly of a prompt, a model call, and a tidy interface, the buyer can now ask its own engineers to reproduce the useful part. The competing proposal may arrive from inside the company before procurement has finished comparing outside vendors.

This changes the software deal. A startup is no longer defending its price against another startup with a lower token bill. It is defending the whole purchase against a team that already has access to the company's systems, data, and people.

Cheap inference moves the build-versus-buy line

Traditional SaaS vendors won because they spread the cost of building and maintaining software across many customers. Buying a mature product usually cost less than creating an internal version, then staffing it forever.

Falling inference prices move that line for AI products whose model call does most of the work. The model still has to be evaluated, secured, monitored, and connected to real systems. Internal software is never free. But a sharp decline in one important input makes the first credible prototype cheaper, and modern model APIs reduce the specialist knowledge needed to produce it.

That is enough to change a renewal conversation.

Andreessen Horowitz's follow-up, “Surviving AI Price Wars Without Destroying Your Business”, describes the practical result: enterprise buyers tend to keep the AI products that become indispensable, rather than standardising on whichever vendor offers the cheapest model access. Low prices can win a trial, but they cannot make a shallow product expensive to replace.

The cost decline also appears durable. MIT FutureTech's research on algorithmic efficiency and inference costs attributes the trend to more than improving hardware. Better algorithms and techniques such as quantisation allow systems to deliver comparable capability with fewer computing resources. Vendors should plan around continued pressure on inference costs, not a temporary discount that disappears after the current price war.

Separate the cost of intelligence from the cost of a dependable product. Intelligence is getting cheaper. Dependability still requires integration work, permissions, evaluation, exception handling, audit trails, support, and accountability. A vendor that bundles those hard parts has a business. A vendor that resells intelligence with a nicer screen has a narrowing window in which to build one.

Pricing cannot rescue a replaceable product

Per-seat pricing looks increasingly awkward when an AI system can do more work without adding users. Charging for resolved tickets, reviewed contracts, or processed claims can fit the value delivered more closely. Consumption pricing and gainshare can also make adoption easier because the bill rises with use or measurable benefit.

None of these models creates defensibility by itself.

Outcome pricing works only when the vendor can define the outcome, measure it, and take responsibility for enough of the process to influence it. “Contract reviewed” sounds clean until the customer asks whether review means clauses extracted, risks flagged, a redline approved, or an agreement signed. If the vendor controls only the model response, it cannot credibly price the whole result.

The product has to reach further into the job.

For a legal workflow, that may mean document intake, clause policies, jurisdiction-specific rules, approval routing, version history, and an audit record. For an insurance claim, it may mean evidence collection, policy checks, fraud flags, human escalation, and a defensible record of every decision. A Slack bot and a generic connector do not supply this depth. Years of handling exceptions might.

Proprietary data can help, but the phrase is often used lazily. A pile of customer documents is not automatically a moat, and contractual or privacy limits may prevent a vendor from pooling them. The stronger asset is often a lawful feedback system: labelled corrections, domain evaluations, failure cases, and operating data that improve the product across repeated use. An internal team starts with rich knowledge of its own company. A specialist vendor can earn an advantage by learning across many deployments without exposing one customer's information to another.

That advantage has to survive a blunt question from the buyer: what would we lose if we rebuilt this ourselves?

A good answer names concrete assets and ongoing work. It might include a tested integration with a difficult system of record, an evaluation set covering rare failure modes, regulatory updates maintained by domain experts, or an operations team that owns exceptions at 2 a.m. “Our prompts are better” will age badly as models improve and inference gets cheaper.

Build for the renewal meeting

The next product review should include an internal-replacement test. Give a small team access to the same model APIs and ask what it could reproduce in six weeks. Do not handicap the exercise. Assume the team can see the customer's schemas, internal tools, and existing automation.

Whatever remains difficult is the product.

This test will usually expose two kinds of work. Some features are cheap demonstrations: summarisation, drafting, classification, and chat over a bounded set of documents. Other features carry operational weight: reliable actions across several systems, permissions that match real organisations, evaluation against domain-specific errors, approval paths, and recovery when the model fails.

The first group may still attract users, but it cannot support comfortable SaaS margins merely because it uses AI. The second group can justify a purchase because rebuilding it means taking on years of edge cases and continuing operational responsibility.

Cheaper inference is good news for builders. It allows more attempts, more background processing, and products that would have been uneconomic when every token mattered. It also removes the cost umbrella that protected weak applications. Both effects arrive together.

Watch model prices, but spend product time elsewhere. Instrument the workflow. Catalogue exceptions. Build evaluations from real failures. Take ownership of the steps before and after the model call. Price an outcome only when the product can carry enough of that outcome to deserve the fee.

At renewal, the decisive comparison will be the annual contract against the cost and risk of internal ownership. The vendor wins when the customer sees a working system it does not want to rebuild or operate. Cheap tokens alone cannot produce that answer.