Our takes

Why we priced this per request, not per seat

A seat is a unit of software you install once and open every morning. An API call is not that. It happens whenever a batch job runs, a checkout page loads, or a background worker resolves a shipping address. Nobody sits at a desk clicking a button ten thousand times a day. A machine does that, and it does it in bursts.

Seat pricing exists because it is easy to sell and easy to forecast. You count people, multiply by a monthly fee, and you have a number finance can plan around. It works for software that people log into. It does not work for infrastructure that machines call, because the number of people on a team has almost no relationship to the number of requests that team's systems make.

We priced My Geocode per request because that is what actually costs us money to serve. Every lookup touches a database, does some computation, and returns a response. The cost scales with volume, not with how many engineers hold API keys. So we charge for volume: 2,500 free requests a day from any address, with no key at all. When you need more, sign up with an email address and either top up prepaid credit at €0.0001 a request or take an Unlimited key for €50 a month. Every endpoint and every drop-in host costs the same.

This also removes a strange incentive that seat pricing creates. When you pay per seat, you are tempted to share one login across a team to save money, which usually violates the terms of service anyway. When you pay per request, there is nothing to share. One key or ten keys, it does not matter. What matters is how many lookups you actually make, and that number is honest. It goes up when your product gets busier and down when it does not, without anyone renegotiating a contract.

Per-request pricing also scales down cleanly, which seat pricing rarely does. A student project or a weekend prototype does not need five seats. It needs a few hundred lookups a month, and the free allowance covers that without a sales conversation. A growing product does not need to guess how many seats its geocoding needs; it needs to know what a thousand requests cost, which is a number you can put directly into a unit economics spreadsheet.

None of this means per-request pricing has no tradeoffs. It means your bill moves with your traffic, which can be uncomfortable if you are not watching usage. That is a real cost, and we do not pretend otherwise. It is why every response carries quota headers so you always know where you stand before a bill surprises you, not after.

We are not against seats as a concept. They make sense for tools that a fixed number of humans open and close. Geocoding is not that kind of tool. It is closer to electricity than to a subscription: something consumed by machines running your business, at a rate that has nothing to do with your headcount. Pricing it per unit used is the only version of the number that means anything.