How to get a headless product to $100m ARR

How do you go from developer and founder of an API, IaaS or dev tool to $100m ARR? What are the biggest surprises and hurdles to get to market? What can you learn from Heroku, Github, Algolia, Tokbox, Layer, Greta.io, Timekit, and maybe even me?

The world is breaking apart. And, not in the way you think. I am talking about Infrastructure as a Service (IaaS) companies. Gone is the world of a massive monolith of self-written code hosted on your machines. Layer by layer is being peeled off from underneath. The peel continues, like a Brit after the first summer sun, and the opportunities to build startups are amazing.

How do you go from a product to a massive revenue IaaS company? Here are the five biggest discoveries you need to figure out and my three recommendations.

“At our series B, we got lots of questions about revenue. Previously we were advised to focus on getting massive amounts of active developers. Now we had to figure out something quickly."

—Tomaž Štolfa, Layer

Discovery #1: Your customers are nothing like you

Very likely you are a developer if you build an IaaS and you want to talk to and help other developers. It is great to see people sign up for the service you are building and chatting with them. But sadly, these people are not the customers you want. Why?

1. Developers think they can build it themselves. But love playing with things. A lot of false positives regarding sales signals.
2. Developers view their time as free, and don’t realize what it is worth. What you are charging sounds expensive to them. (And, you really crave for their praise.)
3. Developers don’t have a budget for services, but for people. They literally can’t buy your service.

You have to find who would get promoted for buying your service. Is it someone in marketing? Or a product manager? Or the CIO?

“Who would get promoted for buying Layer?”

— Tomaž Štolfa, Layer

What is that person’s business needs? Is your product essentially replacing the cost of one developer per year? Or, do you decrease load times and increase uptime and therefore increase revenue? Or can you improve analytics which allows the marketing team to be more data driven?

Companies are driven by profit, although we’re sometimes tricked into believing otherwise in the startup world. Therefore, you can only become important to them by improving that profit, meaning you either increase their revenue, or decrease their cost.

Discovery #2: Are you need to have or nice to have?

It sounds great to be a vital part of your client’s business. To be core, not context, as it is called in business tongue. If you are not then customers might not pay you much or even bother. Not a problem if the setup is self-service and costs are less than $50 per year. But if you want to charge $25k per year you need to show not only why they can trust you, but why they shouldn’t build it themselves.

“Inhouse competition was always the problem with the big corps.”

— Scott Chacon, GitHub

The best ways of staying relevant is doing one of two things:

1. You need network effects or advantages of scale. Showing that the other customers are providing value to the customer in question. The most obvious is splitting the costs, but usually when things are core enough, then some cost savings are not that important. Instead the system should get massively better with a lot of users or concurrent usage. If you are building an ML system, the interactions others are doing trains the system. If you are a CDN, then the nodes you set up are utilized by everyone.
2. Continually raising the bar. Maybe the customer can build their own thing, but like the tortoise and the hare — when they have reached you, you are much further ahead. The market is moving faster than they can, and only you who specialize and is part of defining the future can keep up. This was the playbook at TAT. Often startups can recruit competence that doesn’t wish to work at big corps, so you can push the envelope when the customers are playing catch-up.

“I wished that we earlier realized that we ought to interact with clients based on potential, rather than of need.”

— Janine Yoong, Tokbox

Be very close to customers and potential ones who you are core for even if they can handle things themselves. Some of your best clients might refuse you give you insight into how they are using your product. You still want to stay on top of their demands and make sure to know what internal projects they are benchmarking you against.

Discovery #3: Pareto Revenue

Almost every company I know have whales — a small number of clients who make up the majority of the revenue. The top 20% accounts constitute more than 60% of the MRR. Those who survived realized that the pricing plan shouldn’t be Free, $299, and a $699 enterprise plan. The highest clients will pay five-figure numbers or more per year.

“The one thing that stands out is that founders charge too little!”

— Chris Janz, Point9 Capital

It is often a heart breaking moment for developer founders to ask themselves “Is Enterprise a serious part of our revenue or are we a community play?”. You don’t feel equipped to handle these sales conversations. Luckily for you, there are good books on the subject.

Big deals might not be huge in the beginning. The strategy is often “land and expand.” Begin with a proof of concept, than an internal use case, move on to being one feature or region, and so on.

“We start by asking in what region they want to test the system. It becomes a smaller decision and gets them up and running quickly.”

— Anna Ottosson, Greta.io

But big clients will need handholding or even integrations done. You might need to build a professional service team even.

I have a simplified rule of thumb for different contract values:

• $50 per year is self-service. People are not names but cohorts. This is rare for headless companies.
• $5000 needs setup calls but no special features. You know the company and their problem, but maybe not the org structure.
• $50k is all about customer intimacy. Do bespoke services, customer teams, and setup “success KPIs” for every onboarding.

Discovery #4: Tiers are complicated

A lot of tech founders just want to get their product out there and in the hands of other developers. First, you start with a free tier. Then you realize you need monetization and add paid tiers. Most headless companies can’t make $100m ARR if they don’t have very high priced tiers. But apart from that, what should you think about?

1. The Free tier

As long as you don’t have high costs for using your service or a very complex onboarding, I think you should try to have a free tier. If there are costs then you can have a free trial at least. What are the reasons for a free tier?

• “Free users will upgrade over time.” Sadly this is not true. Regarding sales and self-service, free is not functional. For the reasons mentioned above, but also because there is little movement between tiers. Free is not sales, but if done right it is marketing.

“When we went into YC we removed the Free tier. It didn’t really have any impact on sales. It was an overrated topic.”

— Gaëtan Gachet, Algolia

• “Free users will help and give feedback.” Very true when you are getting started, but sadly getting feedback from developers is almost as hard as getting it from Japanese customers. You will always need feedback; in the beginning on the problem, later on the solution, and then on the documentation and finding bugs. But that doesn’t mean it is a business model.

“As the first employee of Heroku, I spent 40% of my time as an evangelist and 60% on coding. If there was a Ruby event in Montreal with three attendees, I was sure to be there.”

— Blake Mizerany, Heroku

• “Free brings us leads to then sell to.” Yes — this is true and stays true. But you will have to sell to them.

“I hate startups whose tech you can’t just try out, but have to talk to a sales rep first.”

— Scott Chacon, GitHub

• “Free fends off competition.” Yes — when you are established, free acts as scorched earth tactic towards newcomers.
• “Free shows how easy the product is to use and integrate.” In the beginning, this is really important.

“By providing a free version we remove the barrier to get started and explore our technology.”

— Anna Ottosson, Greta.io

2. How to design tiers

So, we need the free tier, but then what about the rest? There are two main ways, dependent on how your product works. Either you have feature-based tiers, or you are paid by the meter — for storage, traffic, or some kind of volume. Whatever you do: have few tiers, make sure they are simple to understand, and costs are predictable.

Feature-based tiers

Ideally, there are only two paid tiers; one which can be handled over the phone with setup meetings, and one which will need some professional services or substantial interaction.

“When we started living with our biggest client, life got a lot easier.”

— Jesper Klingenberg, Timekit

Put the “sophisticated” features in the more expensive tier, even if it already is there implemented from a product standpoint. Things like using the API on your own — even if that works out of the box it will demand a lot from your customer success team. Compliance, guaranteed uptime, more service, etc. are all in higher tiers.

A lot of time we make the higher tiers more flexible instead of learning what those use cases really are. Compensate your flexibility with customer intimacy as your product becomes more vague and harder to understand. Setup professional service teams or just work in close cooperation with the big clients.

“Product development was too much focused on flexibility, instead of monetization. Biz dev people should be stakeholders in feature planning.”

— Janine Yoong, Tokbox

With feature-based pricing, you will leave money on the table. Some of the biggest companies in the world will settle for a lower tier and not the “Call us” one. You know that you could increase the price for them. But resist the temptation to add tiers in between to solve this.

Volume based tiers

Volume feels so easy — if you use it more, you pay more. But with volume based pricing comes other problems. The first one is that you take the risk and cost of the onboarding without knowing how much you will make.

The second is that some of the customers that get the most value, might not have the biggest volume. If you are a messaging service, you drive revenue for an e-commerce business but are not a revenue feature for a dating service. Another problem is that ambitious people believe their company to be the next Google so when they look at what your service will cost in two years, it is worth building it on their own.

Both are usually best solved with platform fees, because people don’t like minimum bundles of usage if they don’t understand how much they will use.

“When we introduced minimum bundles, people pushed back saying ‘what if we don’t use all that traffic?’”

— Tomaž Štolfa, Layer

The platform fee covers the onboarding and filters out the false positives of people who later don’t want to pay anyway. In the fee, there is some volume, but then you charge that by the meter. You can have a unique platform fee for every tier and will look just like any SaaS pricing page.

Secondly, you want to show how increased usage increases the benefits. Ask yourself “What can I build into my product to incentivize the real clients to use it more?”.

Discovery #5: Your solution needs to be more tangible

When you are building infrastructure, API services, or anything “headless” you need to figure out how people can see and relate to what you can do. As Clayton Christensen says “People don’t buy drills, they buy holes.”

There are a couple of ways to become tangible — get credibility, data, or testimonials:

1. Make a portfolio of demos or concepts.
2. When a potential client approaches you, build a proof of concept for them. Work with the developer or champion at the client to build “internal ammunition” and ask for a call with the decision maker.
3. Build an app on top of your system. But this is a slippery slope if you want to be a $50k company. You might turn into an application and become less flexible and therefore move to a $50k per year company which is another sales strategy and requires different team DNA.

“We built PoCs for a lot of potential five-figure deals, even when they hadn’t asked for it.”

— Gaëtan Gachet, Algolia

At the end of the day: Do not underestimate how hard it is to understand what can be done with your amazing technology. You are not spending a tenth of what you should be on communicating. What are you solving and for whom? Educate them on the problem.

My recommendations

1. When you have figured out that you can solve a significant problem, ask yourself how to get to $100m ARR. Is it 100 companies paying $1m or a million paying $100? Or what is the mix? This defines everything, so do the math. Are there enough companies around that will buy your product — or is your product critical enough to pay that much for?
2. What is the profile of that kind of customer? What business value do you bring to them? Are you context and just something they need to fix and move on? How do you get them to find you and get up and running without interacting with you? Or is this vital to them and they are happy to pay you a lot? How do you stay relevant and aren’t replaced by an internal solution?
3. Who are the people at the other side? Who will be promoted from buying your solution? How do you drive their business KPIs? Who is the user and who will set it up? This defines your customer success team or need of professional services.

If you are building a company in the space, I’m of course happy to chat!

Thanks, everyone who talked to me and helped me figure this out: Jesper Klingenberg, Anna Ottosson, Tomaž Štolfa, Scott Chacon, Janine Yoong, Gaëtan Gachet, Christoph Janz, and Blake Mizerany.