The modern cloud has a billing problem. Not the raw prices — compute has never been cheaper — but the cognitive overhead. When you're charged per millisecond of CPU time, per GB of egress, per API call, and per log line stored, you end up making architectural decisions based on cost anxiety rather than what's actually right for your users. You add caches not because you need them but because you're afraid of the database query bill. You delete logs you'd want to keep. You avoid certain regions because the egress math is terrifying.
The dark pattern at the heart of usage-based billing
Usage-based billing looks fair on paper. You pay for what you use, and nothing more. But in practice it creates perverse incentives. Cloud providers benefit when their services are hard to reason about — because confused customers over-provision, and surprised customers rarely churn immediately (they're too deep in the ecosystem to leave). The complexity is a moat. Per-minute billing is the most egregious version of this: your bill changes every second, and you can't know what it will be until the month is over.
We looked at how developers actually spend money on infrastructure. Most small services have consistent, predictable load. A startup's API doesn't have wildly variable traffic day to day — it grows gradually. Flat pricing matches this reality. You know your costs in January. You know them in December. If you ship a feature that gets picked up by Hacker News, your bill doesn't spike. You celebrate instead of refreshing the billing dashboard.
How we set the number
We modeled what a typical production service actually costs to run on Hetzner hardware: CPU allocation, memory, egress, storage, TLS, monitoring. Then we added a margin that lets us stay profitable while keeping the price well below what engineers pay in time every month managing their own infrastructure or debugging billing anomalies. The goal is to be so obviously worth it that pricing never comes up in a conversation about whether to use Glinr.
Flat pricing is also a forcing function for us. We can't subsidize inefficient infrastructure by passing costs to customers. We have to build an efficient platform. That's a constraint we're happy to have.