Why Your Company Needs to Think Platform First

If 2015 had large overriding themes in the world of technology, among them would be the proliferation of devices, continued move toward mobile, smartphones most among them, and the internet of things. What all these themes have in common is that it is becoming increasingly difficult for companies of any size to build experiences for their users on all of the devices said users would like to interact with.

A typical user in 2016 may use an iPad while on the couch, a Mac at home, a Windows computer in the office, an Android smartphone, Ford Sync in their car, Xbox and Roku for their TV, and Amazon Echo in the kitchen. Unless your company is large enough to have teams for each of these, you’ll never scale for them all. This is why you need to think as a platform first.

A platform can mean multiple things, from a software development team that builds APIs and frameworks, to a centralized team tasked with ensuring a consistent user experience across all surfaces. In order to succeed in the distributed device world, you need to think about consistent design language across all, but have enough flexibility to allow for device specific features and taking advantage of the capabilities of different devices.

Let’s say you are a fledgling entertainment focussed tech startup that wants to be everywhere for your users. Here are a few devices you may want to be on.

  • IOS
  • Android
  • Windows (probably not the phone, but definitely the OS)
  • Amazon Echo
  • Google Now
  • Siri
  • Cortana
  • Roku
  • Speakers (Sonos, Denon, and others all have their own streaming technology)
  • Chromecast
  • AirPlay
  • Cars (Ford, Tesla, Toyota, and obviously CarPlay and Android Auto)

Yikes! How can you possibly handle all of these? One option is to focus on the top ones first, IOS and Android. But if you do this rather than think platform, it will cost you time and effort to re-focus design this way later.

Build API first, not Mobile First

Mobile first replaced whatever it was called when you build monolithic software by focusing on building mobile apps first, then expanding to other surfaces later. Uber, Snapchat, and Instagram are famous examples. None launched even on Android until months or years after IOS. Some still don’t have a web presence. However, building this way will ensure you design and build mobile first which will be quite hard to extend to web and devices. Ignoring these devices is just as dangerous and potentially fatal as ignoring mobile five years ago.

Instead, build API first. Yes, this will delay your first app release, but it will speed up every single subsequent one thereafter. No company should be entering 2016 without an API. APIs ensure several benefits.

  • Speed of delivery – You don’t need to rebuild logic for each surface
  • Speed of integration – Third parties like Alexa, Tesla, and Roku require APIs. You can’t control the UX because it is entirely API driven. This means an API is the fastest option to getting there
  • Scalability & Creativity – Third party developers and people like me with free time on weekends and a desire for tinkering can be huge assets. They think very differently from your employees and can come up with some amazing ideas. This was responsible for the astronomical growth of Twitter before they fool heartedly decided to close their API (more on that later)
  • Consistent Experience – It’s impossible to overstate how important this is. Once a user learns how to use your product, they shouldn’t have to relearn how it works on other surfaces. By moving logic to an API, devices have to behave the same way and the experience becomes a set of rules that the user understands.
  • No copy and paste – No need to re-create code or create templates or boilerplate code.
  • Eliminates stack setup – Saves the time and headache cost of having to setup stacks for every surface.
  • Increases your brand awareness – Users and developers act as evangelists for you. Think of the success of Amazon’s AWS and how much of it is driven by happy users. There is no better endorsement than using a company’s API or platform.

Use standards

The use of standards like REST and OATH2 will help you immensely in saving development time and your users will thank you. They don’t need to re-learn anything as these are well known and many libraries and frameworks exist for them.

Dog food your API

The number one user of your API should be you. If you aren’t testing your API in the same way a client would use it, your users won’t use it. Don’t make your users your testers. You’ll find issues earlier, write better documentation, find gaps, think of features, and make your users happier in the process.

Use Amazon AWS

And not just because of where I work. Seriously, AWS is amazing and can save you so much work. It’s like a cheat code for software development. You’ll save time, money, and walls because you won’t punch through them while trying to figure out how to scale your systems.

Why should you believe me?

Let’s look at a few examples of companies who made decisions about being a platform and see how they did.

Amazon AWS

Amazon decided to make use of the work teams internally had to do to launch software and build an internal platform. Then, it took the bigger step of exposing this platform to the outside world and the results have been astronomical. AWS now earns Amazon an incredible $2.4 Billion a quarter. Yowza!


Uber began app first, but transitioned to a platform company in an interesting way. Uber partners with tons of apps to integrate the ability to call a car from anywhere. This more traditional platforming has helped growth, but even more interesting is a product platform in which Uber seeks to be the delivery platform for everything from food to package deliveries to personal items you may have forgotten to bring to work from home. Uber may be hitting some rough patches in its growth, but no one can argue that their growth hasn’t been astounding.


The classic example of a platform is Windows. Way back in the good old days, before the internet even, Microsoft and Apple were bitter enemies. Apple sales were growing in a huge way and Microsoft was struggling to get market share. Then they essentially invented the concept of a platform and decided that they’d be on every computer without an apple on it. This decision allowed Microsoft to become the platform of choice for work and software development in the pre-mobile app world. Apple learned a lot from this. I’m not as sure that Microsoft did.


Twitter provides a great case for the pros of a platform on both sides. Twitter began as a side project before smartphones, allowing users to post updates via SMS (hence the 140 character limit). After pivoting to mobile, Twitter continued to struggle to grow. They then built an API which any third party client app could use. A proliferation of apps grew including TweetDeck, Twittersaurus, and TweetMonkey. Ok I made two of those up but it doesn’t matter. Twitter became a rocketship. Users joined in mass and while everyone used different clients, experiences were great. Innovation and creativity bloomed and features like the hashtag, photo uploads, RTs, search, and saved position were added by third parties, eventually coming into the Twitter ecosystem.

However, Twitter decided they didn’t like the lack of control this gave them. They couldn’t insert ads into other apps. so they closed off access to new apps and bought up or killed the big ones. Now only a few remain and are effectively hamstrung by Twitter. The death of Twitter may be highly over exaggerated, but there is no denying that Twitter is in some trouble. New user growth has plateaued and execs are leaving in droves. The last several big features have been flops, especially moments and the omnipresent “Dick bar” (named for then CEO Dick Costollo). In fact the only new features that people have responded well to have been acquisitions or skunkworks projects, Vine and Periscope.

Don’t be like Twitter, be like AWS. Your users and your growth will thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *