Whether it’s for building a company, monitoring the news, or even making a grocery list, software penetrates every part of the modern western lifestyle. The demand for software far exceeds what developers (and the tech industry as a whole) are capable of supplying from scratch. In order to keep pace with demand, our industry has been increasingly shifting towards a ‘prefabrication’ model of software development via the utilization of third party APIs. While this trend has been in the making for 10 to 15 years already, the market is poised for continuous aggressive change in the coming years as well.
We can say this with confidence because history tells us so. At the turn of the century, when large-scale construction was beginning to become common, constructing an office building or factory required bringing together a large group of expert craftsmen at a jobsite. Expert carpenters were needed to build the doors and framing, expert glass blowers for the windows, expert masons to cut and lay the stone, blacksmiths to create the steel structure, and so on. As the 20th century progressed, and demand for construction skyrocketed, various forms of prefabrication were developed in order to make construction faster, cheaper, and more accessible. For high-end, custom buildings, the prefabricated parts components could be limited to the windows, doors, and HVAC system while at the other end of the spectrum entire buildings can be erected in days out of completely prefabricated components. In fact, McDonalds has been known to complete a building in mere weeks this way.
The evolution of software development has followed a similar trajectory, with APIs serving as the prefabricated software that companies are leaning on to build software faster and more cheaply than ever before.
In many ways, Amazon pioneered this ‘prefabrication’ mode for software developers when they released Amazon Web Services in 2006. By making Amazon’s excess compute resources available to other software companies to use in the form of APIs, the capital and expertise needed to build a software company was reduced dramatically. Do you want to spend your technical resources trying to scale and manage infrastructure better than Amazon? For the vast majority of companies the answer is no, they’d rather spend those resources focusing on the more specialized parts of their software, and that’s why AWS generated $46 billion in revenue last year.
Since AWS, hundreds of other API-as-a-service companies have emerged to help other software companies build faster and cheaper. Twilio came up for digital communication. Stripe was used for payments. Shopify was available for e-commerce. Okta became important for user authentication. Just these four companies represent over $350 billion in enterprise value and have laid a lot of the groundwork for this industry, but it’s still very early in this movement. There are still many parts of the software stack that have yet to be ‘prefabricated’ and millions of hours of development are still spent on building the same functionality over and over again when it would be far more efficient and lead to more innovation if those hours were spent on building unique value.
The rise of APIs-as-a-service is increasing both the prevalence and importance of the ‘build vs buy’ decision within engineering teams. Should we roll our own user authentication service or buy Auth0? Should we roll our own payments platform or buy Stripe? As my colleague Tejas controversially argued in his post, user authentication, payments, and notifications are three things that you should never build yourself. While many people did not agree with that particular thesis, the trend of engineering orgs evaluating API solutions in order to get their product to market faster is certainly growing.
What this means for engineers is that having the ability to effectively evaluate APIs and run a cost benefit analysis as opposed to creating a custom solution is becoming increasingly important. As a company that builds and sells an API, we see it all the time here at Courier. A software company, typically a medium to large startup, begins to run into some pain points around sending and managing product notifications. A decision is made to find a new notification service that meets their needs and tap a senior engineer to decide how this problem should be solved. He or she typically evaluates using Courier rather than rolling out a custom solution and then makes a case for which solution they think is a better fit to their team.
Having a good understanding of the currently available products and functionality offer, being able to effectively estimate the total cost of ownership for both an API solution as well as a homegrowth solution, and being able to effectively map out the integration strategy for API products are all skill sets that are becoming ever more valuable in both developers and engineering leaders.
As APIs handle more and more of the monotonous and undifferentiated parts of the software stack, developers' time is being freed to be spent creating new, unique, and highly valuable product experiences. In the past several years we’ve seen brand new software startups take on challenges as diverse and complex as automating and streamlining the mortgage application process, building marketplaces for pretty much any good or service imaginable, democratizing the ownership of publicly traded stock, and much more.
As the proliferation of APIs continues, software development will be able to focus less on solving low level systems and infrastructure challenges and more on the creative side of product and customer experience. Of course, there will always be a place for the engineers who truly want to dig into systems challenges (someone does have to build these APIs, after all), but the engineer who is adept at leveraging APIs in order to deliver a more differentiated product more quickly will become increasingly valuable and sought after.
The prefabrication of software via APIs is the next big wave of disruption in the software industry, and while it has already arrived, we’re only in the beginning phases. There are still hundreds, maybe thousands, of technical challenges that are repeatedly solved across nearly every software company or vertical that could be successfully prefabricated via an API. As slower moving industries such as insurance, healthcare, education, and finance become increasingly digital, additional API services will emerge to serve those industries. As digital regulations around privacy and security continue to mature, we’ll see more APIs focused at helping with compliance. The startup engineers of the future will either be building APIs to help other companies move faster or leveraging those APIs to take their own product to market.
Building a Slack Integration for Your SaaS Notification System
Many organizations don’t quite know what to expect when building an integration for sending messages from their SaaS product to a Slack channel or a direct message.
August 04, 2022
Common Courier Troubleshooting Solutions for Developers
In this post, we will discuss example issues around Courier’s Gmail integration and API rate limits, an incomplete data profile, and an incomplete request with Inbox and Toast, and how to fix them.
July 21, 2022