How to Price an AI-Built SaaS for Your First 100 Customers

Median gross margin for software companies sits near 80 percent, but AI-native SaaS products running real inference workloads land at 55 to 70 percent, according to 2026 benchmark data from Aleph's SaaS gross margin report. That gap is not bad luck. It is what happens when a founder prices an AI feature using a generic SaaS playbook that has no line item for a per-request model bill. How to price an AI-built SaaS for your first 100 customers comes down to three numbers: your real AI cost of goods sold per user, the fixed costs that do not shrink just because you only have 100 customers yet, and the gross margin you need to still be standing at customer 1,000.

Why the usual pricing advice skips your biggest cost

Most pricing guides talk about willingness to pay, competitor benchmarking, and value metrics. All useful, all assuming a classic SaaS cost structure where serving one more user costs a fraction of a cent in database rows and bandwidth. An AI-built product breaks that assumption the moment a feature calls a model on every use. Each request now has a real, metered cost that scales with usage, not with your headcount. Skip that line item and your pricing model is fiction dressed up as strategy. This post is one piece of a wider set of AI monetization strategies, but the unit economics below apply whether you eventually pick subscriptions, credits, or usage billing.

Step 1: Find your real AI cost per request

Pull your model's published per-token price and run the math on a representative request, not a best case. As of September 2026, OpenAI prices GPT-4o mini at $0.15 per million input tokens and $0.60 per million output tokens, per its official API pricing page. Anthropic prices Claude Sonnet 4.6 at $3 per million input tokens and $15 per million output tokens, per its published pricing docs. Take a request with 4,000 input tokens (system prompt, retrieved context, user message) and 800 output tokens, a normal shape for a feature that reads some context and writes a real answer:

• GPT-4o mini: (4,000 / 1,000,000 x $0.15) + (800 / 1,000,000 x $0.60) = about $0.0011 per request

• Claude Sonnet 4.6: (4,000 / 1,000,000 x $3) + (800 / 1,000,000 x $15) = about $0.024 per request

Same feature, same request shape, a roughly 20x difference in cost depending on which model answers it. That gap is a pricing decision you make before you write a single price on a landing page, and it is the reason two AI-built SaaS products with identical feature sets can need completely different price floors.

Step 2: Add the fixed costs that do not shrink at 100 customers

AI COGS is only part of the bill. A small AI-built SaaS also carries fixed monthly costs that stay roughly flat whether you have 20 customers or 500: hosting and compute, a vector store, error tracking, transactional email, a support tool, and a buffer for auxiliary model calls like embeddings or moderation. A realistic bootstrap-stage total for those looks like $600 a month.

At 100 customers, that is $6 of fixed overhead per customer per month. At 1,000 customers, the same $600 spreads to $0.60 per customer. Same infrastructure, a tenth of the per-customer cost, purely from scale. This is the part generic pricing advice never mentions: your cost floor is not fixed, it moves with your customer count even if nothing else about the product changes.

The worked example: cost per customer at three usage levels

Using Claude Sonnet 4.6 at $0.024 per request from Step 1, and $600 in monthly fixed costs from Step 2, here is what three usage patterns actually cost you to serve, at 100 customers and at 1,000 customers:

• Light user, 40 requests/month: AI COGS $0.96. Total cost at 100 customers: $6.96. Total cost at 1,000 customers: $1.56.

• Medium user, 200 requests/month: AI COGS $4.80. Total cost at 100 customers: $10.80. Total cost at 1,000 customers: $5.40.

• Heavy user, 800 requests/month: AI COGS $19.20. Total cost at 100 customers: $25.20. Total cost at 1,000 customers: $19.80.

Now run three candidate flat prices, $19, $39, and $79 a month, against those costs at 100 customers. The margin swing is the whole argument for doing this math before you pick a number:

• At $19/month: light user margin 63%, medium user margin 43%, heavy user margin -33%. You lose about $6.20 on every heavy user before paying yourself anything.

• At $39/month: light user margin 82%, medium user margin 72%, heavy user margin 35%. Thin on heavy users, sustainable everywhere else.

• At $79/month: light user margin 91%, medium user margin 86%, heavy user margin 68%, in line with the AI-native benchmark cited above.

A single flat price at $19 looks attractive on a pricing page and quietly loses money on your best, most-engaged users. That is the opposite of what a pricing model should do.

Step 3: Turn the numbers into a price floor

Once you have a cost per customer, the price floor formula is: price floor = cost per customer / (1 - target gross margin). Pick your target margin honestly. The AI-native benchmark above runs 55 to 70 percent; traditional SaaS runs 75 percent or higher once you have scaled and optimized your inference costs.

Take the medium-usage customer from the worked example, $10.80 in cost at 100 customers. Targeting a 65 percent margin: $10.80 / (1 - 0.65) = about $30.90. The $19 flat price fails this customer before you even count the heavy-user losses. The $39 tier clears it with room to spare.

At 1,000 customers, the same medium user costs $5.40. The same 65 percent margin target: $5.40 / (1 - 0.65) = about $15.40. The $19 price now works comfortably. This is the real answer to how to price an AI-built SaaS for your first 100 customers: price near the top of your floor while you are small, because your floor is falling under you as you grow, not rising.

Step 4: Choose a tiering structure that protects the floor

Two structures are worth comparing at this stage:

• Flat tier with a soft cap and overage: for example, a Starter tier at $19/month including 150 requests with overage at $0.06 per request beyond that, and a Growth tier at $39/month including 500 requests at $0.05 overage. Billing stays predictable for the light and medium users who make up most of a first-100 cohort, and a heavy user's own usage pays for its own AI COGS instead of eating your margin.

• Pure usage-based pricing: for example, a flat per-request or per-generation charge with no base fee. This tends to work better once you have real usage distribution data to set a fair meter. At 100 customers you rarely have that yet, and unpredictable bills are a real drag on conversion for early adopters who are still deciding whether to trust you. The mechanics of setting this up are covered in how to add usage-based pricing to an AI app.

For a first-100 cohort, the flat-tier-plus-overage structure is usually the better starting point. It gives you predictable revenue to model against your fixed costs while still protecting margin against the one outlier heavy user who would otherwise wreck a pure flat-rate plan. Once you have real usage data at 1,000-plus customers, it is worth revisiting whether a credit system or a fuller usage-based model fits your usage curve better.

What changes once you clear 1,000 customers

Two mechanics push your floor down further at scale, beyond the fixed-cost amortization already covered. Anthropic's Batch API gives a 50 percent discount on input and output tokens for asynchronous, non-real-time requests, per its pricing documentation linked above, useful for anything that does not need an instant reply. Prompt caching cuts the cost of repeated context, like a long system prompt reused across requests, by a large margin on cache hits. Combined with fixed-cost amortization, this is why the same price that barely survives at 100 customers can carry a healthy margin at 1,000, without you touching the sticker price at all. Regional cost differences add another layer worth understanding once volume is real, covered in regional pricing for an AI product.

This is not the same problem as finding your first 100 customers

Worth saying plainly: pricing and acquisition are different problems that get tangled together constantly. If you are still working out how to get people through the door at all, that is covered separately in how to get your first 100 users for your AI app. The two compound in a specific way worth watching for: pricing too low to make acquisition easier, then discovering once volume actually arrives that the price cannot cover its own AI COGS. Solve acquisition and pricing as separate questions, but check the second one against the math in this post before you commit to a number that acquisition pressure talked you into.

Frequently asked questions

What gross margin should an AI-built SaaS target in year one?

Aim for the 55 to 70 percent range that Aleph's 2026 benchmark data reports as typical for AI-native SaaS, rather than the 75 percent-plus figure common in traditional software. Treat the gap between those numbers as the cost of running inference, and plan to close it over time with cheaper models for low-value requests, prompt caching, and batch processing, not by hoping AI costs stay ignorable.

Should I absorb AI costs during a free trial?

Yes, but cap the exposure. Limit trial usage to a fixed request count, sized against your worst-case per-request AI cost so a trial abuser costs you a known, bounded amount rather than an open-ended one. An uncapped trial on an AI feature is the fastest way to discover your unit economics the hard way.

How do I stop one heavy user from wrecking my margin?

Give every flat tier a usage cap with an overage charge above it, sized close to your actual per-request AI cost plus a margin. As the worked example above shows, a flat price with no cap turns your best, most-engaged customer into your least profitable one.

Is usage-based pricing better than flat tiers for a brand-new AI SaaS?

Not usually at the very start. Flat tiers with a cap and overage are simpler to sell and easier to model against your fixed costs when you have little usage data. Pure usage-based pricing tends to work better once you can see your actual usage distribution, typically well past the first 100 customers.

How much should I mark up my AI API cost per request?

A flat markup multiple on the token bill alone is the wrong frame at low volume, because fixed costs usually dominate your per-customer cost at 100 customers, not the AI COGS. Use the full price floor formula, cost per customer divided by one minus your target margin, so fixed costs and AI costs are both accounted for rather than just the part that is easiest to calculate.