Infura's New Pricing Plan

Exploring revenue channels

There were three primary problems Infura was facing when I joined this project:

1. Macro-economic shifts and internal pressures due to lack of revenue improvements.
2. Feature parity with key competitors who already transitioned pricing models to compute units.
3. Blind spots where users were able to create unlimited free accounts.

‍

The proposal

I was onboarded to this project mid-way through due to strategic reorgs in early 2023.

Previously, Infura was basing its pricing model on requests made per API key. This allowed users to pay monthly based on the requests package that best aligned with their needs.

The proposed solution was to: 1) migrate existing users to a compute units based pricing model, and 2) bill users based on how much compute units they've used per billing cycle.

Why is this proposed solution beneficial?

• Pricing model aligns with industry standards. Establishes familiarity for users when comparing node API providers.
• Creates room for up-selling to achieve customer conversion from free tiers to paying tiers.
• Opportunity to improve outdated UI and flows using new component library.

What are the risks of this solution?

• Product decision based on market trends and analyses.
• Difficult to fit user research due to project confidentiality.
• Rollout timeline & user migrations.
• A lot of stakeholders involved.

‍

Design process

Define

Since I was onboarded post-project kickoff, I spent the first week gathering context & understanding the problem and business goals.

User stories:

• As a new or existing Infura user, I want a billing system that charges based on compute units so that I only pay for the resources I use, ensuring transparency and value alignment.
• As a user on the free tier, I want insights into how compute unit pricing works so that I understand the benefits of upgrading if I exceed free-tier limits.
• As a user, I want a more intuitive billing dashboard so that I can easily monitor my compute unit usage and avoid unexpected charges.

Design

First iteration

Early feedback

Opportunities for improvement:

• Pulling number of methods used across API keys from our database might introduce complications.
• What would an empty state look like for a new user without any existing data?
• Something to note: billing cycles differ across userID's (accounts).

What's going well:

• Empty state card is a great opportunity to up-sell for tier conversion.
• Some new design components in local file can be used to merge into main library.

Second iteration based on feedback & edge case considerations

‍

Refining designs

While refining the designs, I continuously advocated for user testing high-risk designs and flows. Due to the confidential nature of the project, my request for testing was not approved. Retroactively, I realize now that we could've tested internally. Within my responsibilities, I delivered:

• A redesigned payment page.
• A redesigned + reorganized billing tab with relevant usage data.
• Improved visual signifiers for alerts, nudges, and loaders.
• Billing management flows.
• Components to a/b test up-selling metrics.
• Separate usage analytics dedicated to compute units breakdown.

Rollout plan

There was a three-phase release plan, each with sub-phases. This was mainly due to:

• Backend considerations when migrating existing paying customers.
• Migrating from old payment system provider to new provider.

‍

Challenges

1. No research: I considered a high-risk and XL-effort project. We were putting a big bet on new designs without getting user feedback.
2. New product manager: A new PM joined mid-project due to business functions changing in mid-2023.
3. Delayed stakeholder sign-off: Finance team sign-off was a bit delayed due to OOO's. Their approval was a requirement for this project to proceed to rollout.
4. Top-down decisions: Phased releases were decided by the product team as designs were near-done. Design was involved too early, in my opinion.

‍

Packaging design files

During July 2023, I left Infura to join MetaMask's account abstraction initiatives.

To guarantee a smooth transition, I set up a time for design handoff files to my junior designer partner.

What happened to the project?

• Released in late Q2 2024.
• A new designer (not the junior designer) had inherited the project.

‍

Lessons learned

• If you can't research with existing users, find a way to validate high-risks designs internally. Or behind a feature flag.
• Visual delights and color theory are underrated and underestimated when it comes to "good UX."
• Call it out early and often if design is being pulled in too soon.