Pricing, billing & open source: A chat with Algolia's co-founder

Algolia is the leading Search-as-a-Service company that powers search functionality for companies including Atlassian, Slack, Staples and Under Armour.

Algolia's latest valuation was $2.25 billion in 2021. Its revenue had increased by 180% the year before the fundraising. This is partly due to a rising post-pandemic demand and to a radical shift to usage-based pricing.

We sat down with Algolia’s co-founder and founding CEO Nicolas Dessaigne, who’s now Group Partner at Y Combinator, to discuss billing systems, pricing and open source.

‍

What did Algolia’s pricing look like when you launched in 2013?

As most early stage companies, we had no clue about what our pricing should look like. So we took inspiration from what was on the market back then and tried to do something that was attractive enough for early adopters.

We ended up with three plans, from $49 to $299 per month with different quotas. We also had an over-quota price to avoid forcing people to move to the next plan if they had low overage.

‍

How did you build your billing system at the time?

We created our home-grown billing system. There was nothing on the market that really worked well for the overage component, so we decided to build our own invoicing system and integrate with the Stripe API directly without using their subscription feature.

To be honest, we also underestimated the complexity of maintaining a billing system.

‍

How did your pricing evolve over the years? Why?

We iterated a lot on our pricing, from small iterations that were mostly about individual plan prices and quotas, to major ones where we changed the full structure of our pricing. At some point for example, we decided to stop charging for search queries. Indexing was our major cost and we thought that by making searching free, we would encourage customers to better leverage the product. It turned out to be a very bad move.

What matters is not your costs but what your customers value. And in our case, the vast majority of people value search and don’t care about indexing. Later on, we decided to move to a full usage-based pricing. No more tiered plans. You can access all features from the first dollar. It’s aligned with the expectations of technical buyers and makes the adoption of value-added features easier.

‍

Did you upgrade your billing system accordingly? How?

Yes. At the beginning it was relatively easy. Our VP Engineering had built the system and would update it when necessary. As we scaled, however, it became a nightmare. We always grandfathered our customers so we had to maintain many versions of our pricing in parallel.

In addition to this, as the company grew, the Finance team had more and more requirements, which added to the complexity. Usually, you don’t want to change the past, but if we canceled an invoice that had not been paid for instance, this would update our past MRR.

‍

Would you do it differently today?

I’d probably think about it twice. The initial billing system might be easy to build in-house at the beginning: at an early stage, pricing is simpler, your internal tool stack is limited and you might only accept card payments, using Stripe Payments for instance.

As you grow, everything gets harder: more products, more internal tools, more payment channels, more cash collection challenges, more people in the team (you need to manage permissions and keep a log history). Building a home-grown billing system means committing to maintaining it for the long term, as any of your products. It can quickly become a distraction from the core business.

Also, as a CEO, it also means more effort to get reporting right. I spent a lot of time on this when we were raising funds for our series C. Just picture the situation: leading the company, fundraising at the same time, and working on the many tiny and tedious details of reporting with the Finance team. If you can spare the extra workload for your Finance team, and the extra stress for yourself, do it.

Unless you have a passion and a lot of experience in billing, find a solution that is flexible enough for you and that will develop and maintain the features you need in the future. There are now solutions on the market that didn’t exist when we decided to develop our billing system by ourselves. I would definitely evaluate them.

‍

Have you ever explored open-source options for your billing system?

I had not heard of any open-source solution before Lago.

It might even seem a bit counterintuitive to open source a billing system, as it’s not a ‘pure’ engineering tool: for a data sync tool or a search API, beyond cost considerations, the Engineering team is the only decision-maker. For a billing system, nearly every person on the Executive Committee has a say, or at least the CEO, CFO and CTO.

I like the idea of  ‘open sourcing’ a billing system as it helps cover the long tail of edge cases by adding composability and allowing for customizations.

‍

As an investor, are you concerned about the monetization path of these tools?

Not really. There are many ways for an open-source company to monetize its product. It can offer a cloud version of the product that is hosted by the provider and updated automatically, making it more convenient to use.

The company can also monetize specific value-added features in an ‘open core’ model. This usually means that while the main product is open-source and can be used for free, some premium features are not. It’s particularly relevant for ‘enterprise’ customers and features like granular access control, single sign-on, etc.

It has become a popular playbook and has been used by companies like PostHog and Strapi.

Thanks to Nicolas Dessaigne for his time and for sharing his experience with us.