Three years ago, I open-sourced a lightweight routing layer for edge deployments. By late 2023, it had 14k GitHub stars and zero revenue. I assumed visibility would naturally convert into income. I was wrong. The transition from community project to sustainable business required a complete rethink of how engineering teams actually budget for tooling.
Today, my API infrastructure company brings in $42k MRR with a 91% gross margin. The journey wasn’t about shipping more endpoints. It was about pricing architecture, usage psychology, and aligning my billing model with how developers actually run production workloads. Here’s what worked, what failed, and the exact numbers behind the decisions.
The Pricing Shift: From Flat Tiers to Telemetry-Driven Metering
Early on, I used a flat $29/month Pro tier capped at 500k requests. Conversion hovered around 1.2%. The flaw was obvious: I was charging for access, not consumption. Developers don’t care about “Pro” labels. They care about predictability, scale, and what happens when traffic spikes during a launch.
In mid-2024, I replaced it with a hybrid model: free sandbox with hard limits, usage-based overages, and flat-rate tiers for budget planning. I tied pricing directly to compute seconds and egress volume instead of arbitrary request counts. The free tier became a functional playground with 50k requests/month and basic telemetry. Once a project crossed into production, the meter ran.
I also introduced “burst credit” packs for teams that needed predictable spikes without negotiating contracts. Instead of pushing them to sales, I sold $25 credit blocks that converted automatically when usage exceeded tier limits. That single change reduced billing disputes by 68% and lifted paid conversion to 4.3%.
Here’s the exact tier breakdown that stabilized our revenue in early 2025:
| Tier | Monthly Cost | Included Usage | Overage Rate | Conversion Rate |
|---|---|---|---|---|
| Sandbox | $0 | 50k requests, 10GB egress | N/A | 100% (acquisition) |
| Production | $19 + usage | 200k requests, 50GB egress | $0.40/10k requests, $0.05/GB | 4.8% |
| Scale | $79 flat | 2M requests, 200GB egress | $0.25/10k requests, $0.03/GB | 2.1% |
| Enterprise | Custom | SLA, dedicated edge nodes, SSO | Negotiated | 0.7% (62% of revenue) |
The Scale tier became our anchor. It caught growing startups before they churned to competitors. The flat fee gave them budget predictability, while the overage rate stayed low enough that scaling felt painless. Enterprise stayed small in volume but massive in revenue. I capped it at five clients deliberately to keep operational overhead manageable.
The Real Numbers
I’ll keep the breakdown blunt. Revenue streams for the last trailing twelve months:
- Self-serve API usage: $214,000
- Scale tier subscriptions: $189,000
- Enterprise contracts (5 clients): $72,000
- Add-on modules (auth proxy, rate-limit rules, observability packs): $29,000
- Total ARR: ~$504,000 ($42k MRR average)
Margins sit at 91% because the stack runs on spot instances with auto-scaling, and I don’t carry a sales team. Customer acquisition is purely organic through GitHub, technical write-ups, and developer communities. The only paid channel I tested was conference sponsorships, and it consistently underperformed. I stopped doing them.
The hardest metric to move was churn. At 2.8% monthly early on, it felt manageable. But 2.8% compounds. I dug into the telemetry and found the real issue: teams were upgrading to Scale, then hitting egress caps within 90 days, then leaving when overage invoices surprised them. I fixed it by adding a hard cap notification at 80% usage, followed by a one-click upgrade prompt in the dashboard. Monthly churn dropped to 1.1%. Net revenue retention jumped from 84% to 108%.
Lessons That Cost Me Time and Cash
Developers will pay for reliability, not features.
I spent six months building a plugin ecosystem. Conversion didn’t budge. What moved the needle was publishing a public status page with a 90-day uptime history, plus automated failover documentation. Teams started asking for enterprise contracts because they needed guaranteed SLAs, not another middleware integration.
Free tiers must be genuinely useful.
My initial free tier rate-limited to 10 req/sec. Developers used it for testing, hit the limit during basic load tests, and abandoned the project. I raised it to 50 req/sec and added 30-day metric retention. Suddenly, indie hackers and small agencies built real prototypes on it. They became my best referral source.
Invoice transparency beats sales calls.
In 2026, developers expect to read a pricing page and calculate their cost in under two minutes. I added a live cost estimator to the dashboard that updates as you configure routes, middleware, and egress regions. Support tickets about billing dropped by 73%. Finance teams at startups stopped pushing back on procurement.
Don’t optimize for vanity metrics.
I used to track “active users” and “total API calls.” Both are useless for a bootstrapped tool. The only metric that correlates with survival is net revenue retention. I track it weekly. If it dips below 100% for two consecutive months, I know the pricing or product is misaligned with market reality.
Enterprise doesn’t mean “big logo.”
I wasted eight months chasing Fortune 500 security reviews. The real money came from Series B startups shipping AI agent workflows that needed low-latency routing and predictable compute costs. Their procurement cycles are 14 days. Their contracts are straightforward. They pay for speed, not compliance theater.
What I’m Doing Differently Now
I stopped chasing new pricing models every quarter. The hybrid usage + tiered flat structure works because it matches how engineering teams budget. I publish our pricing on GitHub, keep the estimator public, and route every billing question directly to the dashboard instead of a support inbox.
I also stopped building features I couldn’t price clearly. If a feature doesn’t map to compute, egress, or operational overhead, it stays in the backlog. That discipline cut infrastructure waste by 34% last year.
Monetizing developer tools isn’t about locking features behind paywalls. It’s about aligning your revenue mechanics with the actual cost of delivering value. If you can explain exactly what a team is paying for, why it costs that amount, and how it scales with their workload, you won’t need a sales deck. You’ll just need a working API and a pricing page that doesn’t lie.
The numbers above are real. The structure is repeatable. Build something useful, charge for what it consumes, and let telemetry—not assumptions—drive your next move.
💡 Further Reading: Pi Stack
Top comments (0)