The key to your side hustle

Published 22-10-2021

I am sure that you, like me, have come across posts of startups securing millions in funding and thought - hey, I could have done that... The goal of this article is to introduce you to the "magic lamp" that could help get your idea off the ground - an API...

Consider the following scenario:

Working from right to left, the participants are:

• Corporation: This is typically an organisation which does the "heavy lifting". An example could be a bank which provides customer account information or a mobile operator which sends SMS. The functionality is accessed via an Application Programming Interface (API). Think of an API as a "channel" to the organisation. A collection of APIs is what I refer to as an API Marketplace.
• Enterpreneur: This is You. You and your team are building an App that is going to take the world by storm. The App uses the API to communicate with the corporation.
• Customer: This is the user of your App.

It is important to remember that the Customer uses your App which accesses the functionality of the Corporation via API.

Now that you understand the positioning of APIs, let us determine some of the benefits of this approach.

1. Show me the money

Value for the you, the consumer of the API could be implicitly derived. For example, customer transaction data retrieved from the host organisation could be used to determine a more accurate user risk profile or a personal loan at checkout could be used as a payment option.

With time and as API ecosystems grow and mature, competition between organisations could result in more aggressive business models - which is to the benefit of the API consumer (you). It would be awesome to see a revenue share model to attract third party developers to API products. As an example - if a developer builds an App that potentially results in a customer signing up for an account or maybe a home loan, the developer could potentially be rewarded with credits for further API calls, revenue for signing up a new customer or facilitating a new home loan.

2. Implicitly earned trust

As a Developer myself, I too have delusions of building the next killer App. Humour me - let us assume that I have stumbled across the next great idea, which uses SMS as a primary channel. If I managed to secure a meeting with a VC and used my mobile device to send messages, it would not be a great reflection of my App. On the other hand, if I used a provider like Twilio, I implicitly inherit their reach, capability and reliability as they have points of presence in many countries and are an established organization.

By working with an established partner, your product or service "automatically" gains trust from the end user. I think that one of the most difficult phases in a product lifecycle is customer adoption. Although you can run your App from a computer under your desk, the assurance that it is "powered by AWS" or "runs on Google Cloud" is what the end user may need to try it out.

Major brands around the world have spent years, sometimes decades, building trust and are now household names. Consider how this could slingshot your application's rollout.

Before you decide to "go it on your own", keep in mind that you could acccelerate your effort by "standing on the shoulders of giants" or become "famous by association"...

3. Focus on the star

Let us return to my "killer app" idea. As you will recall, it uses SMS as a channel. It is important to keep in mind that the idea/intention of the app is the star of the show - not how the message was sent. The simple act of connecting my mobile device to my computer cost me time - time that I could have been spending cultivating the idea. I speak as a techie - I often get caught up with the thrill and challenge of getting something difficult and intricate to work. The goal is to get your product out as quickly as possible.

Again, although your team can build a platform to manage customer Wallets, is the Wallet your core business or is it the Application that uses the wallet to store money? Try to outsource as much of the peripeheral functions as possible. And do your best to silence that little voice suggesting that you need to control every element of the solution.

Remember, at the end of the day, your solution needs to be engaging, stable and reliable. Although I am technically interested, I don't really mind if WhatsApp uses their own infrastructure or AWS - as long as it works.

4. If you can't beat 'em, join 'em

As much as I would love to be sitting next to Greta Thunberg on the steps of parliament railing against big corporations protesting climate change, my "killer app" has not really taken off yet. It is important to understand and accept that the incumbent organisations that many startups are trying to disrupt have had a headstart of decades and probably have far deeper pockets than the VC you just presented to. Notwithstanding that - their biggest advantage is that they control access to the customer data.

Again, you can go it on your own and build a whole new world for the customer (much like Aladdin promised to Princess Jasmine), but consider the benefit to the end user if your application had access to historical and transactional data - from their current world. This "middle-of-the-road" approach also gives you (almost) immediate access to an existing customer base - in their "current context".

If an organisation is extending an olive branch to third-parties by making an investment in an API Marketplace, to democratize customer data (sorry - really had to use that line) with customer consent - maybe it is something to consider? Think how that data, which has been locked away - probably for decades - could accelerate your product or service.

It may be better to have a piece of larger pie than to have a smaller pie all to yourself...

5. As a service

I use GMail for my personal email. I was lucky enough to have a superbright friend who got an early invite and sent it to me so I could snag rennay@gmail.com. As much fun as it might be to set up a mail server on an old computer at home, I'm pretty sure it would be far more painful operating it on a 24x7 basis. To be honest, it was never an option to start with - there was no way I was going to run my own mail server. I'm still curious why Hillary Clinton decided to run her own.

Today, thanks to Cloud providers (Amazon AWS, Microsoft Azure and Google Cloud), the immediate reaction if compute capability is required, is to spin up a machine "in the Cloud". Again, the capability is provided "as a service".

Bear with me - one more example. Around 20 years ago, when I wanted to send an SMS, I proudly connected my Ericsson mobile device via serial cable to my notebook, initiated a session and sent ATDT commands which sent out the message. Later, while on a project at a mobile operator, I was lucky enough to get an SMPP account which connected to the SMSC. Boy, was I chuffed! Found a Java library which converted java code to SMPP and I could send and receive messages. This capability was not easily accessible as it was "direct" integration to a network element. Today, my 12 year-old son (I wish he had the inclination), could do the same by firing a HTTP request to a Clickatell/Twilio endpoint.

The argument using the above scenarios is that - although it is possible to grow your own vegetables* or keep live chickens for eggs, it is far easier to get these from your nearest grocery store. As much as you can run your own database and system to maintain customer Wallets, it is far simpler and more efficient in the long run to simply leverage the capability it as a service.

Disclaimer*: No offense intended to those who grow their own vegetables. Really do not want to upset my in-laws who are super proud of their home-grown veggies.

Corporations globablly are extremely keen to work with third-party developers and entrepreneurs to extend their reach and APIs are the new channel to achieve this. This is a great opportunity for you to grab that brass ring and be that next startup with an amazing idea that will take the world by storm! I certainly hope you do.

If you have any questions, do not hesitate to drop me a mail at rennay@rennay.dev