How Fly.io solves usage-based billing challenges with Metronome

‍Fly.io is a developer-focused public cloud that makes it easy to deploy and grow your business. As this lean startup has grown, they’ve faced a now-common challenge: usage-based billing. Jon Phenow, Staff Software Engineer at Fly.io, spoke with Chang Li, Product Marketing Manager at Metronome, about the obstacles his team overcame in making usage-based invoices clear and legible for customers, aligning pricing to value, making pricing updates easier, and more. 

Tell us about what makes usage-based billing challenging at Fly.io.

Our focus is always on delivering tangible value to our customers. That obviously comes in the form of Fly.io products, but it also comes through in our invoices’ usefulness. The utility just has to be there, same as any other experience customers have with us. 

Fly.io’s pricing and invoices have complexified with all that usage-based billing encompasses. At Fly, each customer signs up as at least one organization. Within that org, you can set up one, two, or hundreds of apps. Each app generates charges based on where it’s running (one or multiple regions), machine type, CPU count, bandwidth, data transfer, volume, etc. An invoice can quickly end up with thousands of line items, frustrating customers who just want to understand where their money has been spent.

We explored different methods that would account for all these pricing dimensions, as well as allow us to support other factors unique to Fly.io, like the fact that customers build apps on top of our infrastructure. Add onto that our special pricing for larger contracts, discounts for certain regions, and our desire to iterate quickly on pricing, and you understand some of the challenges we’ve been partnering with your team on.

Where did initial efforts to simplify billing fall short, and how did Metronome help?

We started off collecting and storing usage data in a TimescaleDB, with a goal of sharing better information via total-cost invoices through Stripe. Every dimension associated with that data had to be accurate, up-to-date, and reliable. We tried so hard to make the usage data useful by pairing it with pricing information, but two main obstacles made it nonfunctional: 

First, usage and pricing data were decoupled, so it was hard to break down total costs by granular usage and get the numbers to align correctly with Stripe. Stripe also couldn’t handle the usage-related dimensions we’d been capturing. Those should have allowed us to display more granular usage data on invoices and to group org- or app-associated charges, but we really hit a wall there.

Second is just that as a startup, bandwidth is limited. We have to be judicious with our engineering team’s time, and throwing unsized effort at a problem like this just isn’t worth it when we have other projects to ship. It made sense to find a partner that could help us make things simpler and more understandable for customers.

We talked to several vendors, but Metronome showed us the most direct path to clearly tying pricing dimensions to the associated dollars and reliably displaying it to customers.

After all we did to try to simplify billing, it’s been a relief to see how adept Metronome is at this—basically acting as an event ingest with a flexible pricing engine—plus the API-first infrastructure.

We’re now using Metronome 2.0 to work on more granular invoice breakdowns, which is basically an easy-to-read itemization of charges incurred by app. Soon, customers will see detailed spend per app, broken down by region, instance type, bandwidth, etc., giving them an easy view of what costs roll up to which app.

How have you been able to introduce new pricing models after working with Metronome?

We were able to quickly introduce region-based pricing on Machines using Metronome's dimensional pricing feature. Enterprise customers also have more options and flexibility than before, since we can now offer discounts on larger contracts and can even target discounts on, say, just the subset of machines they’re running in India. For legacy contracts, Metronome lets us adjust them as needed, without affecting everyone else’s rate cards.

We also now offer machine reservation blocks, where you get a 40% discount, spread over a year, when you pay up front to reserve blocks of compute time on region-specific performance or shared machines. We couldn’t have offered something like that before.

What’s been the most surprising learning since adopting Metronome 2.0?

I don’t think we fully realized how simple the flexibility Metronome 2.0 offered would be. That “one change to change them all” idea was a huge wakeup call.

The fact that you can distill everything into a single rate card and then price flexibly based on date-specific amendments makes usage-based pricing as easy as flipping switches. Our teams can now easily handle those targeted, enterprise-level contract discounts and adjust legacy contracts without even having to think about whether it’ll affect other customers’ rate cards. 

It’s also been awesome to see how much easier it is to launch, iterate, and move faster. We’ve essentially been able to give more power to non-billing teams, who can make decisions without being bogged down in how pricing is plumbed out. They can just plan, decide, and launch. If I’m honest, this was an operational obstacle I don’t think we even fully realized was blocking us, and it’s really sped us up.

Tell us a bit about pricing migration at Fly.io. How has that changed since partnering with us?

Pricing migrations are like the worst version of data migration, and there’s money associated with it! Worst case, you might make a mistake and either accidentally overcharge people or just lose money. It’s been great to worry less about that, since nearly everyone is billed on the same contract template in Metronome. When everyone’s tied to only one or two centralized rate cards, it’s much harder to screw up and much easier to avoid the complexity of having unique pricing arrangements for each customer. 

And I have to say that we’re fans of being able to model legacy plans in Metronome and migrate them when the time comes. Before, big changes like that could be a nightmare, but now it’s pretty much one change to change them all.

‍Besides clearer billing, what’s Fly’s next big focus to improve the customer billing experience?

More predictable, estimable costs from the start, for sure. We’re making it easier for customers to understand rough costs before they even spin up new resources. Some customers run businesses where pricing hinges on how much they pay us, so being able to estimate their Fly.io costs is critical. All the updates we’ve been able to implement with Metronome should really help people out there.

--

Interested in learning more about Metronome 2.0? Join us for our live webinar on November 20th at 10am PST.

‍