How I monetized my invisible product

Give me $50, and I’ll give you a product you can’t see, touch, or evaluate. 
 
APIs, dev tools, and even infrastructure-as-a-service are all “invisible” products. There’s no user-interface to show off in an ad and no tagline that succinctly sums up everything that the product can be used for. That means there’s a huge time and attention commitment required from potential customers to understand what your product is even capable of.
 
So unlike with traditional businesses, you can’t start with a product and then look for a market. There are too many hurdles to get over to put your product in front of a customer. With invisible products, you have to start with a market. You need to find an unquestionable need for your service.
 
A few years ago, I stumbled upon one developer’s need on Stack Overflow. He was trying to customize his webpage, so he was looking for a way to fetch the location of a visitor based on their IP address. I built an API in response to his question, posted it, and only months later found that hundreds of other developers also found my tool useful.
 
I had accidentally discovered a need. The next few years, I looked closely at usage and iterated on pricing to determine exactly whether that need was big enough for me to quit my job. By running experiments and shaping my pricing around what my users were doing, I was able to build a business around my API product.

MVP Pricing to Test the Waters

The unsexy truth is: I didn’t go out on a limb and take a huge gamble on IPinfo. I eased into the business slowly, by testing exactly what developers would be willing to pay for. 
 
My first clue that I had something useful was when I got an email alert from Linode. When I looked at the usage, I saw that my API was receiving over 250 million requests per day. This showed me people were interested in the product as a free tool — but it didn’t give me any indication of its value. From there, I looked at how many requests were coming from each IP address, so that I could test paid plans on a small number of users. Then, I launched a tiered pricing strategy that I iterated on for the next two years.
 
By the time I finally started working on ipinfo full-time, I already felt confident that I had a viable product I could monetize. 
 
There were three components of pricing that I tested, in order to find the best way to monetize my product:

• Testing freemium. How many people were interested in my API in the first place? And how valuable is it to them — how many API calls are these people making per day?
• Testing price points. Are the people using this API hobbyists, or are they huge businesses with steady cashflow? What should the distribution be like to allow for both?
• Testing packaging. What should each pricing tier include? How many requests per day? Should it be per app or per customer?

Going through these tests helped me determine whether there was a market, and gradually understand just how big that market was.

Testing Freemium

IPinfo was free for the first year because it didn’t even occur to me how useful it was to developers. I built it thinking that people would just use it for a side project or a hobby, making between 100 and 1,000 requests a day. Once I got that warning email from Linode, I decided to take a closer look at usage. 
 
Looking at the number of requests per IP address, there were two few notable metrics:

• 95% of people were making less than 1,000 requests a day
• The most active 1% were making over 100,000 daily requests

This presented a perfect opportunity to test whether people would pay for my service, without disappointing the vast majority of developers that rely on ipinfo. I kept 95% of people on a free tier, and created four additional tiers for the rest:

Up until 1,000 daily requests, developers could use IPinfo without any sort of commitment. No credit cards, no emails, no anything. This ensured that, as I introduced paid plans, there was no friction for the majority of developers using ipinfo. The option to upgrade now existed, but it didn’t compromise the experience for the vast majority of people. 
 
These paid plans would either discourage high-frequency users from sticking with IPinfo, significantly lowering the costs for supporting all those requests — or they’d prove that people actually derived value from the product. Best case scenario, I could monetize the high-frequency users and keep working on making the product better for everyone. 
 
When there was only a slight drop-off after I set up the paid plans, I knew I could turn my API into more than a side-project.

Testing Price Points

Once I had decided to offer paid plans, I needed to pick price points. At that time, I knew very little about the developers using IPinfo, so I wanted to make sure the tiers encapsulated as many different kinds of buyers as possible. This would give me a starting point for gathering data that wasn’t based on any assumptions — and I knew I could always tweak and focus on a particular section of the market later. 
 
I created four tiers to start: $10, $50, $100, and $200. The $10 tier was meant to capture developers who are working on a side project, but, perhaps, are starting to dedicate more time and resources to getting it up and running. The $200 tier was meant to capture businesses that require this API as an integral part of their application. 
 
My hypothesis was that the distribution across tiers would be skewed to the less expensive plans — that more hobbyist developers would use the API to create an MVP for their side-projects. 
 
But once I launched these tiers, it turned out to be quite the opposite. Developers on the free tier hesitated to switch to a paid plan, but many other customers were immediately interested in our most expensive plan. Tesla, one of our first customers, signed up for the highest tier immediately. 
 
Within a few months, I had to add a tier to capture more upmarket customers:

As I looked more at usage and got to know more of our customers on a personal level, I ended up adding yet another tier:

If I had based my pricing plans on how I thought developers would be using my service, I would have made the plans much less expensive — a $10, a $25, and a $50 plan. But by keeping the range large, I was able to get more data, and get a better understanding of the types of customers that had a need for ipinfo.
 
In retrospect, the actual price points were less significant in the long-term than the fact that they covered such a vast range. If you’re looking for a market, you can’t make any assumptions about who will get the most value from your product. 
 
Today, the top 1% of customers — who make millions of requests of day — keep my business profitable and enable us to support thousands of developers on the free plan.

Testing Packaging

The most difficult decision was about what to offer in each tier. Pricing experts suggest that the price per unit should increase as you move upmarket, because the bigger the customer, the higher their capacity to pay:

But because I was still testing what distinct groups my customers fell into, I didn’t feel comfortable drawing such clear lines between packages. I wasn’t sure what the difference was between the customer that needed to make 1,000 daily API requests and 10,000 — so I wanted developers to first pick the appropriate package based on their particular needs. If they signed up for the wrong package, it needed to be a no-brainer that they needed to upgrade. 
 
The first packaging had pricing double for each tier as the offering quadrupled:

This packaging helped me better understand my customers, as I had originally intended, but it also provided an unexpected benefit. Because we never strong-armed anyone into an upsell, we earned ourselves a good reputation in the developer community. I found that our biggest acquisition channel for the lower-tiered plans was word-of-mouth, through happy developers referring their friends. 
 
Today, we’ve gathered enough data to draw more distinct lines between our buyer personas — but we still want to preserve that good will in the developer community. So we mashed together the traditional pricing methodology with the one that has helped us keep IPinfo useful for hobbyist developers:

For the lower-tier plans, we still offer a hefty discount per unit for each upgrade. For the customers who are less price-sensitive, however, we stop offering discounts upon upgrade.

This allows us to preserve good will, while maximizing our earnings from our most profitable customers.

The Developer Entrepreneur

The internet is filled with best practices for B2B and B2C products, but invisible products, such as APIs, are new enough to the market that no one has quite figured out the best way to make money off of them. It’s in this instance that experience as a developer, rather than as an entrepreneur, comes in handy.
 
As a developer, I’m used to not knowing what the hell I’m doing. Part of the job of computer engineering is to start with a problem, and reverse-engineer the solution — with the help of Google, Stack Overflow, and a lot of testing. When I realized that there was a market for IPinfo, I didn’t need to know what I was doing as an entrepreneur in order to monetize. I just had to put in the time to test and be willing to second-guess every hypothesis I had about the value of my product.
 
Looking at data and experimenting with pricing half a dozen times has left me with these key insights:

• It’s perfectly okay to have the majority of your users paying $0. Many companies only use “free” as an acquisition strategy, but as a developer it’s important to create goodwill in the community. You’ll be paid back in an immeasurable way.
• The prices you choose are less important than being inclusive of different types of customers. A ton of use-cases exist for your API that you haven’t even thought of yet. Don’t price yourself out of the most popular use-case or underestimate the value of your API to bigger businesses.
• Packaging by buyer persona only works once you intimately know your buyer personas. In the beginning, your packaging is going to be somewhat arbitrary. The important thing is to make sure that your buyers are able to upgrade to the package that’s most appropriate for their needs.

Now, two years and a half-dozen pricing experiments later, I run a profitable API-first business.

IPinfo is a comprehensive IP data and API provider with flexible pricing plans to meet your business needs. We handle billions of API requests per month, serving data like IP geolocation, ASN, VPN detection, and more. Sign up for a free account or contact our data experts to learn more.