DEV Community

Cover image for Finding the right price for a weather API
Petrichor
Petrichor

Posted on • Originally published at meteosource.com

Finding the right price for a weather API

Why pricing a digital product is harder than it looks

Pricing a digital product is a strange kind of problem. There's no shelf to stock, and the cost of serving each customer isn't fixed. It grows with how much they use it. Usage is unpredictable, value is hard to see upfront, and a weather forecast can feel like a commodity, something buyers assume is all the same and shop for on price alone, even when the accuracy behind it isn't (in our case, 40 models blended with machine learning).

Price it too high, and it's out of reach for a hobby developer building something small. Price it too low, and it can't support what a business running thousands of locations actually needs. We ran into this from three different angles at Meteosource, and changed our pricing to deal with each one.

Challenge 1: usage is all over the place

A subscription API was always our way of letting a solo developer and a global operations team build on the same forecasts. But a fixed call limit doesn't work for both. One project makes 5,000 calls a day, another makes 500,000. Same plan, wildly different needs.

So to solve this, we split the offer into subscription levels, from Startup to Standard, and gave each level its own tier of call volumes. It works a bit like a table: pick your subscription for the features you need, then pick the call volume that matches how much you actually use, and find where you sit best. The details are on our pricing page, but the short version is: a side project and a scaling product don't have to fit in the same box anymore, and moving up as you grow is a lot more incremental.

Challenge 2: historical data doesn't fit neatly into a tier

Twenty years of historical weather data is one of the most valuable things we offer, and one of the hardest to price fairly. Bundle it into a plan, and people download the archive once and leave. Put it behind its own tier, and the price climbs until only the biggest customers can justify it. Neither worked.

We made it a metered add-on instead: $0.005 per day, per location, covering 20 years back, on any plan. You pay for exactly what you pull. A small project can dip into the archive without upgrading to an expensive tier, and the cost scales with actual usage instead of a flat guess.

Challenge 3: no tier existed for renewables forecasting

We kept hearing from people forecasting energy production (solar and wind) who needed something none of our existing plans covered: power-production forecasts per location, at hourly or 15-minute resolution.

So we built a Renewables tier from $19/location, covering PV systems and wind farms. It works whether you're modeling a few rooftop panels or a full farm. Past 20 sites, we set up custom pricing directly.

What stayed the same

Free is still 400 calls/day, no credit card, just an email. Enterprise is still fully custom, with parameters, data volume, SLAs, and applied-AI models built around the use case. Existing subscribers keep their current plan. We kept what was working, and moved around what needed a change.

We'll keep adjusting further if the need appears, and of course keep adding features to cover more of what people actually need. That's really the goal behind all of it.

But we're happy we cracked the logic of it, and it seems to be working well. What do you think about this change? What's your experience with the prices? Share it with us.

Top comments (0)