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.

Chargebee Metered Billing for AI Usage: Where It Works and Where It Stops

Chargebee does support metered billing, and for many products that is genuinely enough. It stops being enough at four th...

8 min readRead more

Designing Billing Meters: Value Types, Units, and the Four Aggregations That Decide the Invoice

A billing meter is a small schema decision with invoice-sized consequences: value type, aggregation (sum, count, max, un...

8 min readRead more

Free AI Credits Can Quietly Switch On Metered Billing

On a subscription plan the rate limit is a spend cap you never configured: hit it and you stop. Usage credits remove tha...

7 min readRead more

Explore More Articles

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

View all articles