Don't stop here
Hand-picked guides our readers explore right after this one.
Prompts for OpenAI Codex CLI coding agent for code generation, debugging, and multi-file projects
Read the guideExpert guide to Claude prompts with XML tags, artifacts, and complex reasoning
Read the guideBuild full-stack web apps with Lovable AI using effective prompts for SaaS, dashboards, and landing pages
Read the guideRevenue strategy · Checked August 13, 2026
The right business model follows the customer's workflow, your cost distribution, and the amount of performance risk you can actually carry. Here is how I would compare services, SaaS, usage, outcome, API, and marketplace models before choosing a price page.
Michael Okeje
AI business model research and workflow economics · Last updated August 13, 2026
Pricing is not just a checkout choice. It tells the customer what they are buying and tells the company which uncertainty it has agreed to absorb. A seat plan puts more usage risk on the buyer. A per-task plan makes the provider responsible for making each task complete. An outcome fee makes the provider responsible for attribution and performance. A service contract puts more operational responsibility on the team delivering the work.
I would therefore avoid choosing a model by copying a successful AI company's price page. Ask what the customer can observe, what the provider can control, and where failure happens. If a buyer cannot predict the bill, or the provider cannot predict the cost of serving the account, the business model is unfinished.
BuyerA team wants an outcome but lacks time or expertise to operate the workflow.
RevenueRetainer, project fee, or per-deliverable fee.
MarginStarts lower because people deliver part of the work; improves when repeated steps become productized.
RiskCustom requests and support can swallow the margin.
BuyerA repeatable workflow needs a shared workspace, permissions, history, and collaboration.
RevenueMonthly or annual price per user, sometimes by role.
MarginPredictable revenue, but inactive seats and support affect realized margin.
RiskSeat count may not track value; customers may share logins or resist expansion.
BuyerCustomer volume varies and each action has a countable unit.
RevenuePer task, document, minute, token, credit, API call, or successful action.
MarginCan align revenue with variable model cost and customer volume.
RiskBills become unpredictable; abuse, retries, and edge cases need limits.
BuyerThe customer cares about a measurable business result more than software access.
RevenuePer qualified lead, resolution, completed case, booking, or savings share.
MarginPotentially strong if the workflow is reliable and attribution is clean.
RiskThe provider inherits customer-side delays, disputes, and performance risk.
BuyerAnother product wants agent capability inside its own customer experience.
RevenueAPI usage, minimum commitment, enterprise contract, or revenue share.
MarginEfficient at scale if infrastructure and support are standardized.
RiskConcentration, low switching costs, and demanding uptime expectations.
BuyerMultiple sides need matching, delegation, or shared agent capabilities.
RevenueTake rate, listing fee, subscription, or transaction fee.
MarginCan benefit from network effects, but early liquidity is expensive.
RiskTwo-sided acquisition and quality control are harder than the model layer.
An AI agent can complete many runs and still lose money if the customer accepts only a fraction of its output. Use this simple model for a pilot:
Suppose a research agent is sold at $40 per accepted brief. It makes several model and search calls costing $3.20 per run. Thirty percent of briefs need 12 minutes of analyst review at a loaded cost of $36 per hour, adding $2.16 per average run. Support, storage, and payment cost another $3.50. The contribution margin is $31.14 before acquisition and fixed costs. If the acceptance rate falls from 100% to 70%, the economics change substantially because the provider must either redo work or refund the customer.
The p95 cost matters because an average hides the customer with a huge document, a looping tool call, or a difficult exception. Put limits and approval thresholds around those cases before you advertise unlimited usage.
AI businesses often have both fixed costs and variable costs. A platform must be maintained whether a customer uses it once or every day, while model calls and human review increase with volume. A hybrid model can make that reality visible: charge a base fee for the workspace, permissions, integrations, support, and governance, then include a fair allowance of usage with a clear overage or upgrade path.
Examples include a monthly platform fee plus credits, a per-seat plan with an included task allowance, or a managed retainer plus a fee for exceptional cases. The important details are not the labels. Tell the customer what counts as usage, when a retry counts, whether unused credits expire, how spend is capped, and what happens when the system needs human review.
The customer wants a predictable base budget, but usage genuinely varies and the unit is visible in their own workflow.
The company cannot explain the meter, uses credits to conceal cost, or adds overages because the underlying system is inefficient.
Score each row from low to high for your product. The model with the strongest fit is the one that makes the economics and customer promise easiest to explain.
| Question | If yes, lean toward | Why |
|---|---|---|
| Does value come from a shared workspace and access? | Per-seat or tiered SaaS | The buyer is paying for the operating environment, not just one output. |
| Can you count a completed task and cap its cost? | Usage or credits | The meter maps to both customer volume and provider cost. |
| Can both sides verify a business result? | Outcome fee | Price can follow value, but attribution must be agreed before delivery. |
| Is the workflow still changing every week? | Managed service | A service gives you room to learn before hardening the product boundary. |
| Does another platform already own distribution? | API or embedded contract | Integration can reduce acquisition cost, but service levels and concentration risk rise. |
| Can the customer approve a stable annual budget? | Tiered or hybrid subscription | Predictability becomes part of the product value. |
Unlimited plans sold before p95 cost is known
Charging for tokens when customers care about a completed job
Human review treated as a temporary exception when it is actually the product
Retries and tool loops with no budget or action limit
Outcome definitions that ignore customer-side delays
Enterprise discounts that remove the margin needed for support
A free tier that attracts heavy experimentation but no repeat use
One customer accounting for most revenue and dictating the roadmap
These are not arguments against AI products. They are reasons to instrument them like operational systems. OpenAI's agent guidance recommends guardrails, failure thresholds, and human intervention for high-risk actions. The same controls protect the business model: they bound cost, make quality visible, and create a path for improvement.
For the product decision behind this pricing sequence, see how to start an AI startup. For implementation risk, connect the plan to AI governance and AI evaluation.
There is no universal winner. A service or managed pilot is usually the fastest way to learn a complex workflow; SaaS works when the workflow is repeatable and onboarding can be standardized; usage pricing fits variable consumption; outcome pricing fits measurable results but transfers more risk to the provider. Many startups begin with a service-assisted model and productize the stable parts.
Charge per seat when value comes from access, collaboration, permissions, and a predictable workspace. Charge by use when customer volume varies and the completed task is easy to count. A hybrid plan can combine a platform fee with included credits or metered actions. The unit should be understandable and should not punish the customer for exploring the product.
They can be, but profitability depends on the whole workflow rather than model price alone. Include inference, tools, retrieval, storage, evaluation, human review, support, refunds, sales, and failed or abandoned runs. A product with low model cost can still have poor margins if every customer requires bespoke onboarding and manual correction.
Outcome-based pricing charges for a result such as a qualified appointment, completed document, resolved case, or approved claim rather than for access to the software. It can align price with customer value, but the provider must define attribution, quality, exclusions, refunds, and what happens when the customer delays or rejects the result.
Hybrid pricing gives the provider a predictable base to cover platform and support costs while letting the customer's bill grow with usage or value. Examples include a monthly platform fee plus credits, per-seat access plus overages, or a managed-service retainer plus a fee for completed workflows.
Avoid it when customers cannot predict or audit the usage unit, when model routing makes costs volatile, when a single user can accidentally create a very large bill, or when the buyer's procurement process requires a stable annual budget. In those cases, use a cap, included allowance, approval threshold, or a predictable tier.