Confessions of an API Nerd: The Moment I Understood the Power of APIs

I started my personal API journey when I joined an email marketing company as their “Partner Integration Manager” back in 2009. Even though I spent every day supporting our technical customers as they integrated with our public SOAP APIs and explaining their business value to our business contacts, I didn’t understand the real value of a solid API-first program until I heard our VP of Engineering tell our CEO “No.”

Like many mid-stage startups, we found the code base that made us successful was creaking under the weight of scalability limitations as we grew. After several unsuccessful attempts to modernize our stack, the engineering team made the bold decision to completely rewrite our application from scratch. This split our technical resources between supporting our existing infrastructure and code while building the new version. 

Negotiating engineering priorities is a constant for most organizations, but discussions can become quite contentious in a resource constrained environment. Our executive team had come to a head in their negotiations and called a meeting with the product management and engineering leads to hash it out. My role was acting as a technical consultant - the new application took an API-first approach, and I was our resident API expert.

Our CEO and marketing team presented a wishlist of items they needed from the engineering team to continue supporting and selling our existing product. Our engineering leaders compared this list to the roadmap for the new project and asked to choose between them. “If you want us to take on a project from your list,“ they explained, “you’ll need to pick one or more features you want to delay or drop completely from the new product. We just don’t have the staff for both.”

One of the high priority items on the wishlist was a tool that would make it easy for our small business customers to design an HTML email that fit their brand without technical or design resources. Several customers explicitly named the cost and effort required to create well-designed emails as a barrier to using our product. The CEO suggested that we build this in the current product, then adapt it to the new product when it was closer to its launch date.

The VP of Engineering was firm: “No. If we’re building something new and core to our product offering, it needs to go directly into the new product. If we want to launch this thing when the investors are expecting us to, we need to stay focused.” He suggested adding the requirements for this new tool to the list of feature requests and began leading a discussion on what the expected use cases might be.

I carefully listened as the marketing team dejectedly described their expectations for how the tool should work. As I often do, I began thinking of how I might implement this were it assigned to me. I wasn’t as familiar with our new code base, but I knew our public APIs like no one else. Very quickly, I realized that our APIs could be used to deliver this functionality and, if I built the email creation tool myself, we wouldn’t need any engineering resources to make it work in the current version. My mind lost in thought, I began absentmindedly talking.

”We can do all this with our APIs. I can build the interface and the logic necessary to create the HTML templates, then we can use the APIs to get them into the user’s account with a single button click.” I laid out my plan on the whiteboard.

The engineering team was skeptical, but glad to move the discussion along. The marketing team was ecstatic. Within two weeks, I delivered a working prototype of the tool while still performing my other work duties. It allowed a customer to enter the URL of their website, then present them with a series of choices based on the colors and images my code found on their site to apply to one of several pre-designed email layouts. With just a few clicks and less than five minutes, our customers were able to generate a custom HTML email featuring their logo, images, and brand colors and save it directly to their account - no downloads, coding, or design skills required. 

After four more weeks of design work and testing, we launched it, hosting it on an AWS EC2 instance I set up specifically to support it. The marketing team built a campaign around it, targeting the customers and prospects who indicated this was a need. The tool took off immediately and helped us maintain those customers while rapidly onboarding new ones. An updated version of the tool eventually made its way into the new product and became the primary interface for email design in the application. This became the first of several “lab” projects we built to further some of our marketing goals, test out ideas in a low-risk way, and provide valuable early feedback that helped drive many decisions for the new product.

Our API program was designed for third parties to integrate our functionality with their systems and provide additional value for our customers through strategic partnerships, keeping them loyal and making them more successful in their email marketing efforts. More than 10 percent of our annual revenue flowed directly through those APIs, with significantly more being influenced by their usage. The program was already a success, but we had left too much value on the table. When I began to see my peers outside of engineering as API customers as well, it opened new vistas for us to pursue and allowed us to not only grow our business on the existing platform, it helped the new platform launch with a set of features we had already validated. 

As you review your API strategy, widen your scope beyond the usual cast of developers and strategic partners. An API-first approach to development and engineering can help your organization bring new digital products to market faster with better reliability. But you may find the real value comes when the power users in your organization are able to leverage those same APIs using their own subject matter expertise to achieve their goals. That’s why an API-first approach is fundamental to building an agile organization. 

Image by Free-Photos from Pixabay