
Free APIs Are Not a Business Model: How to Build With Public Data Carefully
A practical essay on free APIs, rate limits, keys, caching, fallbacks, licensing, and avoiding fragile products built on borrowed access.
Free does not mean dependable
A free API can change, throttle, disappear, require a key, block a domain, or update its license. If the product depends on one borrowed source, the product is only as strong as someone else's generosity.
Public data needs a plan
Cache responses, track failures, separate providers, and keep fallback data for basic experiences. The user should not see a broken page simply because one provider is down.
Keys do not belong everywhere
Secrets should not live in frontend code. Public keys may be fine when designed for browsers, but privileged access belongs on the server. A leaked key can create bills, abuse, or blocked access.
Take this with you
The best work rarely arrives as a perfect announcement. It arrives as a clearer sentence, a fixed route, a calmer screen, a safer default, a better question, and one more honest version than yesterday. Read the lesson, test it against your own work, then use what survives. That is the whole point.