May 28, 2026 · 8 min read
Pricing travel data: tiered subscriptions beat per-call metering
We launched with $49 Starter, $249 Growth, and a free tier of 1,000 calls/month. We didn't meter. Here's the math behind that choice and the trade-off we accepted to make it.
The default that everyone reaches for
The standard advice for an API business is: meter per call, charge fractions of a cent, scale revenue with usage. AWS does it. Stripe does it. Twilio does it. Google Places charges $17 per thousand Place Details requests. The pattern is so dominant it feels like the only adult option.
For us it was wrong, and almost every customer who tried both told us so within the first month.
Who metering serves
Per-call metering is a great deal for one kind of buyer: the infrastructure-scale customer running variable, spiky workloads with a finance team that has spreadsheets for cloud spend. They want linear scaling. They have FinOps. They write off the cost in unit economics that compress over time.
Our customer is not that buyer. Our customer is a four-person team shipping a travel chatbot. They have a $400/month tools budget. They want to know — in advance, on day one — what the line item will read when the CFO opens QuickBooks.
The math from the buyer's seat
Imagine a chatbot with 3,000 monthly active users. Each session triggers about 10 API calls. That's 30,000 calls per month at steady state, growing.
Google Places at $17 per thousand: roughly $510. Reasonable. Now the chatbot grows to 10,000 MAU and 100,000 calls. The bill is $1,700 per month. If the chatbot has a viral week, it's $4,000. The founder's reaction is to add caching, rate-limit users, and start nervously logging into the billing console at 2am.
Our Growth tier is a flat $249. It includes enough headroom that the same chatbot doesn't think about pricing again for a year. Whatever happens to traffic, the line item reads $249.
Why predictability is worth the structural mispricing
Tiers are structurally a worse fit for actual usage than metering. Some customers will under-use their tier and overpay. Others will push the limit and we'll subsidize them. Metering would clean that up. We chose to leave that money on the table.
The reason is that for SaaS teams in our price band, predictable cost is a feature, not just a comfort. It removes the conversation about caching strategy from the team's first three sprints. It removes "what does this cost at scale" from their internal demo. It removes the procurement objection where the buyer can't budget a line that varies. The selling friction collapses.
The free tier is a positioning choice, not a discount
We give 1,000 calls a month free, no card required. That's not a trial. It's a permanent offer. The reason is that travel-data buyers are technical, skeptical, and have been burned by APIs that promise coverage and ship gaps. The free tier lets them stress-test the actual data — the actual coverage of their actual destinations — before deciding anything. By the time they upgrade to Starter, they've already validated that we have the rows they need.
What we'd consider for a v2
There's a real argument for a hybrid: tiered for predictability, with a metered overage rate for customers who blow past their plan. We haven't shipped that yet because the failure mode of the simple tiered model — a customer occasionally hitting their cap — has been rare enough that it isn't worth the billing complexity.
The decision tree, if you're pricing a similar product: who is your buyer, do they have a FinOps function, and how much do they value predictable cost. If the answer is "small SaaS team, no, a lot," pick tiers. If it's "platform infra, yes, not really," pick metering. Don't pick metering because the cool kids do.