STOP! You are giving your customers away!

We must all be taking crazy pills, we have been drinking the API economy kool-aid for the past 10 years, that many of us had become blind to the fact that we may actually be harming our own business and future.

Don’t get me wrong, I strongly believe in API economy — in fact, I’ve built my company around it (https://cloudonix.io). However, there is a big difference between building an API economy enabling business — and building a service, that is heavily based upon another companies API platform.

For sake of discussion, let’s examine 2 API economy giants: Twilio and Salesforce. To 99% of people both companies have nothing in-common. Twilio is the world leader in CPaaS service (Communications Platform as a Service), providing tens of thousands of businesses with SMS and Voice API services — and a whole lot more. On the other hand, Salesforce — potentially, the world’s largest SaaS company. Providing tens of thousands of businesses with business management tools, CRM tools, marketing tools and more. From a technical standpoint, they are not competitors — they are complementary tools. Actually, if you look into the Salesforce marketplace, Twilio is one of the most installed Salesforce plugin.

However, Salesforce, unwillingly and without thought, had actually ‘given’ its customer base to Twilio — while at the same time, provided them a rapid go-to-market, for introducing new services — potentially, competing services.

Sounds imaginary? maybe a little science fiction? — sorry, this is not fiction, this is FACT!

Between 2 giants

In February 2019, Twilio completed the acquisition of SendGrid — a mass e-mailing API and services company.

Twilio Completes Acquisition of SendGrid

From a business standpoint, Twilio acquiring SendGrid makes perfect sense. Twilio is a CPaaS looking to expand its offering with more communication tools and services. At the same time, SendGrid existing customer are a wonderful portfolio to extend Twilio services to — in other words, it’s a perfect fit.

Now, let us examine Salesforce, a Twilio partner. One for Salesforce’s primary products is “Marketing Cloud” .

What is Marketing Cloud?

Marketing Cloud is Salesforce’s marketing automation and marketing management product. One of the primary components of that service is a mass e-mailing service and API. Business speaking, a direct competitor to SendGrid, that is fully integrated into the Salesforce offering.

Now, if you are unfamiliar with how API companies normally connect to one another, the process flow is normally this:

1. Setup an account with company A
2. Setup an account with company B
3. Generate an API key with company B
4. Input API key of company B into account in company A
5. That’s it — company A is now able to activate services on company B for it’s customer

Massive problem — company A had now exposed its customer to company B, indicating that customer is using company A’s services.

So, let’s go back to the previous Twilio/Salesforce example. To enable Twilio services in your salesforce account, you will normally generate a Twilio API key and feed-it into your Salesforce account. Now, Twilio’s systems are aware that the activation of a customer account is performed from Salesforce’s system. Also, if the activation of the Twilio account had been performed via the Salesforce’s marketplace, Twilio is fully aware of the customer as well — long before the actual usage starts.

So now, Twilio holds a rolodex of businesses that are using Twilio services — however, had been referred to Twilio’s service via Salesforce. Now, Twilio acquired SendGrid and asks itself: ‘hmmmm… Salesforce has many customers that use mass e-mailing services and APIs… Let’s try and go for these customers’. Not a bad tactic, makes perfect sense. The customer is already using a similar service, go-in, offer a competing service for a better price, get the customer — smile all the way to the bank. Question is: ‘how can the sales team obtain a list of qualified leads and prospects?’ — answer, just dig into the database of customers that were referred from Salesforce (or other partners in similar verticals) and start targeting them for direct sales or field sales. In other words — Salesforce had unwillingly provided its competitor with its customer rolodex.

XaaS — and your business

As an entrepreneur you always torn. Torn between the desire to build something fast, get to the market, grow fast — make an impact and of course, succeed along the way. In that pursuit, we tend to ‘cut-corners’. Use a platform we already know, use a service that gets us their faster — in many cases, without fully realizing how it affects our business (or to be more accurate, the future of our business). As an entrepreneur, you will be required to raise funds — from family, friends, angel investors and venture capitals. One of the questions they always raise is directly related to the competitive landscape of your business. Now, this is a tricky question — what they are asking isn’t only “do you have competitors?” the other question is “how hard will it be for a non-competitor to compete?” and worse “how hard will it be for a ‘partner’ or ‘platform provider’ to become a competitor?”

Let us assume that your business is building skills for Alexa. Well, no one builds a business just on that, unless you are a freelance developer. Let’s say you are building Alex skills for lawyers, skills that only lawyers need. Let’s assume that these skills will now mash-up the following online SaaS and PaaS tools:

1. Alexa — Naturally you need the Alexa platform to build a skill, right?
2. Toggl.com — This is a time reporting SaaS that has an API to integrate with your own code
3. Salesforce — Naturally you have a customer management system
4. QuickBooks — For accounting
5. Stripe — For credit card processing

Now, assume that your service includes the following skills:

1. ‘Alexa, start clock with customer X’
2. ‘Alexa, stop clock with customer X’
3. ‘Alexa, add last transaction from customer X to bill’
4. ‘Alexa, charge customer X credit card and send invoice’

Now, as a developer — I know that mashing the above services to create the above skills is possible (possibly, someone already did it — but for sake of discussion, let’s assume it’s brand new). Now, as a developer you build the service, but you don’t want to pay Toggl, salesforce or any of the above, you want your customer to create the relevant accounts and give your the API keys for integration. Makes perfect sense, you want to charge for your service, not fund someone else’s service.

Problem 1: Toggl.com decides that building Alexa skills to activate Toggl via Alexa may be a worthwhile business — judging from the last time I dabbled with Alexa skills — will probably take them a couple of days to do so.

Problem 2: Amazon decides to create its own time tracking and Alexa skills for the same purpose. Will potentially take them a bit longer, as they will require to make it integrated with the rest of the Amazon services — but still, they are a big enough player to do so.

Problem 3: Salesforce identifies that your Alexa skill is being used extensively with their customers. Salesforce decides to develop an Alexa skill to compete.

With all 3 problems — the result is identical. You had developed a product that can be easily copied, that leverages other products in a smart way — but can’t be protected and can’t assure for proper customer stickiness.

You answer to this will be: ‘Look, it’s a proof-of-concept, we’re gonna replace it’ — again, you are wrong. In the pursuit of growth and rapid market penetration, changing your core is the last thing you’re gonna think about — which means, that mistake will continue onwards, potentially to a highly dangerous point.

Stacks, Customers, Ownership and Control

At Cloudonix we have a saying: ‘if you don’t control the stack, the stack controls you’. It means that whenever we decide to use a specific tool or technology, regardless if it’s a source code library or a service provider — we examine the short time and long time implications of both, and thus, make sure that whatever decision we take — its risks are understood, hedged and can be mitigated when required.

For a business, ownership of one’s customer is crucial — and full ownership is key for success. Full ownership means: if you use a 3rd party service, that service should never be exposed to your customers. In addition, if you are using a 3rd party service, it must be an infrastructure service — not a potential software service that can turn into a competitor. For example, we use Auth0 as an authorization provider — but we can’t see a situation where Auth0 will decide to compete in our space, simply because they are dramatically apart.

At the same time, we using Amazon AWS and other cloud providers for our computing infrastructure — however, they are not exposed to our customer rolodex nor who they are. Thus, we have full control over our customers.

As a business model, we believe that API companies such as ours (https://cloudonix.io) should enable other companies to build new services, without the fear of us becoming competition. In addition, we believe that API companies should enable its customers to integrate it into their tooling and other tooling, without exposing their customers. Any situation in which the utilization of service A within the construct of service B, requires the exposure of the customer from A to B — is a potential risk and point of business friction.

If you are building the next Skype, you won’t be using Twilio as your backend. If you are building the next whatsapp, you will be doing it using something like Intercom or other live-chat platform.

So, what is your idea and how will you build it — after reading these words? have I given you some food for thought? let me know.