Pricing strategy should lead product, not the other way around

Most AI teams set prices in the same order. The team builds a feature, ships it, watches usage for a few months, and then someone asks what it should cost. By then, the answer is already constrained by what was built.

The feature might run three model calls where one would do. It might have no clear moment where the work counts as done, so you cannot price it as an outcome. It might not emit the signals you need to see who uses it and what it costs you. Each of those is a pricing problem that started as a product decision.

In AI products, every feature has a provider cost attached. That makes pricing a design input. Decide how a feature will make money while you are deciding how it will work.

Why pricing usually comes last

The habit comes from SaaS. A seat cost roughly the same to serve in month 12 as in month one, so pricing could wait. You packaged features into tiers after they shipped, and the margin took care of itself.

AI products carry a cost per unit of work, and product decisions set that cost. Three examples:

• Architecture sets your provider cost. A planning step, a retrieval pass, or a second agent that checks the first can multiply the tokens behind one customer request. If nobody asked what the customer will pay for that request, nobody weighed those steps against it.
• Model choice sets your margin floor. Model providers change prices, add tiers, and retire models on their own schedule. A feature built around one model's rates carries that exposure into every plan it lands in.
• Usage patterns set who is profitable. Some accounts run overnight batch jobs. Others use the agent twice a week. If the product was designed without a pricing unit in mind, flat pricing hides the difference until one heavy account costs more to serve than it pays.

What it costs when pricing follows the product

The first cost is margin, and it builds quietly in your heaviest accounts. You usually find it when someone exports provider invoices into a spreadsheet and matches them to customers by hand.

The second cost is the retrofit. When pricing is designed after the product, the correction eventually arrives all at once, and customers experience it as a surprise bill. Cursor's mid-2025 move from request-based to usage-based limits on its Pro plan is the public example: the company apologized within weeks and offered refunds for unexpected charges. Customers had formed their habits under one pricing model while the product's costs had moved to another.

The third cost is that your sales team becomes your pricing engine. Every custom deal, discount, and one-off credit grant is a pricing decision made outside the system. After a few dozen of them, nobody can say what a customer is supposed to pay.

The fourth cost is features you cannot charge for. If a feature has no unit a customer recognizes and no signal you can meter, it ships as a free addition to every plan, whatever it costs you to run.

How to put pricing first

Pricing first means the pricing question sits in the product spec, next to the user story. Teams that work this way tend to do five things.

1. Write the pricing unit into the spec. Before building, name what the customer will pay for: a credit, an outcome, or a unit such as a seat or a repo. If you cannot name it, you have found a product question worth answering first.
2. Set a cost budget per unit of work. Agree on the provider cost one request or outcome can consume at the price you plan to charge. Architecture choices then get weighed against a number.
3. Define "done" before you build. Outcome pricing needs a clear, meterable moment when the work is complete. That moment is easier to design in than to reconstruct from logs later.
4. Meter from the first release. Record every signal with the customer, agent, and model attached, including features you do not bill yet. When you decide to charge, the data already exists.
5. Keep prices in configuration. Credit burn rates, outcome prices, and plan limits live in plan configuration, outside application code, so a pricing decision ships without a code change.

Billing decides whether pricing can lead

For most AI teams, the billing system is what slows pricing down.

Pricing can only lead the product if your billing system keeps up with both.

The typical setup started as a sensible shortcut: usage rows in Postgres, a cron job that totals them at month end, and a spreadsheet that estimates margin. It handles the first pricing model well. Each new one after that takes more work.

The problems are specific. A prepaid credit bundle and a monthly usage overage need different billing timing, so they end up in separate code paths. A new outcome price needs a new definition of "done" in the meter. Grandfathering needs plan history the original tables never stored. Each change is reasonable. Together, they turn every pricing decision into a sprint, and pricing slides back to the end of the roadmap.

This is the problem we are building Clocknext to solve. Plans are composed from credits, outcomes, units, wallets, and flat fees, and each one can bill in advance or in arrears inside the same plan. Because every signal carries provider cost, you see margin per customer, per agent, and per model, without the spreadsheet.

Start with the next feature

The simplest place to start is the next feature on your roadmap. Before it goes into a sprint, answer three questions: what will a customer pay for, what can one unit of it cost you, and how will you know it happened?

If those answers are hard to get, or if checking what your five largest customers cost you last week takes an afternoon of spreadsheet work, talk to us. We will show you how Clocknext handles it for your own agents.