Two merchants use the same app. One submits four small reports each month. The other submits hundreds of large files, asks for repeated corrections and needs help with unusual formats. Charging both the same price may be simple, but simplicity does not make their delivery obligations equivalent.
AI software pricing has to reconcile three questions: what the customer values, what the provider must deliver and what creates cost or risk. Choose a price architecture whose unit is understandable to the buyer and whose boundaries keep the promised service sustainable. Then test the actual offer with qualified customers rather than treating a spreadsheet as evidence of willingness to pay.
This cornerstone in The AI Software Factory compares subscriptions, usage, seats and outcomes. AI software cost of goods sold builds the delivery ledger; contribution margin reconciles revenue and attributable cost. Here the central decision is how to structure the customer obligation before selecting a final number.
Start with the job and the paying customer
Price should refer to an offer someone can understand. A merchant paying for a weekly exception report evaluates a different obligation from a developer buying model access or a manager buying team collaboration.
Identify the useful job, its cadence and its acceptance boundary. Name the person who uses the result and the person who approves payment. They may have different information needs even though the product must preserve one coherent promise.
Sell outcomes distinguishes an accepted app result from downstream impact. Pricing a prepared review package does not automatically justify charging a share of increased revenue. The latter would require a credible attribution and measurement arrangement.
Research the current alternative. Customers may compare the app with staff time, a service provider, an existing subscription or doing nothing. The comparison reveals constraints and perceived value, but the cost of an alternative is not automatically the price customers will accept for a new unproven product.
Separate the value hypothesis from the cost floor
A cost calculation tells the founder what delivery requires. It does not establish demand. A willingness-to-pay conversation tells the founder something about perceived value. It does not ensure that the chosen delivery model is profitable.
Keep both records. The value hypothesis should name the customer, useful result, alternative and evidence of commitment. The cost record should include ordinary use, expensive use and exceptions under the actual proposed terms.
The SBA business planning guidance includes researching demand, alternatives and prices, and presents a single-product break-even calculation based on fixed costs and contribution per unit. Those tools support reasoning; they do not prove that any software offer will sell.
A price below the cost floor may still be an intentional limited experiment. State the budget and stopping condition. Do not describe an open-ended loss-making obligation as a validated growth strategy merely because signups arrive.
Choose a unit the customer can predict
A pricing unit can be an account, seat, report, processed item, accepted job or defined business outcome. The unit should map to a decision the customer can anticipate and a record the provider can reconcile.
Internal model tokens often make a poor customer-facing unit when buyers cannot estimate them. A source file may contain hidden variation in size and processing effort. A “report” may vary from a few rows to millions. The unit needs boundaries, not just a familiar noun.
Ask the buyer to estimate a typical bill using representative work. If they cannot do so, the price architecture may require clearer allowances, size bands or caps. The problem might be comprehension rather than the price level itself.
The unit also affects incentives. Charging for retries can reward delivery failure. Charging by seat can discourage collaboration. Charging by output can encourage unnecessary generation. Choose the tradeoff deliberately and inspect behavior rather than assuming one model is universally best.
Flat subscriptions trade predictability for usage exposure
A subscription gives customers a predictable recurring obligation and can fit a recurring job. It also places usage variation with the provider unless the terms include meaningful allowances or scope limits.
Define what the subscription includes. Supported inputs, job volume, storage, users, support and exceptional work all matter. “Unlimited” can create a broad expectation even if the product quietly rate-limits heavy use. Avoid using a word whose ordinary interpretation exceeds the intended obligation.
A subscription can include a practical allowance and a clear path at the boundary: wait until the next period, purchase additional units, upgrade or pause. The customer should know which occurs before reaching the limit.
Review inactive accounts as well as heavy accounts. A subscription can collect revenue from customers who receive little ongoing value, but that is not proof of a durable relationship. A repeat useful job and clear renewal terms make the recurring offer easier to evaluate.
Usage pricing aligns volume but can create bill uncertainty
Usage pricing can make sense when customers vary greatly in work volume and can understand the billable unit. A processed supported report or a validated document batch may be easier to anticipate than internal computation.
Specify whether failed attempts, duplicates, corrections and provider retries count. A customer should not pay twice because the acknowledgment was lost. The billing system needs an operation identity and reconciliation process that matches the commercial policy.
Show current usage and a practical cap when appropriate. A projected charge can help customers decide whether to continue. If the estimate changes with input size, explain the size boundary before processing.
Stripe’s current basic usage-billing documentation recommends Metronome for new usage-based integrations while describing Billing Meters as a supported existing primitive, with compatibility qualifications. That vendor choice needs review for the actual integration; selecting a billing product does not solve the price architecture.
Seat pricing works when people create the value boundary
Seats can fit a collaborative workflow where users need independent access, roles and shared records. The customer can often estimate the number of people involved more readily than processing volume.
But a seat may not track delivery cost or value. One analyst can run thousands of jobs while ten reviewers mostly read the results. A uniform seat price can discourage inviting the people needed to complete the workflow safely.
Define seat roles and commercial consequences clearly. Is a read-only reviewer paid? Does an invited but inactive member count? What happens when someone leaves? Avoid billing surprises caused by administrative actions that do not obviously create new value.
Consider account-level allowances alongside seats if that fits the job. This adds complexity, so require a reason. A hybrid architecture should clarify a real difference in value or cost rather than reproduce every competitor’s pricing table.
Outcome pricing requires acceptance and attribution
Charging per accepted useful result can align the commercial unit with the app’s promise. It also requires a clear acceptance boundary and a fair policy for rejected, corrected or incomplete work.
A review-ready reconciliation package is more directly observable than increased profit. A revenue-share arrangement asks additional questions: which baseline applies, what caused the change, which records establish it and when the amount becomes final?
Avoid an outcome fee whose measurement is costlier than the service itself. If every invoice requires a negotiation over whether the result counted, the model may create support obligations and customer frustration.
A proposed outcome price can begin with a limited pilot and explicit acceptance rules. Preserve disagreements as evidence about the offer. Do not resolve them by making the product’s definition of success broader after the customer commits.
Work through one hypothetical customer population
Consider a hypothetical report product with three monthly usage patterns: a light account completes four supported reports, an ordinary account completes twelve and a heavy account completes sixty. Assume delivery cost is $1.50 per report plus $3 per account for attributable account-level services. These are illustrative assumptions, not vendor prices or Salars measurements.
Under a $39 flat monthly subscription, delivery cost would be $9, $21 and $93 respectively. Contribution before other expenses would be $30, $18 and negative $54. A price that looks comfortable for the light account becomes loss-making for the heavy account under the same obligation.
Now consider $9 per month plus $4 per accepted report. Revenue would be $25, $57 and $249. Under the same cost assumptions, contribution would be $16, $36 and $156. That model covers the illustrated delivery variation, but it may be unattractive to customers who need a predictable fixed bill.
The calculation identifies exposure, not the winning offer. Customers may not accept $4 per report, heavy accounts may have different cost per job and account support may vary. The next step is checking those assumptions and testing the bounded offer.
Compare a subscription with an included allowance
A hybrid alternative could charge $49 per month including twelve supported reports, then $3 for each additional report. For the illustrative light and ordinary accounts, revenue is $49. For the sixty-report account, revenue is $193.
Using the earlier cost assumptions, contribution would be $40, $28 and $100. This preserves a predictable ordinary bill while charging more for heavier work. It also creates questions about unused allowance, reset dates, refunds and the handling of extra usage.
A customer submitting four reports may see poor value compared with a smaller plan. A customer near the allowance may worry about unexpected overages. Explain the boundary and offer a usage view before assuming the hybrid model solves both groups’ problems.
An allowance can correspond to the natural task cadence. Twelve reports may be arbitrary for a weekly job. Choose a package grounded in the customer’s work, then verify that its delivery exposure remains acceptable.
Examine seat pricing with the same workload
Suppose the hypothetical ordinary account has three active users and the price is $19 per seat monthly. Revenue would be $57, matching the earlier ordinary usage example. The apparent equivalence disappears when team size changes independently of volume.
A one-person heavy account would pay $19 while creating the illustrated $93 delivery cost. A ten-person light account would pay $190 despite only four reports. Neither comparison proves seat pricing is wrong; it shows that seats alone do not track the assumed workload.
If collaboration itself creates substantial value, the ten-person account may still find the offer worthwhile. If the work is mostly automated and one person reviews it, a seat-only model may fit poorly. Customer research and cost evidence determine the relevance.
A seat model with an account allowance could address some variation, but now the buyer must understand two units. Keep the explanation and billing record coherent. Added sophistication should earn its complexity through a real problem it solves.
Stress-test cost and usage separately
The baseline calculation can look favorable while hiding sensitivity. Under the $49 plan with twelve included reports, increasing illustrative delivery cost from $1.50 to $3 per report changes ordinary account cost from $21 to $39, reducing contribution from $28 to $10.
If an ordinary account instead completes twenty-four reports at the original cost, revenue becomes $85 and cost $39, giving $46 contribution under the stated hybrid terms. That result differs from a flat $49 subscription with no overage, which would contribute only $10.
Vary one assumption at a time before combining stressful conditions. Inspect report size, retries, human exceptions, vendor minimums and support. A spreadsheet that changes every number at once can obscure which boundary is driving the exposure.
Include a plausible difficult case, not only the average. If a few accounts require expensive manual correction, their obligation may need a different service tier or a narrower supported scope. A larger customer count does not automatically dilute variable exceptions.
Decide how to treat failures and corrections
Commercial treatment should match responsibility. A provider-caused failed job may deserve no charge or a credit. A customer requesting a different supported output after accepting the original may be a new job. An invalid input can be rejected before paid processing if the system can detect it.
Write these policies before implementing the meter. The technical event “job attempted” may be convenient to record but unsuitable as the billable event. Preserve separate cost and billing records so internal retries remain visible without automatically becoming customer charges.
Corrections need scope. Fixing a parser error differs from adapting an unsupported format. The former may belong to the promised product obligation; the latter may require a separate setup offer. Explain the distinction without making the customer litigate internal terminology.
Test duplicate and delayed events. A usage model can be economically reasonable and still damage trust through duplicate invoices. Idempotent agents develops retry safety; the billing path needs the same care at its own boundary.
Package support as a real obligation
Support is not an unlimited free resource simply because the product is software. The offer should state the kind of help included, the relevant service window and the boundary between product assistance and custom consulting.
A small plan may include help with supported imports and product errors. A premium service may include reviewed setup or a scheduled decision session. Both can be reasonable if the price and operation cover the obligation.
Avoid selling a vague “priority support” badge without defining what changes. Faster response, dedicated contact and bespoke interpretation are different services. A promise that cannot be scheduled and staffed creates uncertainty for both customer and provider.
Include support exposure in price experiments. A lower-priced cohort may create more, less or similar support work; do not assume a particular relationship without observations. The customer mix and product fit may matter more than price alone.
Use trials to test readiness and value
A trial should let qualified customers evaluate the promised job within a bounded scope. A sample demo can explain the result, while a limited customer-specific run can test input readiness and practical fit.
Choose what the trial includes and what it does not. A free unlimited processing period can create costs without revealing willingness to pay. A trial so constrained that it cannot complete the job provides weak evidence of value.
Require commercial commitment at a point the customer can understand. Explain what happens when the trial ends and whether any charge follows. Do not rely on surprise renewal as a substitute for a clear offer.
Compare trial cohorts with context. Assisted prospects from the founder’s network may behave differently from unassisted customers arriving through a search channel. Record assistance and readiness rather than attributing all variation to the trial price.
Discounts change the experiment and the promise
A discount can reduce initial purchase friction, compensate for limited maturity or reward a defined commitment. It also changes the evidence gathered. Acceptance at a deeply reduced price does not establish acceptance at the intended ongoing price.
State the duration and renewal terms. A customer should not discover the normal obligation only when the discount expires. Record promotional and standard revenue separately when evaluating economics.
Avoid discounting away a mismatch in the offer. If prospects do not need the result, a cheaper price may create low-value accounts and more support. Investigate the objection before treating every refusal as a price problem.
A deliberate pilot price can be useful when paired with an explicit scope and learning goal. The important distinction is between a bounded test and an indefinite obligation the founder hopes to reprice later without evidence.
Annual payment changes cash timing, not delivery physics
An annual prepayment can improve near-term cash receipts and create a longer customer commitment. The product still owes future service. Do not treat the entire receipt as freely spendable contribution without considering the remaining obligation.
Estimate the delivery exposure across the contract term. Usage, support and vendor costs may change. A large discount for annual payment can lock the provider into a fragile margin before it understands those patterns.
Keep cash receipts, the recurring metric and the accounting view separate. Stripe’s subscription analytics documentation defines its MRR as monthly-normalized active and past-due subscriptions, excluding metered products, taxes and free plans; discount settings affect the calculation. That provider-specific metric is not cash or profit.
Use clear cancellation and refund terms appropriate to the offer and jurisdiction. This article supplies an operating model, not legal or tax advice for a particular contract. Exact terms require review for the actual business arrangement.
Review upgrades and downgrades as customer decisions
A plan change can alter included usage, support and access. Explain when the new terms apply and what happens to current work. The customer should be able to estimate the commercial consequence before confirming it.
A downgrade should not unexpectedly strand existing data or make export impossible. If a feature requires a higher plan, state the consequence and provide a practical transition path consistent with the original promise.
Do not use growth in upgrades as the sole evidence of value. Customers may upgrade because an allowance was poorly explained or a critical workflow was artificially blocked. Examine successful work and understanding alongside revenue.
Plan boundaries should reflect meaningful differences. Packaging every minor interface control as a separate tier can make the offer harder to evaluate and the support process harder to maintain. Simpler packages are valuable when they preserve sound economics.
Establish a price-change process before needing one
A product may need to reprice after learning its actual costs or customer value. Set up the records required to identify affected accounts, current terms and future obligations. Without them, even a justified change can create billing confusion.
Communicate the new price, effective date, scope and available choices clearly. Customers need time appropriate to the consequence to assess the changed obligation. The actual contract and applicable rules govern the process.
Evaluate existing commitments separately from new offers. A new-customer price test does not automatically authorize changing every current agreement. A grandfathered cohort can also create long-lived delivery exposure that deserves explicit planning.
Underpricing examines low-price failure mechanisms. The response is not simply to raise the number; it may require narrowing scope, changing support or retiring a commercially unsuitable offer.
Distinguish account expansion from cost expansion
A growing customer can create several different patterns. More teammates may improve collaboration without increasing report volume. More reports may increase delivery cost without adding users. Larger files may increase compute while the count remains unchanged. A single expansion metric cannot describe all three.
Choose upgrade triggers that the customer can recognize. If file size changes the delivery obligation, a stated size band can be more honest than an unexplained plan requirement. If governance features create a distinct team benefit, they may justify a package difference independent of processing volume.
Inspect the customer’s resulting bill under each pattern. A hypothetical ordinary account that adds two read-only reviewers should not unexpectedly face the same increase as an account that multiplies processing by ten unless that is the explicit architecture the buyer accepted.
The review should include the cost of administering the boundary. A technically precise unit that requires constant manual reconciliation can be more expensive than a slightly broader understandable package. Price architecture has its own operating cost, including support explanations, meter disputes and changes to account entitlements.
Keep those costs visible when comparing models. The highest spreadsheet contribution is not automatically the best business if it produces substantially more confusion or unreliable collection.
Evaluate prepaid credits without hiding their meaning
Prepaid credits can bound spending and make variable work easier to purchase. They can also obscure the unit if customers must translate currency into credits and credits into work through changing rules.
Explain what a credit buys, when it expires, how it is consumed and what happens to a failed job. If different operations consume different amounts, show the expected charge before processing where practical. A customer should not need to reverse-engineer the meter after delivery.
Consider unused balances as obligations, not simply attractive cash receipts. The product may owe future work or a remedy under its actual terms. Credits also require account-level records that reconcile purchase, use, adjustments and expiration.
A proposed test should include two simultaneous jobs, a duplicate submission and a correction after a charge. The credit ledger should produce the agreed commercial result in each case. The customer view should explain the balance without exposing internal retry noise.
Credits may fit an episodic buyer better than a subscription, but only if the buyer can estimate useful work. Test that understanding before adding a wallet merely because the billing vendor supports one.
Make currency and invoice timing explicit
A buyer evaluating a price needs to know the currency, billing period and whether the displayed amount includes the charges applicable to their purchase. A cross-border or business account can face different administrative requirements from a simple domestic consumer purchase.
The actual billing integration should establish how required taxes, invoices and payment methods apply. Do not invent a universal rule from one provider’s examples. Keep current legal and accounting review scoped to the jurisdictions and arrangement the product actually serves.
Timing matters for usage offers. A monthly invoice issued after substantial consumption creates different exposure from a prepaid balance or a hard cap. State when the customer can inspect accrued usage and when it becomes payable.
A failed payment also needs a policy. Does processing pause immediately, continue for a stated period or remain limited to already paid work? The decision affects service continuity, collection risk and support. The policy should be visible before a failure and enforced consistently afterward.
These details may be unglamorous, but they make the commercial promise concrete. A price architecture is incomplete if the customer understands the unit yet cannot predict when or how the obligation appears.
Keep a decision record for the chosen architecture
After selecting a model, record why it fits the job, which alternatives were considered and which uncertainties remain. Include the relevant customer evidence, cost assumptions and protected cases. This makes later changes easier to assess than a memory of a persuasive sales conversation.
The record should separate measured facts from assumptions. A pilot’s accepted reports can support observed usage. A projected heavy account remains a scenario until one appears. A customer saying the bill is understandable is useful qualitative evidence, but does not establish long-term renewal behavior.
Set revalidation triggers. A new model price, a larger supported file, a new support promise or a different customer segment can change the chosen architecture’s economics. Review the decision when those triggers occur rather than treating the first price as permanent truth.
The record can be brief and internal. Its purpose is to keep the business from forgetting what the offer depends on. When a later problem arises, the team can identify which assumption changed and choose a focused response.
Use break-even only within its assumptions
Suppose the hypothetical ordinary subscription contributes $28 monthly after its stated delivery costs and fixed monthly expenses are $840. Thirty such accounts would cover those fixed expenses in this simplified scenario: $840 divided by $28. This does not include acquisition spending, owner compensation or obligations excluded from the model.
If ordinary contribution falls to $10 under the cost sensitivity case, the same fixed expenses require eighty-four accounts. The arithmetic shows why a delivery assumption matters more than an attractive customer-count target. It does not predict that either number of customers is reachable.
Mixed cohorts require their own weighted contribution rather than pretending every account resembles the ordinary case. Recompute when the actual mix changes. A break-even worksheet is a decision aid whose usefulness depends on the cost boundary and customer evidence, not an automatic forecast of profitable software.
What Would We Do at Salars?
For a proposed merchant report app, we would begin with the supported job and its natural cadence. We would build an illustrative cost ledger, then replace assumptions with measured ordinary and exception-path costs during a bounded pilot.
We would compare a predictable subscription with a stated allowance against a comprehensible per-accepted-report offer. The customer would see which runs count, what happens at the limit and how failed provider runs are treated. Neither architecture would be called validated before qualified customers completed the job and made a consequential purchase decision.
A proposed price review would include light, ordinary and heavy use, larger files, duplicate submissions and manual exceptions. It would preserve acceptance quality and customer comprehension as requirements. The numeric scenarios in this article are hypothetical; they are not observed Salars margins or current vendor prices.
We would keep billing units separate from internal compute and record support obligations explicitly. A final offer would need to cover its actual delivery boundary and remain understandable to the merchant making the purchase.
Price architecture is an operating decision about value, risk and responsibility. Choosing it carefully gives the product a clearer promise and gives the founder a business model that can be tested. The wider AI collection supplies the discovery, trust and delivery practices that make those tests meaningful.
Sources
- Stripe: Basic usage-based billing — current Metronome/Billing Meters guidance and compatibility qualifications, checked October 7, 2026; not a quoted pricing schedule.
- Stripe: Subscription analytics — provider-specific MRR and discount definitions; not cash, recognized revenue or profit.
- SBA: Plan your business — market research and single-product break-even guidance; does not establish demand for the hypothetical app.
Loading comments…