How to price your AI SaaS - 2 mistakes we made

Pricing is hard. Pricing for speech and audio intelligence is harder, because what you are selling is not a seat or a document — it is minutes of acoustic signal that have to be decoded, diarized, and normalized before anybody can read the result.

We have rebuilt the Andebet pricing page more than once, and we made two mistakes worth writing down.

Mistake #1. Pricing based on costs

The first version of our pricing was a mirror of our infrastructure bill. We metered the things that are expensive for us: model compute, chunk counts, GPU seconds.

That is a tempting way to protect margin, and a terrible way to talk to a customer. Somebody who wants to transcribe a 45-minute Amharic interview does not want to estimate GPU cycles. Their question is much simpler: what does one hour of audio cost me?

So we deleted the internal units and put the customer’s unit on the page: audio minutes. That one change did more for our sales conversations than any copy rewrite, because it removed arithmetic from the buying decision.

It also forced us to be honest about what actually drives our cost. The expensive part is not the average minute — it is the shape of the audio:

• Long-form recordings. A two-hour focus group with overlapping speakers costs far more to process than sixty one-minute clips, even though the total duration is identical.
• Diarization and code-switching. Splitting speakers and tracking Amharic–English switches inside a single utterance needs more acoustic context than a monolingual monologue.
• Ge’ez script normalization. Amharic and Tigrinya output has to be normalized into consistent fidel, and homophone-heavy recognition errors have to be handled before a transcript is usable.
• Low-resource languages. Afaan Oromo and Tigrinya have far less labelled audio to train on than English, so more of our engineering time goes into data work than into GPU time.

None of that belongs on a pricing page. All of it belongs in how we size an allowance — which is why the free tier is measured in minutes and the paid tiers are sized in hours.

Mistake #2. Introducing unnecessary complexity

The second mistake was inventing a second unit. Every new concept on a pricing page is something extra a customer has to hold in their head, and stacked-up concepts are how you lose somebody who was ready to pay.

Complexity #1. Introducing “processing credits”

At one point our page asked customers to think in processing credits. A raw transcription consumed a fixed number of credits; a search across the resulting corpus consumed a different number. The intent was to reflect variable backend cost. The effect was that nobody — including us — could answer what will this month cost? without a spreadsheet.

When we dogfooded our own API and could not predict our own invoice, that was the tell. If the people who built the meter cannot read it, the meter is the problem.

We killed the concept and replaced it with transparent audio minutes. Now the answer fits in one sentence: you get a monthly allowance of audio, and anything beyond it is billed per extra minute at a rate printed on the page.

It is also far easier to say out loud. “You get 10 hours a month, then $0.015 a minute” survives a sales call. “You spend processing credits on diarization and search credits on timestamps” does not.

Complexity #2. Adding tiered pricing when we really didn’t need it

We also jumped into tiers too early, with a Solo / Startup / Business split where every plan changed the limits and the units at the same time. That is the trap of doing something because it is what everybody does.

The lesson was not “never build tiers”. It was that a tier should change exactly one thing: the size of the allowance. Every plan we ship today is denominated in the same unit — audio minutes — and the tier decides how many of them you get, plus the operational extras that come with them.

Here is the structure we ended up with, and why each step exists:

Two details matter more than the numbers. First, the unit never changes between plans, so upgrading is never a re-education. Second, every paid plan has a controllable monthly spending limit, so a runaway batch job cannot produce a surprise invoice.

Local billing matters too. We publish Ethiopian Birr prices alongside US dollars, because a researcher in Addis should not have to open a currency converter to find out what a plan costs.

TL;DR - how should you price your AI product?

If you are pricing an AI product, especially a new one, this is what we would do differently from the start.

1. Kill as much complexity as you can.

• Pick the unit your customer already understands and use it everywhere. For us that is an audio minute.
• Do not introduce a second unit for a second feature. If a capability cannot be expressed in the same unit, it probably belongs in the plan rather than on the meter.
• Make the free tier a real allowance, not a demo. 45 minutes is enough to upload a genuine interview and judge the output for yourself.
• Put a hard cap on spending — visible to the customer — on every paid plan.

2. Focus on outcomes, not on running costs.

You will almost certainly make less money per heavy user this way. Margins get tighter, and you have to watch for abuse — rate limits, concurrency limits, and spending caps are not optional once you price on the customer’s unit instead of on your own compute.

In return you get a page a customer can read in ten seconds and a bill they can predict. That has been worth more to us than the margin we gave up.