Pricing & Positioning

Going Usage-Based: How Algolia Built Their Most Customer Friendly Pricing Model Ever

March 22, 2022

Since Algolia’s founding in 2012, we’ve had eight evolutions of our pricing model. 

In the early days, we took a “Good, Better, Best” type of approach, where the difference was the amount of usage you had access to. At first, there was zero feature gating. This early usage-based pricing (UBP) model was product-led growth (PLG)-friendly even though we didn’t know it at the time. 

We started Algolia as an API platform to allow builders to develop their search and discovery experience. Established in 2012 in France, we have since expanded to more than 630 employees in 10 countries with 12,000+ customers. We experienced a massive acceleration of the business in the past year, driven by a combination of product-led and sales-led growth. A key factor in our growth acceleration: a new usage-based pricing model. 

The rise and fall of product-led growth

Our initial product-led strategy was a huge engine for growth in the beginning. Developers saw a lot of value in the product and drove adoption in their companies from the bottom-up. The downside of our pricing model at this time, however, was that larger companies would end up paying a lot less for their use case compared to the value they extracted. We were in hyper-growth mode, but from a sales standpoint, we were missing opportunities. In order to share in more of this value that customers experienced from Algolia, we turned to feature gating.

By 2017, we had adopted an extreme feature gating approach, where practically all of our innovation was reserved for our enterprise plans—our highest paid plans. One of these features was personalization, which had been really popular among all customers—especially e-commerce accounts. But in this highly-gated model, it was only accessible behind a “contact us” form and an expensive price tag.

Algolia’s old pricing model with feature-gating

Algolia’s old pricing model with feature-gating

We closed larger and larger deals with this pricing model—which was good for sales, obviously—but our leads pool and goodwill in the community took a hit, as developers lost the ability to get their hands on the best parts of our product and consequently were unable to appreciate the value themselves. They weren’t seeing our innovation because they weren’t able to try it for themselves.

Our journey home to the usage-based pricing model

Our bottom-up approach is what initially fed the growth of our sales engine. Our product was, and still is a technical one, and we relied on technical champions to vet the product and push it internally. 

When we implemented this extreme feature-gating strategy, we virtually killed that motion—plain and simple. We had forced ourselves into a largely sales-led growth model, and we had no choice but to go outbound to our business personas without the initial support of a technical champion. 

In 2019, we made the decision to revert back to our UBP and PLG roots and to lean into the model even harder than we had in the early days. We saw that other companies were approaching a developer audience with a pricing model that gives access at a very low entry price to all the features of the product—no gating, no commitment.

This is a developer-centric, bottoms-up approach that encourages advocacy among technical champions: This is the philosophy that went into the redesign of our pricing.

In 2020, we launched the most customer-friendly pricing model in Algolia’s history.

Aligning on the problem from a user perspective

The process to decide and align on a new approach to pricing was a long and arduous one. When we initially discussed pricing internally, we heard 20 different versions of what the problem was. The sales team saw very different issues compared to what the customer success team saw, and they saw something totally different compared to the engineering team. Nobody could offer a crystal clear diagnosis.

We started with user research to determine what problem we wanted to solve with pricing. We talked with customers about their experience when using and paying for our product, and many shared that they were upset with having to pay a specific price to get access to the features they wanted. 

Our research revealed that our product features fell into one of two categories: 

  1. Features that made sense for all customers, including certain use cases: personalization and A/B testing
  2. Features that only made sense for enterprise customers, such as SSO and enterprise security & compliance.

In our model at the time, features that made sense for all customers were put at a premium—and the price of that premium wasn’t accessible to many of the customers who needed them. On the other hand, for features like SSO and enterprise security, customers were fine with having them only in the premium plans because these features only made sense for enterprise companies that needed them and could afford that price point.

To address the issue of enterprise-specific features, we learned from Twilio’s example: You carve out what is essential for large companies and you make it a SKU of its own. Not only does this address the needs of the enterprise customer, but it also mitigates risk for Algolia’s sales team. For enterprise or new market salespeople, even if an account doesn’t have a lot of usage, they can start with this enterprise foundation that includes all necessary enterprise-specific requirements. Having this SKU as the floor is reassuring to sales teams—they know that no matter what, they can pitch it. 

So far, the enterprise SKU has worked out really well. Our retention on the enterprise SKU is extremely high. This tells us that we packaged it the right way, even though the core product is not part of the enterprise SKU itself. 

Building a developer-centric usage-based pricing strategy

The idea behind taking a usage-based approach was that at scale people should pay the same price as before, but that they should be able to start out in a more affordable way. It’s not so much that we made the product cheaper—rather, we made it easier to try and ramp up with.

To accomplish this, we developed our new pricing model around the following five principles:

  1. Remove friction for ‘try and buy’: Customers can start for free and select more options from pay-as-you-go plans starting at $1 per month, no long-term commitment required.
  2. Increase access to innovation: Several advanced features, such as query suggestions and A/B testing, are available with the standard plan, whereas in the past they were only accessible to enterprise customers. Features like personalization and AI-based reranking moved to plans with a higher price per unit. 
  3. Make pricing transparent: Pricing is simpler ensuring invoices are predictable and easy to understand.
  4. Charge only for what is used: Customers pay for units of value, which are determined by search volume and size of their indexes. Customers can either pay for their exact usage on a monthly basis or receive volume discounts with an annual commitment. 
  5. Encourage customers to grow: By offering volume discounts, customers are incentivized to increase their usage. They can cost-effectively scale as their business grows. 

Algolia’s most customer-friendly pricing model

Algolia’s most customer-friendly pricing model (screenshot taken March 7, 2022)

For the executive team, following through with this change took a lot of courage. Even when we mapped out the change to the existing user-base, there was still that looming worst-case scenario. In our case, we chose to allow existing customers to retain access to the old pricing. So in our case, if you calculate the worst-case scenario of people optimizing for cost, there was a potential risk for the business. But we also know that calculations don’t always align with what is seen in practice. At some point, you can choose to either drown in analyses and projections or just take the leap of faith. 

Algolia leapt. 

The percentage of existing customers that moved by choice to the new pricing was a key metric of success for this project – with a significant percentage moving immediately. We didn’t force them—our customers were clearly seeing the benefit of a simple, usage-based pricing model tightly aligned to the value they attained. Our approach to grandfathering existing customers proved to be a great strategy for retention—we regard this as meaningful proof of success.

Integrating a sales-led approach with product-led growth core

Adopting UBP didn’t mean abandoning our sales-led motion. In fact, taking a PLG approach allowed us to optimize our sales-led approach in areas where it has the most potential for success, without having to rely on it as our only source of leads. 

For certain use cases or certain industries, we lead with our extremely effective sales-led growth (SLG) engine. We have a propensity model that works really well and we also have predictability on commitment. 

Where we connect the two models is with the customers who have onboarded on the PLG model and who aren’t typically represented in our ideal customer profile. We enable them to grow slowly and at their own pace, and when they cross a certain usage threshold, there’s something in it for them (along the lines of a volume discount, or SLAs) to discuss with a salesperson. 

PLG should feed our sales team and, it’s an investment for the future. The PLG-based customers we’re developing today will be a major pool for the sales team to tap into in the future. 

Takeaways for PLG success

We were a PLG company initially, then we became hooked on chasing bigger deals. Now, we’ve circled back to our PLG roots and have been reinvesting massively in it. We’ve improved our onboarding process, built a team dedicated to product-led growth, and addressed points of friction in the self-service part of the business. Suffice to say, it’s been a journey and we’ve learned a lot along the way:

  • Don’t pursue growth at all costs. It may force you to make decisions you’ll come to regret. If you want to build your sales team and SLG model, don’t do it at the cost of your PLG model—especially if you have a PLG engine that’s working. And especially if your product has the potential to be extremely broad in terms of use cases.
  • Take the time to do UBP right. From conception to launch, changing our pricing model took a little under a year—we started research in October and launched at the beginning of July. We needed to change the service order, billing system, and pricing page, and train the support and sales teams. Just the implementation before ‘go-live’ took weeks, and there wasn’t a single team that was not impacted. 
  • PLG has to be the mindset of everyone in the company. The goal is to maximize the experience of the product. Everyone should be thinking about volume, motivation, and ways to make the product better. To make this shift, you might need external people who can progressively challenge the mindset of your internal teams. 

Remember that PLG is a long-term game. When you move to a usage-based model, it will take time for new customers to ramp up their expenditure. If you are coming from an SLG business, revenue per customer might appear small compared to what you were doing before in terms of landing big customers. Be patient. It will pay off.

DON’T MISS: Join Kyle Poyar in his session How to Scale with Usage-based Pricing at TechCrunch Early Stage 2022 on April 14.