How we delivered an API integration 7 weeks ahead of schedule

Our client came to us with a problem: They wanted an integration to a third party using an API, but they didn’t have the staff to do it. 

The mission was to complete the integration in a 16-week engagement. We assigned a team of three Test Double agents to the case: two software engineering consultants and one Product consultant.

The reason we chose to assign both software engineering consultants and a Product consultant was because while the API integration was a straightforward tech integration, it also included a UI component.  The client’s Product team also didn’t have time to support the integration, and the integration would roll into a larger product launch.

We delivered the well-tested API integration in only 9 weeks – seven weeks ahead of schedule. 

Here’s how we delivered so quickly and how you can do it too.

‍

Don’t boil the ocean 

The scope of this engagement was an API integration that would eventually fold into a larger UI effort. 

The discovery, research, and design of the larger UI effort was not complete when we onboarded. So we first focused on shipping the technical integration in small iterations. 

Then when we were ready to work on the integration of the API into the UI, the design was ready, but needed to change to account for our API. 

At Test Double, we have a mentality that we don’t need to know everything when we start, and even if we do, it is likely to change. 

So we embrace the uncertainty that accompanies every project and effort, and we build in small increments as we prototype, collaborate, and learn. In other words, we don’t boil the ocean. 

Approaching it as an iterative process with incremental changes is the key. 

‍

Been there, done that, got the T-shirt

Our software engineering and Product consultants have a ton of experience building technical products, many of which leverage external APIs and webhooks with third parties. 

Comprehensive API documentation helped us understand what data, methods, and objects are available, and what constraints the API had for performance or security. Security involves not only user authentication (commonly using OAuth2), but also API access for the application and the management of the tokens that provide that access. 

We also had experience with building and using internal APIs, made famous of course by the Bezos API Manifesto. 

Exploring the API with a standalone app (we used Ruby) helped us get familiar with how the API responded to various inputs and understand the various ways to use it to solve the problem. 

‍

APIs are Products, too

While the purpose of APIs are to systematically connect two systems together, they are also solving a problem for the customer. 

In our engagement, we looked at the API integration as a Product, accounting for not only the technology to integrate with the API, but also the usability, marketing, and support aspects of the integration. 

We asked questions like:

• What value is this API integration bringing to your product?
• Do the customers know how to use whatever feature your API integration is enabling? And for what purpose? 
• Is there a UI component for your customers or your internal teams? Is that design delightful?
• What do your internal support teams — Customer Support, Technical Support, Developer Relations — need to support the occasional bump in the night? 
• What metrics are you using to know your solution is solving their problem? 

While some of this can add some time to your timeline, it will make for a better and more useful product when you go to market.

In summary, we used our experience building technical API solutions by looking at all aspects of the solution and building small, iterative features. You can too. 

‍

Need help with an API integration or internal product? We can help! Let's chat.