How We Shipped Usage-Based Pricing in Two Sprints

Practical notes on pairing UsageBox with Cloud Run and Firestore so pricing launches without a quarter-long platform project.

7 min read

usage-based pricingCloud Run billingSaaS monetization

We tried to build usage-based pricing infrastructure from scratch. After two sprints we still didn’t have reliable ingestion or a dashboard customers could understand. The team was spending more time on plumbing than on figuring out the pricing model itself.

UsageBox gave us the missing pieces. It ships with Cloud Run ingestion, Firestore storage, and a Next.js dashboard that already understands accounts, quotas, and invoices. We still own the pricing rules, but the platform handles the mechanics that were slowing us down.

Where We Burned Time

  • Standing up idempotent ingestion endpoints with Firebase auth and scoped API keys
  • Building a rating service that could apply plan logic in real time
  • Syncing subscription changes to keep invoices aligned with reality
  • Giving support a trustworthy view of what customers had been charged

Each workstream dragged because it required infrastructure, data modeling, and tooling. Even after shipping a thin slice we knew maintenance would pile up.

How We Launched in Two Sprints

Catalog and Pricing Logic

We modeled products and meters directly in the UsageBox dashboard. Versioning meant we could tweak prices for a pilot cohort without merging new code each time.

Authentication and Multi-Tenancy

UsageBox validates Firebase tokens, scopes every event, and stores context in Firestore. That matched our existing architecture, so there was no custom middleware to maintain. Here is the security approach in detail.

Customer Visibility

The dashboard shipped with usage charts, plan details, and invoice previews. We wired in branding and a few extra fields and were able to invite our first beta customers the same week.

Results After Launch

  • Shipping the first pricing experiment in fourteen days instead of stretching across a quarter
  • Moving an engineer off billing maintenance and back onto product work
  • Giving support direct access to event histories so they could answer questions without engineering help

What We Would Do Again

Start small. We migrated one endpoint and one customer cohort, validated that the counts, invoices, and alerts lined up, and then widened the rollout. The combination of Cloud Run, Firestore, and the pre-built dashboard let us focus on pricing strategy instead of scaffolding.

If you are staring down a blank billing backlog, wire up a single API route first. Once events are flowing, follow the rollout checklist to bring the rest of your catalog across without derailing product velocity.

Key Topics

  • usage-based pricing
  • Cloud Run billing
  • SaaS monetization

Related Articles

Explore more articles on similar topics to deepen your understanding of usage-based billing.

Per-Seat Pricing Can't Survive Agentic Users: The SaaS Margin Math That Breaks in One Loop

If you sell software at a flat per-seat price and your product calls an LLM that bills per token, your margin is a bet t...

6 min readRead more

The $23,000 Vercel Bill: How Usage-Based Platforms Create Bill Shock (and How Not To)

A DDoS attack turned a developer's Vercel account into a $23,000 bill because all attack traffic billed at the standard ...

10 min readRead more

Cursor's Usage-Based Pricing and Overage, Explained for 2026

Cursor looks like a flat $20 subscription but bills like a metered API account with a prepaid pool. What the included us...

8 min readRead more

Explore More Articles

Discover our complete collection of usage-based billing guides and implementation patterns.

View all articles