Why free support tiers should still get real answers
A support queue that only gives thoughtful answers to paying customers is telling free users their questions are not worth solving properly.
A support queue that only gives thoughtful answers to paying customers is telling free users their questions are not worth solving properly.
A header, a bearer token, and a query parameter all authenticate a request the same way. Charging more for one of them is charging for a preference, not a feature.
If switching a location API takes a quarter, the previous integration was designed to make leaving expensive, whether or not that was the stated intention.
A usage dashboard that only updates once a day is not really a real time picture at all. It is just yesterday's number wearing today's date on it.
A geocoding API that gates real testing behind a sales conversation is asking a developer for trust before it has actually earned any of it.
A webhook works well for one request at a time. It works badly for a script that just wants to send a thousand lookups and wait for a thousand answers.
An undocumented error code turns every failed request into a guessing game. Publishing the list is a small thing that saves real debugging time.
A free tier is not a discount, and it is not bait for a sales call. It is the smallest useful amount of a product a developer needs to find out if it fits.
An exciting new API version is a migration project for everyone downstream of it. Boring, stable versioning is a feature, not a lack of ambition.
A sandbox that costs money just to test in is not really a sandbox at all. It is a paid tier wearing a testing costume for the pricing page.
A feature you cannot figure out how to use might as well not exist at all. Documentation is not a support cost, it is part of the actual product.
Finding your rate limit through a 429 error in production is not documentation. It is a support ticket that should never have needed to exist.
A trial ends and asks for a credit card on a fixed schedule. A keyless tier just keeps working. We think the second one respects a developer's time more.
A per-request price matches what an API actually costs to run. Seat pricing measures headcount, not usage, and geocoding traffic rarely follows either.