🚀  Manifold is joining Snyk! Read more in our announcement.

Flexible Billing the Dragon

It seems like marketplaces are the hot new thing to work on and every product, platform, and tool wants to offer their own version of a marketplace. In the world of add on platforms, apps stores, and plugins, etc, what qualifies as a marketplace in the digital world? A loose definition that I go with is a place where you can buy or sell goods, in our case digital goods and services.

The Challenges

Building a marketplace has its unique challenges. Manifold is a marketplace where people can find, buy and manage independent developer tools. Building and managing a* developer tools *marketplace has even more challenges.

Imagine having to accommodate 100 different businesses that all have slightly different business models and you want to integrate them all into one marketplace. Accommodating just 10 different business models is a big hurdle for a small team.

The Status Quo

An easy solution is to make everyone (all your partners) compromise and provide one billing model that partners adjust their business models to fit into. In fact as a service provider integrating into any marketplace (AWS, Elements, GH, Azure, etc), you’re expected to adjust your billing model to fit the one currently being used by the marketplace.

Heroku, a beloved developer company and current golden standard, runs a successful add on marketplace that doesn’t accommodate different business models. Heroku’s billing style are fixed monthly plans, for example $10/month, $20/month, etc. This model is used in many other marketplaces and for good reason, fixed monthly plans make it simple for users to understand. It also keeps the marketplace backend and UI simple to maintain. Imagine what a pain it would be for Heroku to adjust their backend and UI each time a new partner integrated with a different billing model. The fixed monthly plans also make a lot of sense for providers like Codeship CI that don’t require metering or volume based billing.

How do services that bill based on usage integrate? Services that bill based on the amount a user consumes and the bill at end of the month are not fixed. The status quo is for providers to create fixed priced monthly plans as a condition to integrating into the marketplace.

Locking users into a fixed price monthly plan does not provide a good user experience. Moreover, it doesn’t make sense for the service providers to change their billing system to a model that is inferior and different than their core business. For SaaS products that provide emailing, SMS, logging, etc, metering/volume based billing is how they normally run their business.

Creating More Plans as a Bandaid

To integrate into Heroku’s marketplace, providers (those who aren’t already billing fixed monthly rates) need to change their business models to a fixed monthly price which has backend implications for the provider. It limits the freedom their users have to choose which rate they want to subscribe to. To combat this, providers who bill based on usage create a lot of plans to extend the customization, but that adds cognitive overload for the user that’s buying. Creating more plans ultimately doesn’t solve the issue because there are literally thousands of permutations based on customer need.

Take a look at how many plans Sumo Logic (a logging service) created to bend their metered based pricing model to a fixed monthly price model.

Sumo Logic pricing plans on Heroku vs their native site

Sumo Logic pricing plans on Heroku vs their native site

When in reality, these are the pricing plans they offer with varying levers a user can adjust to get the exact plan that works for them.

Why Manifold Took on the Challenge

After talking to our Head of Product, Peter Cho, (he ran the Heroku marketplace!) who is very familiar with Heroku’s integrations and limitations, he let me know “Heroku didn’t fix this because it’s a dragon of a project”. There are probably many reasons why Heroku never prioritized building different billing solutions and I don’t pretend to know why. But I do know that for Manifold, it would be game changing to invest in new billing models.

The developer experience is important to Manifold and we want our marketplace experience for developers to be as good as, if not better, than signing up directly with our partners. Not only will our users get the same price and experience as with going directly to the providers, users will have a centralized place to manage all these services together.

A secondary goal of accommodating more billing models is for Manifold partnerships and integrations to go smoother. No more adapting to Manifold’s fixed billing model. No more turning away providers because our billing models don’t match up. Investing in more accommodating billing models directly add to Manifold’s bottom line (via revenue share) because it will attract more providers and users. Developers are a tricky group of users to get feedback from. But if there’s one thing I’ve learned from customer interviews, it’s that developers want choice. The more services we’re able to add to the marketplace, the happier it makes our customers. It’s a win-win.

The Approach

I conducted customer interviews with our existing partners as well as new ones to understand their pains integrating with Heroku, while reviewing hundreds of developer tools to gauge the most common billing models.

After understanding the top business models, I talked to Tim Speed, our tech lead, to get a rough estimate of the lift required to build something that would accommodate essentially three more billing models. I needed a good understanding of how the API integrations would work and leaned heavily on Tim to write the technical backend requirements.

It’s not enough to build good UI for a good customer experience, we needed to make API integrations that made sense to providers and weren’t a giant pain to integrate with. This project pushed me to become much more technical and well versed in understanding Manifold’s integrations.

Lastly, I worked with our design team to create a UI that would still be simple to understand for our users despite the complex backend implementation. These designs were tested with users as well as our partners to ensure we built something that was aligned with how providers envisioned their products.

Working Directly with Our Partners

I involved an existing provider (John from JawsDB) and a new provider (Blitline) early and often to test and iterate on our billing models. John is the most successful partner in the Manifold marketplace and the perfect candidate to inform our custom billing features.

JawsDB’s pains

JawsDB plans have configuration parameters for a number of connections and GB of storage. A pain point John deals with weekly is users asking for plans that aren’t displayed for their specific unique need. John is able to accommodate these unique plan requests by creating new plans in the backend.

On Heroku, John solves this problem by creating new, hidden, plans based on his customers’ specifications. He would do this every time a user asked for a plan that was slightly different than what was listed on the plans page.

It’s a big pain in the butt for John and a lot of work to manage each time a user asks for a bespoke plan. More importantly, it’s not a great user or provider experience. John also offers add-on features like a backup database that’s an exact replica of the user provisioned database that syncs. This is an add-on feature that users ask for and John can accommodate on his end. Yet with the current fixed plans model, there is no way for him to sell this add-on feature.

Blitline’s pains

Blitline’s plans on Heroku are completely different than what they actually offer. For a provider like Blitline, our system had to support a monthly subscription plan price in addition to an hourly metered rate and a volume (what they call ‘imagga’) metered rate. The hourly and volume rates are different and change based on what plan a user subscribes to. Blitline was a perfect candidate to test our new metered solution.

It was important to me that we built a solution that met our provider’s needs but was also a solution that was reusable for future integrating providers.

Three New Billing Models

I boiled down the most common billing models into three new models in addition to the fixed monthly plans we already handle.

1. Metered:

  • Time based (Cost per different interval second/minute/hour/day and prorated)
  • Volume based billing (Cost is based on volume of something, emails, storage used, API calls, etc)
Metered billing
Metered billing

2. Customizable features:

  • Monthly plans with customizable features (Subscribing to a 1 user account plan that can either have 10 GB/20 GB/ 30 GB of storage. Storage is the customizable feature in this example)
Custom features
Custom features

3. Plans and metering:

  • Base price subscriptions that have metering component(s)
  • Multiple metered components (Products that metered multiple components at different rates. For example Ziggeo bills for recording, storage, and streaming all at different rates that add up to a total at the end of the month)
Plans with metered features
Plans with metered features

Working closely with Tim we came up with a two month plan to build out the backend and frontend to accommodate these new models, with built in buffer time to get feedback and iterate on our implementation.

An example of the information we collect from providers during the integration process
An example of the information we collect from providers during the integration process

Two new API endpoints were created to accommodate metering of services. The first endpoint is for providers to connect to Manifold in order to set how much a resource has used of its features during a period of time (push). This endpoint is still in Beta and optional to implement. The second endpoint is for Manifold to call upon daily to get usage information about a resource and is mandatory for providers offering metered plans (pull).

While metering needed new API endpoints, custom features required an expanded list of data we collect upfront. We collect this data from new providers in order to set up their plans in our database. Custom features also required more of the feature information to be sent between Manifold and the provider each time an API call is made. See the custom plans portion above.

The Resulting UI

I wanted to make sure with four total billing models, our UI didn’t become complex for users buying these products. Especially with the ability to customize plans, users can get stuck in the Paradox of Choice. The goal is to show fewer plans, therefore creating less cognitive overload, but still provide more plan options than before. We believe this will significantly improve our user experience. At the very least, the experience on Manifold would be on par with buying directly from our providers.

After five iterations between product and design, we ended up with following UI for metered based billing as well as plans with customizable features.

UI for custom feature billing (1, 2) UI for metered billing (3)

UI for custom feature billing (1, 2) UI for metered billing (3)

In the metering section, you can see the UI is simple. We’re letting the users know the rate per x item used and showing a cost estimator so users can gauge how much money they would be spending at the end of the month. The goal is to be as transparent as possible without overwhelming them with information.

The UI in custom features is sleek and remains simple. We display custom features as a ‘plan’ so it blends in nicely with the existing UI. In order to make iterative changes and to keep scope small for both Manifold and providers, I decided to keep existing plans as is and to only add one additional ‘custom plan’. In order to create a custom plan, users choose one of the existing plans (dropdown) and can customize certain features within it (sliders). We’ve also intentionally placed the custom plan as the last choice because it’s an option for those who didn’t find what they need after reviewing all existing plans.

We’ve included a check box for scenarios where a user wants additional add-on features (a replica database for JawsDB’s use case). Massive shoutout to Meg Smith for the product design work.

The End Result

We’re still in the process of testing and iterating on these new billing models. What we do know is that we’re in uncharted territory. We’ve built an integration that doesn’t exist at Heroku. We have JawsDB running on the custom features billing model. We have Blitline integrated to our metered model. We have Ziggeo currently integrating into our plans with the metered features model.

We have many providers in flight and we’re getting a lot of great feedback. With each new integration, we learn where our gaps are and it gives us a chance to iterate towards a better model.

While I know the new models we’ve created still won’t fit 100% of the use cases, we can see that there are providers currently integrating with us that wouldn’t have been able to integrate otherwise. There is still a ton of work to be done and many areas for improvement, but we’re off to great start.

🎉 Dope illustrations by Meg Smith 🎉

Recent posts

Related posts

No items found.