Usage billing, a public API and calmer releases for a growing fleet-tracking SaaS
An established SaaS that tracks delivery fleets has outgrown flat per-account pricing, and its larger customers keep asking for an API. Its small in-house team needs extra engineers who can work in the existing codebase without slowing releases.
- Type
- Example project · sample data
- Stage
- Established, growing
- Engagement
- Dedicated engineers in their repo
- Focus
- Billing, API, releases
This is an illustration of a typical platform engagement. Routewise, its customers and its numbers are invented for the example.
Metered usage, visible before invoicing
Vehicles are counted once per month and customers can see their usage before the invoice is created.
Sample design · sample data
Growth outpacing the platform
Large customers pay the same as small ones, invoices are adjusted by hand, and integrations are done by exporting spreadsheets. Each release is a nervous evening because there is no staging environment.
Inside their codebase, in two-week releases
- Engineers join the existing repo, code review and standups
- A staging environment and automated tests come first
- Usage metering and volume pricing added behind a feature flag
- A versioned public API with scoped keys, rate limits and docs
- Webhooks with retries for the events customers care about
- Billing totals compared old against new before switching
What we’d track
- Invoices needing manual correction each month
- Customers using the API
- Failed or rolled-back releases
- Time from merged change to production
Building or growing a SaaS?
Map your build with the free roadmap tool, or book a technical call.