How APIs make build v buy irrelevant

A traditional distinction that often comes up for users considering HyperTrack (especially business users) is — should I build location tracking in-house or outsource? The thought process then moves on to whether this is a core feature in the product. If so, “we are going to build it in-house”, they say. If not, “we are looking to partner with someone to implement it for us”, they conclude and that usually means an enterprise-y application with customizations, integration services and operational roll-outs.

Turns out, this traditional distinction has become irrelevant. When Whatsapp implemented mobile number authentication using Twilio, did they build the feature in-house or did they outsource? Was that feature core to Whatsapp? When Shopify implemented a way for their merchants to get paid by consumers using Stripe, did they build it in-house or did they outsource? When my colleagues’ previous startup doing mobile payments for restaurants — Chalo (now Pay with OpenTable) — used Stripe to collect payments from consumers and settle it directly with restaurants, did they build it in-house or outsource? Chalo used PubNub to establish two-way communication between its payments server and the restaurant’s point-of-sale (PoS) system. Was this in-house or outsourced?

What does this say about mobile number validation being core for Whatsapp, or payments being core for Shopify, or payments and real-time communication with PoS being core for Chalo?

These features are core to Whatsapp, Shopify and Opentable. Retaining full control over the product experience is critical to them when implementing these features in their stack. Using a 3rd party API is not at odds with that goal. On the contrary, API-based products like Twilio, Stripe, PubNub and HyperTrack are built precisely for developers who want to build on their own. Arguably, the products are unsuitable for enterprises who want to outsource to a third party solution provider or use off-the-shelf full-stack products. These are neither B2B nor B2C companies. These are B2D companies, where D = Developer. See Twilio’s irreverent yet totally on the money ad campaign — Ask your Developer.

The traditional distinction fails to stay current in the new world order where software systems are built using a number of specialized micro-services talking to each other over the network to get something done. It is now typical for one feature or action in the product to trigger dozens of micro-services in the backend, including third party. The technology in which each micro-service is built is irrelevant to its consumer. There are a tremendous number of specialized 3rd party micro-services with great technology that developers can leverage to build and operate features cheaper, better and faster.

A popular service called StackShare is case-in-point of this new reality. Stackshare lets companies share their software stack with respect to external tools and APIs.

Just as we would like to be in the product stacks of tens of thousands of products with location tracking features, we in turn use a good number of tools and APIs in our stack. It would be hard for us to succeed without these services and similarly expect users to depend on us for their success. It would be a great feeling when users look back at HyperTrack in a few years and wonder how they could ever do without us.

Check out the stack that powers HyperTrack. Click on the details tab to better understand what we use each service for. And hey, try HyperTrack to build location tracking features in your stack. Sign up now and get your free API keys.