I was sitting on my roommate’s dilapidated couch in West Philadelphia when the contract came in:
$4,000 a month with significant room to grow.
There was a squiggle at the bottom of its 15 pages indicating that a real live person working at a real live company had committed to pay us that much money every month for some software we had written.
I checked everything through to make sure this wasn’t a joke. Then I screamed my head off with joy. This was it – we were finally a real business.
We had launched Firefly approximately 11 months prior, and until then had been scraping along with about $1,500 a month or so in revenue from a few small customers. For a bootstrapped startup run by just two college age kids this latest contract represented a giant step up in our revenue graph, and by extension our prospects. We could now run the business indefinitely – and maybe even hire someone to help us out part time.
This moment validated a somewhat unusual strategy we had decided to pursue some months prior. We had started out the company selling directly to the customers that were going to use our product. But over time we had shifted strategies, and this deal was the first fruit of that shift. Instead of selling directly to customers, we decided to build our product into an API, and allow other companies to build it into their products, and sell it to end-customers for us.
How we got to the API strategy
We had this technology we had built called co-browsing. Basically, it works like screen sharing, but instead of sharing your screen you share just a web page. It doesn’t require any downloads or installations to run, and it works across platforms (Mac, PC, iPhone, iPad and Android).
After some playing around we decided to focus primarily on a customer service use case: when a customer is having a problem with a website, we allow the agent to look over their shoulder and help them through the site in real time.
And we had been trying to sell it with some success, but we weren’t blowing it out of the water. What we found was this: small companies wanted it but couldn’t pay too much for it. Big businesses, on the other hand, moved really slowly, looked at it as a feature rather than a product, and were hesitant to work with a company as small as ours.
Becoming an API company solved our distribution problem in one fell swoop: by allowing other companies to sell us to their customers we could launch to thousands of SMBs without having to go through the pain of signing them up individually and we could be sold to large businesses through their existing vendors (thus eliminating their worries about our size and whether what we were selling was a feature or a product).
Over time we did more of these deals, and evolved our vision for what the company could be based on what we saw. Instead of just being a co-browsing company, we looked at ourselves as something like a Twilio for co-browsing. We provided an API that allowed any company to build this feature into their product and sell it to their customers.
If you have a product that works well as a feature of a larger platform, becoming an API company and selling your product through OEM relationships can look like a very appealing path. As someone who’s walked it, I want to go through the pros and cons of running this type of business so you can decide whether it’s right for you.
Different types of API businesses
Before we get started, it’s important to note that not every API company is an OEM business. In fact, the percentage of API companies that pursue OEM as a strategy is probably relatively small.
This piece is going to focus on the OEM strategy specifically – that’s where much of our business at Firefly came from – but some of this applies to other types of API businesses.
Let’s start with the benefits of pursuing a strategy like this.
When you do an OEM deal with another company that already has a large customer base, it’s a great way to scale up your operation (in terms of customers and revenue) quickly. For example, one of the first OEM deals we did was with a live chat company called Olark. When the deal closed we went from being used a few times a day by a couple of SMBs to being deployed to (at the time) about 5,000 SMBs – a number which grew reliably every month.
It also can give you access to companies that wouldn’t ordinarily give you the time of day. For example, shortly after launching with Olark we did another deal with a large customer service company that bundled us into their product and sold us to Best Buy – a company that would have been difficult or impossible for us to sell to on our own given our size and lack of funding.
Great acquisition target
Doing OEM work makes you a very attractive acquisition target for the right type of business.
For one thing, your partners become natural acquirers: they know your product works, they have a need for it because they’re selling it to their customers, and you’re already integrated into their platform.
But more generally, because you’ve built your product to integrate seamlessly into anyone else’s platform you’ve taken one of the big risks / pain points of most acquisitions – integration – and made it into a non-issue. This makes you a much more attractive buy than if you had a product that would have to be totally shut down and rebuilt to integrate into the existing platform.
Indeed, when senior execs at Pega were initially looking to buy Firefly they were stunned that it took only a few minutes to integrate our co-browse into their flagship CRM product Pega Customer Service. That made a big difference in the deal.
Guaranteed revenue, low cost
Finally, the upside of doing these types of deals and getting instant distribution is that you can generally translate that pretty easily into revenue. When we closed our first OEM deal we went from about $1,500 a month in revenue to over $5,000 a month. And within less than a year we had almost 10x’d that number. And we were still just 2 full time founders with a couple of contractors helping us out part time.
To get to that kind of a revenue number without doing OEM deals we would have had to expand our headcount dramatically above where we did. For example, because we were selling to businesses almost all of our contracts had stringent SLA requirements for both server uptime and customer service response time.
Doing support for thousands of businesses, and ensuring that we had a 24/7 operation would have been pretty much impossible with just two co-founders and a few part-time hires. But because we were OEMing our product, the businesses we were selling to were responsible for the first level of customer service when anything went wrong.
Because our customers acted as a filter for their customers, this allowed us to get away with not scaling up our support operation. Instead, we hooked our “24/7” support line up to our cell phones and never slept without our phones under our pillows. We had a few late-night emergencies, but not nearly as many as if we had been doing first line support.
To recap: doing OEM deals allowed us to build a significant base of monthly recurring revenue at a very low cost. This is really important if you’re bootstrapping.
The darker side of OEM
As beneficial as becoming an OEM can be, there are also significant issues involved in running an API-based OEM business that can dramatically limit your growth potential. Let’s discuss those.
Serving multiple constituencies
When you run an API-based OEM business you have to serve two constituencies: your customer, and the end-customer (your customer’s customer.)
Serving multiple constituencies hurts as a startup for a few reasons. First, because you have limited resources it can be hard to spend enough time optimizing your product for what the end customer wants and what your integration partners want. It’s not impossible to do, but it results in a less focused, sometimes lower quality product for each of the constituencies you’re serving.
Second, sometimes the needs of your constituencies are opposed. For example, the end customers may want you to implement a feature that competes with one of your OEM partners. If you built it, you’d make them happy, but you’d be putting your business at risk.
You don’t own the customer relationship
When you go the OEM route you don’t own the end-customer relationship. This is an issue for a few reasons:
First, your business is less valuable if you don’t own the customer relationship. Any potential acquirer is going to look at your list of customers as a way to value your business. If all of your end customers are actually owned by someone else, it makes your revenue stream less valuable.
Second, when you don’t own the customer relationship information flow becomes a huge problem. This isn’t so obvious before you try to run one of these businesses, but becomes a big pain once you’re in the middle of it.
What we wanted to do was build the best co-browsing experience possible for end-customers. But we didn’t have access to those end customers (aside from during support calls) even though there were thousands of them. We had to go through our partners to find out what was happening with the product, what should be improved, and where we could expand.
For example, using a product like Intercom, or Feedbackify, most startups are able to talk directly to their end-users or gather survey data from them as they’re using your app. Because we didn’t technically own the customer relationship we couldn’t just add a little chat widget into the co-browse experience. Our partners wanted a branded, seamless, and streamlined co-browse experience, not one that included surveys or chats with us. So doing something like this to gather feedback was a no-go.
This extra friction makes it hard to move as quickly as you need to – which often spells death for a small startup and can result in a lower quality end product.
Perverse incentives for word of mouth
With a regular company, if your product works really well, the people that buy it will tell their friends and your business will naturally grow via word of mouth. OEM businesses don’t really work this way because a company that is OEMing you is naturally incentivized to keep it as quiet as possible by white labeling you and not tipping their competitors off to the fact that you’re providing this feature for them.
Think of it this way, if a company considers it a competitive advantage to have your product incorporated into theirs, what is their natural incentive to share that knowledge with their competitors? They have none, and so the task of signing up more OEM customers is that much more difficult.
Beyond not owning the customer relationship, serving multiple constituencies, and encountering perverse incentives, there’s one other major difficulty in selling an API-based OEM product. I call it walking the strange line.
Walking the strange line
This is the big issue that we ran into time and time again in our sales cycle and limited our growth more than anything else. When you’re selling an API solution to a company that wants to integrate it into their product and sell it to their customers you have to walk a line:
You have to simultaneously convince them that it’s not core enough to their business for them to build themselves, but you also have to convince them that it’s still important enough for them to pay you lots of money to provide to them.
These are two conflicting notions for a customer. If something isn’t core to their business, why bother to buy it and build it into their product? If something is core to their business, shouldn’t they own it?
You’ll run into this often when building an API-based OEM business. And unfortunately, whether or not you can manage the objection has more to do with the type of product you have than it does with the answer you give.
The key to a successful OEM business
The only way around the strange line problem is this:
You have to have a product that is important to their business, but that they don’t have the expertise to provide effectively themselves.
The best example I can think of for this is Windows – although it’s not an API it is the classic software OEM play.
We struggled with this a bit because most of these companies could build our co-browse product themselves (building client-side heavy, realtime software was a core competency) but what we were doing was difficult enough for them to shy away from doing so in many cases.
The best way to think about this is as a graph. On the X-axis is how different what you’re doing is from your partner. On the Y-axis is how much demand there is for the feature you provide. If you’re in a quadrant where what you’re doing is significantly different from their core, and there’s demand for the feature you enable, you’re in the clear:
Otherwise, think twice about whether pursuing an API-based OEM strategy is right for you.
So let’s say you’re in the top right quadrant of the graph above. Should you pursue an OEM strategy?
If you’re running a venture backed software company my recommendation would be to avoid doing OEM deals – a recommendation that you’ll likely hear from your VCs. This is because you’ll likely encounter problems that will hamper your growth like perverse incentives, multiple constituencies, and the strange line problem.
However, if you’re running a bootstrapped company like we were, doing OEM deals can be a huge boon to your business. You’ll be able to scale up quickly with minimal overhead and get your revenue number to a point where you have a self-sustaining business.
We bootstrapped our business to almost a half a million dollars a year in recurring revenue in about 2 years with two co-founders and 3 part-time contractors before we sold it to Pega – a publicly traded enterprise software company – in 2014. If we hadn’t pursued an OEM strategy, we would not have been able to sniff the revenue numbers we hit in the time period we did without raising money and significantly scaling up our operation.
Thanks to Miles Grimshaw and Ryan Dawidjan for reading drafts of this.