Searching for scale

I recently closed the show at the first APIdays event in Singapore, and given the rather obvious theme of the event, I wanted to talk about API’s. Short for Application Programming Interface. I assumed other people would be more technical than me, so I wouldn’t outshine there. So I went for the really relevant question that’s been on my mind for a while now, as I’m in the trenches myself, searching for scale: why. Why do API’s matter?

NOTE: For what it’s worth, my context here is that of enterprise software startups. Why does that matter? Well, because most API companies don’t actually target enterprises per se, and target developers directly. My company Bambu isn’t a developer tool company. Well, at least not yet.

Why scale even matters

So as you may have guessed at the clickbait, the lens here is scale. Startups care about scale, a lot. API’s matter only because they offer a new type of scalability, which wasn’t possible with traditional go-to-market channels, including Software-As-A-Service (“SaaS”). Again, for the developer community API’s are a revolution, but I’m choosing to focus on enterprise sales because that’s what I do and know.

“But does it scale?” — Every VC you’ve ever met

Scale matters for startups, because scale creates asymmetric returns. Investors want asymmetric returns, i.e. a little risk for a gigantic reward. They did the math, cause they’re smart, and that has been the formula for the last 50 years of venture capital. If this makes no sense to you at all at this point, go read this post for context and come back to finish here.

How did people scale before, then?

Without getting into a whole history lesson here, the thing you need to know about what came before is… Salesforce. Before these guys came along, enterprise software was a dirty business. Not crack cocaine dirty, but just messy. You created some code that you thought would be helpful at other companies, and then if you were successful, you created copies of that code for each client. Sounds great! Slap that code on a CD-ROM, and you’ve got a business.

Now do that 1,000 times. You can’t even begin to fathom the long tail that creates, necessitating an entire cottage, or rather skyscraper, industry to keep those straggling scraps of code glued together over years, even generations. Oracle mastered this game and became king of the hill. This is precisely why Y2K was a genuine concern because the long tail was 50 years deep at that point. Spaghetti doesn’t even begin to describe it. Well, maybe an actual skyscraper built out of spaghetti and some duct tape.

Salesforce came out in the heat of the internet boom of the late ’90s with a new slogan that went against that entire legacy, and they broke all the rules. They must have felt so cool. Not sunglasses with a button-up and tie cool. Like Han Solo and Chewbacca on the Millenium Falcon cool.

You paid Salesforce for software, like any other company, except you didn’t actually get any software. No CD-ROM. Huh? What did you pay for, then? You paid for access to their software. This meant that the team at Salesforce just had to maintain one set of code that everyone shared. If you updated one customer, you could update 10,000 at the same time. But they could still sell it like software. In fact, it would be much faster and cheaper than software. They could scale. It was a real stroke of genius, that changed the industry forever. Legends of the game.

Ever since then, founders of startups across the galaxy have pitched themselves as “Salesforce of anything”, to associate themselves with this business model and go-to-market strategy, that was the epitome of asymmetric returns and scalability.

“Oracle of something” — Said no founder, ever

It’s worth mentioning Salesforce was founded by Marc Benioff, a former top executive at Oracle, and that Larry Ellison himself invested into Salesforce. Then Marc kicked Larry off the board. Pretty symbolic passing of the torch, then. I’m sure Larry isn’t crying too much about spoilt milk on his mega-yacht, named Musashi. Yes, that Mushashi.

SaaS as the silver bullet to scale

So, the moral of the story is, therefore: go SaaS or go home. The only game in town. Case closed. Or is it? Doesn’t a scalable go-to-market apply universally? Why wouldn’t you want to scale, if SaaS is clearly the right tool for the job? The plot thickens…

Now I’m going to diverge even further into a niche category. Remember, we already went from startups down to enterprise software startups, and now we’re going into Financial Services. Why? Couldn’t I just make this simple and universal? No. I prefer to drag you along, deeper into the murky waters of enterprise software.

The peculiar feature of Financial Services is regulation. Regulation is just a fancy word for things you can’t do, and is synonymous with the big stick that beats you if you do those very things you weren’t supposed to. As Theranos would tell you, there are many other industries with this same fun feature. Ask Elon.

So if Salesforce had one set of code, what happened if a client wanted something just a little different? Nothing. They wouldn’t and couldn’t do it. Luckily for them, they chose to start with a very generic and non-regulated cross-industry horizontal function in sales and customer relationship management. So most people were happy to trade their unique requirements for a cheaper and faster solution.

The specific problem with Financial Services is that most countries have their own rules. Yeah, it’s really annoying. If the U.S. alone is a headache with regulation, which obviously also keeps changing, then imagine doing that across the world. It’s a whole nother level of spaghetti.

So if you do SaaS in Financial Services, then you either have to pick a niche where you can slice a common set of regulations, or basically create infinite variations of every feature to allow for that flexibility. Some do get away with it, but most don’t.

“We are a technology company.” - Any bank CEO in 2018

If that wasn’t reason enough to give up the ghost, then you have the trend of banks becoming tech companies. They don’t want to buy your software anymore, SaaS or not, because they’re getting into the business themselves. They need to own all that code and intellectual property, because… well, I don’t know, but they say it with a lot of confidence so I believe them. So it’s a thing now.

Can we scale faster, tho?

So once the standard J-curve was set by SaaS companies, the natural question to ask was how do we make more of more? More is now the standard, so we have to do more of more. Exponentially more. Squares of squares.

API’s: hold my beer.

When did this API thing get started? Well, I suppose a lot of the development of both SaaS and API business models is closely related to the availability of cheap computing on the cloud. Remember back in the golden days of software, one did not simply build data centers. Those were big boy toys, and VC’s weren’t exactly forking out truckloads of cash to just any Sergey and Larry with cool t-shirts and stickers on their laptop.

Fast forward to the birth of Facebook for example, and anyone could go online and set up a website with a credit card and a few books on coding from Amazon.com. That’s pretty much what Zuck did, too. What this enabled was a whole ecosystem of developers doing weird stuff online. Some developed open-source projects, meaning code that others could also use as part of their own projects, like a set of legos open to everyone. Most of it was useless, but some of it stuck.

Eventually, rather than just share code, some thought to instead provide functionality as a service. Not necessarily a whole program like Salesforce, but bits and bobs. Like analytics. Like payments. Like chat. Like SMS. Like anything, almost. You only paid for how much you used, and you could buy online just like shopping on Amazon.com. In just a few years, the way new software changed from the old closed platforms to an ecosystem of open-source frameworks and pay-as-you-go API’s.

In many ways, Salesforce itself is now a little old-school. They’re still out there selling a solution when the world is now building from legos.

Fun story: In 2012, Oracle actually sued Google in hopes of being able to enforce copyrights and patents for it’s Java API’s, which is bought from Sun Microsystem. Oracle lost, and API’s can no longer be patented at all. Which is kind of like the end of Star Wars: Return of The Jedi, where the Death Star explodes and the Ewoks are dancing.

Do not sell the Happy Meal

So how do you do API’s then? How do you go from software to SaaS to API? Is this just another type of technology that your tech guys can just get done in the background? No. If I add a link to my website that says API, and I publish my documentation and name it “API Library”, am I done? No. It’s a different philosophy altogether for product development and go-to-market channels.

Publishing an API library is like McDonald’s publishing a menu of burgers with no intention to sell anything. It’s not enough. This is documentation, it’s not a business model. — Me just now

Think of SaaS. It’s the Happy Meal of software. You want a meal, so it comes in a completely self-contained package that gives you a solution to your hunger and unhappiness problem. Everyone loves a Happy Meal.

The problem arises as soon as the first child with allergies comes in, and would literally die with the standard apple slices. Then you get the picky eaters who will spontaneously projectile vomit at the first sight of a pickle slice between those smooth buns. Someone else can’t stand sesame seeds on the bun, others can’t digest cheese. It goes on and on. This is no longer SaaS. You have to go a level deeper and expose the features and options.

Architect to deliver any item

The real task at hand with API’s is to expose the right level of functionality to the customer. Some get away with just one magical all-inclusive endpoint, but others need a thousand organized like a McDonald’s menu.

Without getting too technical, the key decision is the black outlines. Those are your microservices. A set of features that has a common underlying data model, that cannot be separated from each other. This isn’t automatic or easy and often takes an iteration or ten to figure out where to draw the lines. So the early days will be messy, and you will rewrite most of your code several times. Don’t worry, it’s par for the course, and even the big boys have done it the hard way.

Architect to sell any meal

So where does the scale come in? How is this any different to just selling the whole solution? Wouldn’t you be able to charge more for the restaurant itself as a franchise, instead of selling slices of lettuce and packs of ketchup?

The key that unlocks the scalability of the API business model is flexibility. You don’t care what your customer is building, why, where, or how. The customer could be a team of hedge fund wizards or a garage-full of hackers in Bangalore. They might be building trading software or dating sites.

You stop selling, and they start buying. You have the pieces, and they can buy them like a pair of shoes on Amazon, except that your delivery is instantaneous. As long as you need humans to talk about deployment and billing and click buttons, you’ll be stuck in the McDonald’s before Ray Kroc came in and industrialized the food production line.

How to go about it

So do you go API straight out of the gate? Maybe, if you’re a developer founder and have many stickers on your laptop. That’s a must. If not, you’re more likely going to have no idea what those API’s should be. Trust me, this isn’t something you finagle with an offshore development team.

So I’m proposing a three-step plan to scale. This is empirically speaking how it would happen if you were clueless and stumbled your way through the process. Clueless stumbling is a feature, not a bug! By not knowing what you’re doing, you’re secretly keeping your options open, and willing to admit your mistakes and start from scratch. If you think you know it all, you won’t have the humility to fall flat on your face, which is highly underrated.

To paint a picture of this journey, the Gartner hype cycle is a useful canvas. Any new technology goes through this cycle. We’re somewhere between inflated expectations and disillusionment with machine learning, for example. There’s no use fighting it, so you might as well get on the rodeo horse of hype, and try to hold on as best you can.

Step 1: Pilots

The world is full of opportunity. A new breakthrough technology is making waves around the world, and everything’s gonna be different this time. Full of optimism, you educate the market of your visionary abilities and the upcoming transformation. No one cares. Well, they’re really excited, cause you’re really excited, but no one will take a risk. They won’t gamble the house on your pipe dreams. Lots of meetings and conference panels. No revenue.

So you settle for pilots. Every customer is basically an expensive lesson. Everyone has different requirements, and the outcomes are typically short of expectations for both parties. The customer gets to tick the innovation box on their CV, and the startup finally gets a meeting accepted with a VC. Fair trade.

Solution: Custom software. Monolith architecture. Nothing else to it. Will code for food.

Step 2: Revenue

So cooler heads have prevailed, and you’ve settled for something short of changing the world. A few of your pilots turned okay enough to justify further spending from your customers, and you actually get paid a little now.

Those early lessons have given you tons of valuable feedback on what works, and which customers end up paying you. So now you can take what works across some subset of those clients, hopefully more than 2 or 3, and make that into a platform. Then you try to find more customers that have requirements that are close enough to close the deal.

Solution: Software as a Service. Service-oriented architecture. You still need to sell it in, so the legwork doesn’t go away.

Step 3: Scale

Through the tough times of consolidation, a few players have emerged less scathed than the carcasses that were left behind. Bruised and battered, but still in the game.

Now the use-cases start to spread. More customers are calling. They’ve used similar technologies before, and are starting to build their own teams around this. There are new emerging segments you could serve, with just a few tweaks to the software. You’re tempted to go back to old-school software, but your VC slaps you in the face. Does it scale? No. There has to be a way.

So you look at where the requirements fragment across the underlying services of your SaaS platform. What works independently of the other modules. You probably do some really painful re-architecting again. You need more money to do that, but since you have some traction by now, and use the word “scale” a lot, you qualify for Series A or B.

Solution: Open API. Microservices architecture. You can still sell some, but most of your clients will just buy online, so you can save on business cards and printing paper. Partners will take your API’s too, and create their own platforms to sell into their existing relationships. Queue magic.

API: Endgame

The dream is a tweet from a developer in Estonia using your API in a hackathon. The dream is money showing up in your account from a customer in Nicaragua you’ve never met. The dream is becoming a utility, alongside the internet hall of fame. Think Paypal. If you can facilitate interactions between platforms, you’ve hit a home run. Then you can write your own post on Medium, and tell us how you did it. No really, I need to know.