Three pricing problems we hit selling a weather API, and what we changed

I do marketing and operations for a hyperlocal global weather API. Small team, and pricing was a tough nut to crack.

The hard part with a data product is that it looks like a commodity. Buyers assume every forecast is the same and shop on price, even when the thing behind it isn't the same at all. So you can't price on quality, because they can't see it yet.

Three problems we ran into.

One plan shape can't fit a hobby project and an operations team. One customer makes 5,000 calls a day, another makes 500,000. Same features, wildly different usage. We were trying to solve both with one axis and it kept producing plans that were wrong for everybody. What worked was splitting it in two: pick your tier for features, pick your volume separately. Obvious in hindsight. Took us a while.

A one-time-value asset doesn't belong in a subscription. We have 20 years of historical weather data. Bundle it into a plan and people pull the archive once then churn. Put it in its own tier and it gets expensive enough that only big customers can justify it. We made it metered instead, fractions of a cent per day per location, available on any plan. Pay for what you pull.

Sometimes the right unit isn't calls. People forecasting solar and wind output kept asking for something no tier covered. The fix wasn't a new volume band, it was changing the unit. They don't think in API calls, they think in sites. So we priced per location. That one felt like the actual lesson: price in the unit your customer already counts. If they have to do arithmetic to work out what you'll cost them, you've lost them.

Too early for me to have clean conversion data on any of this, so take it as reasoning rather than proof.

Has anyone else priced in a unit that wasn't calls, seats, or users? What did you land on, and did it confuse people at first?