How AI apps earn their price premium: execution, context and proof of value

The article, published in the a16z newsletter and written by Tugce Erten, starts from a tension facing AI application companies. Falling inference costs can improve their margins, but more capable models and simpler development tools also make parts of an application easier to replace. The commercial question is what customers will keep paying for as their alternatives improve. According to the piece, exposure varies by product: an application is vulnerable when the customer can reproduce its core output with a general-purpose model and little ongoing effort.

The author argues that pricing always matters, but more so now, and that fast-growing startups sometimes put it off. She proposes that all of them build and price four capabilities she calls obvious but necessary: domain expertise, deep integrations, reliable execution and hard-to-obtain context. Founders must understand which advantages their customers actually value, strengthen them and charge for them.

As an example of the “build or buy” test, the piece recounts the case of Repsol’s legal team. In a blind evaluation, it compared Harvey with Microsoft Copilot and with its own in-house prototype, Lexia. According to the article, Harvey delivered the best quality and outperformed the alternatives on accuracy and time savings during an eight-week pilot with 50 lawyers across 12 jurisdictions. Repsol moved to a full rollout. Harvey says lawyers now save between four and six hours per week and that adoption reaches 96% of the legal department. The team also used the tool to identify recurring objections in past agreements and improve its templates with fallback clauses. One reader comment rightly notes that it is unclear whether those hours saved account for the time spent reviewing the tool’s edits. These are figures reported by the vendor itself.

Three rules are drawn from this and other cases: run the workflow better than the customer, make context cheaper to rent than to rebuild, and prove the value and then set a price that captures it.

First rule: run the workflow better than the customer. To weaken pricing power, a customer does not need to rebuild the entire application; it is enough to bring a high-volume task in-house or to have a credible alternative. A buyer at a global professional services firm explained that if a direct prompt to a frontier model produced a better result than a vendor’s tool, they saw no reason to pay the platform premium. That firm had built an internal AI platform capable of running models locally or on-premises when clients did not accept third-party products, and was experimenting with open source. To defend the premium, the vendor must beat the customer’s alternative across the entire workflow: in contract review, that means applying the company’s legal standards, keeping edits consistent throughout the document and preserving context as the negotiation evolves.

As an illustration, the article describes Harvey’s Playbook Review feature: a lead agent splits the review among specialized agents, reconciles conflicting edits and checks the finished document. Harvey evaluates performance with legal rubrics and chooses models by quality, speed and cost for each task. The system retains the review’s context so that later requests build on prior work. Harvey also describes the opportunity to learn from the changes lawyers accept, edit or reject, so that future reviews need less guidance. When that learning improves the next result, the advantage can compound with use. For founders, the recommendation is to compare their most exposed workflow with the customer’s best credible alternative, including implementation, human review, failures and maintenance, and to identify what improves with each use.

Second rule: make context cheaper to rent than to rebuild. Context can justify a premium through exclusive access, useful preparation, or both. Private observations the customer cannot get elsewhere have value of their own; for accessible information, the advantage depends on the cost of making it accurate, current and usable. A vertical software vendor the author spoke with had spent years accumulating proprietary pricing benchmarks from some 3,000 companies and was exploring offering them through a Model Context Protocol (MCP) server so that AI systems could query them directly. The economic logic is that the vendor collects, organizes, validates and maintains the information once and spreads the cost across many customers, who rent reliable context for less than it would cost to rebuild it. The same could apply to the customer’s own information (policies, CRM records, contracts, workflow history): it may be theirs, but preparing it for reliable use requires permissions, normalization, retrieval and ongoing validation. The recommendation is to identify whether the customer is paying for access, preparation or both, and to compare the price with the engineering, validation and maintenance effort it saves them.

Third rule: prove the value and then set the price to capture it. The article cites an a16z survey from August 2026 of 100 enterprise decision-makers on LLMs: 94% expected total LLM spending to rise, and 37% expected it at least to double over the next year. With more spending, customers need to see what they are getting: how much work gets done, at what quality and at what total cost compared with their alternatives.

The proposal is to start from a unit the customer recognizes (a reviewed contract, a resolved support conversation, a completed research task, an enriched record) and measure its full cost of delivery: information retrieval, model calls, tools, retries, evaluation and human review, including failed attempts when calculating the cost per successfully completed unit. Then one must show how much that work is worth, comparing price, implementation, oversight and residual human work against the cost and quality of the process being replaced, and, if building in-house is a credible option, against its development and maintenance costs.

As an example, the piece cites Decagon’s case with Notion: Notion considered building in-house but chose an external solution so its teams could focus on the core platform, after evaluating quality, integrations, security and the vendor relationship. The published case study reports an improvement of up to 34% in ticket resolution time.

On the pricing model, the author points to an earlier piece she wrote with Sarah Wang, “You Are Not a Model. Don’t Price per Token”, which argues that applications should charge at the highest value layer they can reliably measure, attribute and defend. Recognizable work can be charged for directly or packaged into credits, which are a currency rather than a value metric, and should correspond to tasks or levels of effort the customer can plan around. Predictability must also withstand the economics of real workloads: according to Clay’s pricing memo, flat AI prices overcharged simple workloads and made complex ones unviable. Clay separated Data Credits from Actions for orchestration, kept fixed credits for more bounded AI workloads and passed through the actual token cost, with no markup, on the more variable reasoning models. When price is tied to recognizable work, the vendor can use routing, caching or better models to improve margins, lower prices or include more work, and customers share in the gains without tracking every change in the model mix.

The conclusion is that the premium must keep being earned. The test is whether buying the application offers a better combination of total cost, quality, speed and risk than the customer’s best credible alternative, including the effort of implementing, operating and maintaining each option. Execution, context, proof and pricing together reinforce the case for buying. Because model progress continually improves the customer’s alternative, the vendor’s advantage must widen faster to keep justifying the premium.

Editor’s note: the piece comes from a venture capital firm (a16z) with interests in companies in the sector, and several of the case figures (Harvey, Decagon) come from the vendors themselves or from case studies they published.