{"id":21096,"date":"2026-10-14T11:16:00","date_gmt":"2026-10-14T09:16:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=21096"},"modified":"2026-10-09T23:40:00","modified_gmt":"2026-10-09T21:40:00","slug":"saas-ai-preismodelle-en","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/saas-internet-earning\/saas-ai-preismodelle-en\/","title":{"rendered":"Subscription, Credits or Payment per Outcome: Pricing an AI SaaS"},"content":{"rendered":"

AI features do not cost the same every month. Long inputs, retries and extra tools change consumption. A flat subscription can appear simple while subsidising heavy users; pure usage pricing makes customer budgets less predictable.<\/p>\n

\"400
Before payments, support, fixed costs and taxes; not vendor prices.<\/figcaption><\/figure>\n

One application, four models<\/h2>\n

The hypothetical product checks documents and delivers an accepted report. Completion requires the agreed checks and a saved result. A model call alone does not constitute delivery to the customer. Stripe documents usage billing, but the meaningful unit remains a product decision. [1<\/a>]<\/p>\n\n\n\n\n\n\n
Model<\/th>\nBenefit<\/th>\nTension<\/th>\n<\/tr>\n
Flat subscription<\/td>\nPredictable budget<\/td>\nHeavy users change costs<\/td>\n<\/tr>\n
Credits<\/td>\nBounded consumption<\/td>\nConversion must stay understandable<\/td>\n<\/tr>\n
Per outcome<\/td>\nCloser to customer value<\/td>\nSuccess and disputes need definitions<\/td>\n<\/tr>\n
Base fee plus usage<\/td>\nSeparate base and variable work<\/td>\nMore explanation and billing logic<\/td>\n<\/tr>\n<\/table>\n

An explicitly assumed example<\/h2>\n

All amounts are net assumptions, not vendor prices. A report costs \u20ac0.12 in variable resources; a flat plan costs \u20ac29. At 50 reports, \u20ac23 remains before payments, support and fixed costs. At 400 reports, variable costs are \u20ac48, producing a \u2212\u20ac19 balance before other costs.<\/p>\n

An assumed hybrid costs \u20ac19 including 50 reports, then \u20ac0.30 for each additional report. At 400 reports, revenue is \u20ac124 and variable costs \u20ac48, leaving \u20ac76 before other costs. This is not a recommendation for that price: it demonstrates the consumption a model must carry.<\/p>\n

Credits without surprises<\/h2>\n

Credits should describe an understandable scope before work begins. Different weights for pages, file size or extra checks need visible calculation. Retries, abandoned jobs and disputes require consistent rules. Consuming a credit without delivery needs explanation.<\/p>\n

An outcome is not business success<\/h2>\n

A delivered report is controllable. Increased customer revenue also depends on data, implementation and market conditions. Outcome prices need a deliverable that can be attributed and verified. Pricing patterns described by Stripe do not solve the quality definition. [2<\/a>]<\/p>\n

Introducing the model<\/h2>\n

A pilot records costs per accepted task and customer, including failed attempts and manual correction. Distribution matters as well as averages: a few large users can change economics. Warnings, limits and hard budgets need defined behaviour when reached. A model becomes credible when the bill matches the service customers received.<\/p>\n

\n

Related tools<\/h2>\n