Build vs. Buy: API Proxy Edition

"Build vs. Buy" is one of the most old and controversial company-wide debates. They can rage on in R&D departments like "vim VS emacs", "tabs VS spaces", and "rebase VS merge". And when you finally go to the most senior member of the R&D department to settle your debate, you get the following wise answer:

‍

"It depends."

‍

In this post I break down the thought process behind Build vs. Buy for API proxies, and give you some tools to help you make the right decision.

Let's stick to out lunar theme to get the gist across first - bare with me. Imagine your company is our moon 🌔.

It has a lifecycle, and the part of the lifecycle you're currently in will affect your decision.

Now we will dive deeper with this analogy to see whether you should be building or buying based on your stage and other aspects of your business that should be taken into consideration.

Impact: Early stage startup ☄️

Every software company starts with a single line of code written by the first developer and grows from there.

Peter Seibel

‍

You're now a small team of developers, and you're building your first product. It might be a mobile app, a web app, or a SaaS product. And you need to start consuming your first APIs. The first API call you write will probably directly in `main`, written in the middle of the night, with a box of half-eaten pizza 🍕 on the table. I've been there. But the moment you hit that first "429 Too Many Requests" error, you'll realize you need to do something about it.

Like the "Impact" stage of our moon, you have a lot of energy, but to end up where you want - you need to make sure you're not wasting it. The STARS framework can help us assess your situation: You're assembling the capabilities (people, financing, and tech) to get a new business off the ground.

Early stage startup ☄️: Build 🛠

One of the biggest challenges in early stage is making due with limited resources. Since startup teams tend to be scrappy and resourceful, they'll often choose to build their own API proxy. This is a great option if you have the time and resources to do it. It's also a great learning experience for your team. You'll learn a lot about API consumption, and you'll be able to build something that's tailored to your needs.

It's easy to fall into the trap of "I can build this in a weekend" syndrome. It's important to be aware of this bias. What features do you need? How long will it take you to build them? If you fail, what's the bailout condition?

Early stage startup ☄️: Buy 💳

When early, you're usually trying to mostly prove something. And that thing is probably not your ability to build an API proxy!

There are a lot of opportunities in an early stage startup: you can do things right from the beginning, people are energized by possibilities, and there shouldn't be any rigid preconceptions.

Of course, paid solutions aren't necessarily better than free ones. But the best ones are almost always better than the ones you can build yourself.

Early stage startup ☄️: Verdict ⚖

Buy a solution that is fast to integrate.

Unless API consumption is core to the business offering of your product, you should probably go with the "Buy" route.

Since you haven't proven your Product Market Fit yet, any time wasted on building infra could be spend proving (or disproving) more business ideas.

Speed is the name of the game in the early stage: and the paid solution is already built, you can start using it right away.

Here are some tips to buy a solution that can fit your budget:

Look for Open Source solutions that are simple to deploy and have sensible configuration defaults, and that CAN scale (with money) later on. This is a middle-ground option: you can decide to self-host and save the cash. If the OSS option you're looking at is professional, it will have a paid option that you can switch to later on. Make sure you check the license, as well. Not all open source licenses allow you to use the software for commercial purposes.

Look for the flexible pricing options. Buy a solution that offers usage-based, monthly-based, easily cancellable and totally transparent pricing. The point of a runway isn't to walk as slow as you can, it's to gather enough momentum to take off. Take a good look at the pricing model of the solution you're looking at. If it's monthly, you can try it out - if you hit that PMF, great, if not, you can cancel it.

Buy a solution that has a free tier. This is a great way to try out a solution without a ton of risk. If you hit that PMF, you can upgrade to a paid tier. If not, you can cancel it.

Ask about startup deals! A lot of companies offer special deals for startups.

🪐 Disk of debris: Growth Stages

"Accelerated growth: Things are moving forward within your company but a scale-up or plan for expansion may be needed by creating new structures, processes, or personnel."

― The First 90 Days, Michael D. Watkins

You're growing fast from finding your product-market fit. Like the "Disk of debris" stage of our moon. You're starting to get some traction, and you're faced with a new challenge: how do you scale your business? 🪐

Words that sounded like a joke a few months ago are now a reality: "What about our SLA?", "How do we handle this many users?", "This customer needs our
solution to be SOC2 compliant", or "We need to start optimizing our costs".

You need o11y, security, cost analysis, and a way to do all those things at scale - while making sure your team still delivers a lot, and at speed.

You also have other challenges: Integrating many new team members, and putting in structures and systems to permit scaling.

At this point, API consumption problems mean business problems for you. If you don't have a solution in place, you're probably losing money: outages, downtime, slow performance, and even security issues. Also, there might be opportunities you're missing out on: BizDev partnerships with the companies behind the APIs you interact with the most, cost optimizations, and more.

Accelerating growth 🪐: Build 🛠

Building your own API proxy when the team can't fit in a single room anymore means that you're building an internal product: it This is engineering for the engineering team, and it happens quite often in R&D organizations. This is "internal tooling" because it's just there to make sure your business works; and while the Product org will be furious if it's not there, the best case scenario is that they don't even know it exists.

Building internal tooling is a great way to learn about your business, and if you're rapidly growing, perhaps you can afford to dedicate a team to it. The key is to make sure that you're not building something that's not 100% tailored to your needs. In a growing org, that means that someone will have to play the role of Product Manager for this product.

Accelerating growth 🪐: Buy 💳

When you're growing fast, you need to make sure that the API proxy you're working with is reliable, secure, and scalable. One big red flag is if you have to think about your API proxy when closing deals. It should never be in the way of your business - just assist you with reliable API consumption.

You should also consider integration with your existing tooling. If the API proxy works only with REST and you use gRPC, even if you get a great deal, you'll end up building a gateway anyways!

Accelerating growth 🪐: Verdict ⚖

‍

There's a good chance that you're already using an API proxy, and that you're actually deciding on an upgrade right now.

There are a few bars that the API proxy must pass to even be considered:

Failsafe: If the API proxy goes down, it should not affect your business.

Secure: The API proxy should not be a security risk. If all the API calls have to go "someplace else" that's not where your software is deployed, you might be introducing a security risk that can kill deals for more serious verticals such as Government and Healthcare.

Scalable: The API proxy should be able to scale with your business. If you get performance issues and they are not easily debuggable, you might waste time and money trying to figure out what's going on.

There's another consideration that's not a must, but should be considered: testability. If the API proxy you're building or buying is not simple to deploy in a testing environment, you're just getting a shiny new footgun for your team. Since most options on your radar should be able to pass the "Failsafe", "Secure", and "Scalable" bars, you should also consider how easy it is to have the API proxy as part of your testing environment - both locally and in various CI/integration environments.

Since at this point you probably have an API proxy in place, you should evaluate both options: build and buy. If you're building, you should make sure that you know that you'll be able to meet all these requirements within your budget and workforce. When looking at options to buy, look for solutions that are built for systems that look like the one you've built.

I will also recommend checking out this great blog post: LET A 1,000 FLOWERS BLOOM. THEN RIP 999 OF THEM OUT BY THE ROOTS. It talks a lot about the economics of building internal tooling (for Engineering Effectiveness mostly, but the logic stands).

🌕 Full moon: Sustain success

"You get installed by the pragmatists as the leader, and from then on, they conspire to help keep you there."

― Geoffrey A. Moore, Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers

Like the "Moon" lifecycle stage, you collected all the energy and debris, and not you're where you wanted to be. The name of the game is to stay there. Your product-market fit is proven, and you're scaling your business. What are the challenges you're facing now? 🌕

You're probably facing a lot of challenges with the same underlying theme; maintaining your success. That entails a lot of things, but the main things you need to look at are Cost optimization, Security, and Ability to innovate.

In a successful company, you're probably using a lot of APIs. Usually, unless the company put focus on architecture from the get-go, you might have some APIs going through a proxy, and some not. You might have some APIs going through multiple proxies. You might have some APIs that are not even used anymore, but you're still paying for them. You might have some APIs that are used by multiple teams, and some that are used by a single team. 🍝 Spaghetti, anyone? This means that getting one great API proxy has a lot of value for you; consolidating your API consumption into a single place can help you optimize your costs, improve your security, and help you innovate faster.

It should be hard to introduce change in a large company: both system and culture-wise. That doesn't mean you shouldn't do it! But it does mean that you should only do it if there's a real pain point that you're trying to solve. Remember that the pain point should be a business pain point, not a technical one; that way you'll be able to quantify the value of the change you're introducing.

Full moon 🌕: Build 🛠

When building an API proxy for a large company, the maintenance costs are starting to become a real factor. The API proxy is not the "let's set up lunches" SlackBot you built in an hackathon one afternoon, it's critical infrastructure. There are real pros and cons to building your own API proxy. The biggest pro is that you can tailor it to your needs. The biggest con is that you have to maintain it continuously.

Maintaining the API proxy you've built mean you have a skill dependency. If the person who built it leaves, you'll have to find someone else to maintain it; you need all the on-call engineers to be familiar with it; and you need to make sure that the API proxy is always up to date with the latest security patches. That means that the "cost" benefit of building your own API proxy is not as clear as it was in earlier stages, since it might be more expensive to maintain it than to buy a solution. The expectations from your customers are also higher: government agencies, healthcare companies, and other companies that have a lot of regulatory requirements will not be happy with a homegrown API proxy that isn't compliant with various regulations (such as SOC2, HIPAA, and more). A home-grown API proxy is another component that needs to adhere to these strict regulations.

The main benefit of building a custom API proxy is adaptability. But when serving more than 3-4 engineering groups, the API proxy will have to be pretty generic and not tailored to any specific use case. That means that the benefit of adaptability is not as clear as it was in earlier stages.

Full moon 🌕: Buy 💳

In an enterprise context, the development process is sometimes referred to as a "delivery train" - and it's a great analogy. The biggest benefit you can get from buying an API proxy instead of building one is predictability: you know what you're getting, and you know when you're getting it. You can plan the rest of your delivery train around it - your team won't be the one causing delays.

The cost question is also a big one. When you're buying an API proxy for a large enterprise, you can usually get a better deal than a startup; but it's still going to be a large red chuck on your budget spreadsheet 📊. You need to be able to quantify the ROI. Proxies that have great dashboards and observability can help you quantify the ROI, and make sure that you're getting the most out of your investment, and even help you navigate upsells and renewals to get the most bang for your buck.

When looking for which API proxies to buy, you have two options:

1. Find a promising startup, and join as a design partner. This is a great way to get a great deal, and to make sure that the API proxy you're buying is tailored to your needs. The downside is that you're taking a risk on a startup, and that you might have to switch solutions if the startup doesn't make it.

2. Find a mature company that has a leader offering. This is a great way to get a solution that's already proven, but you might not get the same level of customization. Look for reports from analysts such as Gartner and Forrester to make sure that the solution you're looking is a "Leader": meaning it executes well today and is well positioned for tomorrow.

Full moon 🌕: Verdict ⚖

Consider the project's cost, and unless you already have a great home-grown solution, buy.

Finally, whether you decide to build or buy, implementing a new proxy across a large organization is a big project. So you should make sure that you're doing it for the right reasons. But if you've already decided to consolidate, then you should buy a solution, not build one.

The main reason is that the cost of building and maintaining an API proxy is a bad strategy for trying to maintain your company's success: from a cost perspective, it's wise to consolidate your API consumption into a single pane of glass for the o11y value. From a security perspective, maintaining and upgrading an API proxy is a big risk that your customers won't want you to take. From an innovation perspective, you want to make sure that your team is focused on building your vision and keeping you a leader in your market, not building internal infrastructure.

However, the bar for the proxies you can buy is higher than ever. They have to scale, be reliable, simple to implement, well documented, fit various regulatory requirements, and more. You're pretty much limited to the "Leader" offerings in the market from mature companies, or to taking a risk on a young product from a startup. Take this vendor assessment seriously, and make sure that you're not just filling out a spreadsheet with checkmarks! You should also make sure to evaluate the vendor on a regular basis to make sure they're keeping up with your needs.

More tips for finding the right solution

If you're still unsure, here are some extra suggestions that are relevant to every stage you're in.

Look for the community 🚌

The first suggestion is to look for the community. Whether it's other companies you work with, Slack groups, or online forums; find out what other people are using. You can learn a lot from other people's experiences - what fit their stack, what didn't, and why.

A big reason to go with open-source projects is that they usually outperform closed-source projects in terms of community.

Look for flexibility 🧘

The second suggestion is to look for a solution that's flexible. You want to make sure that the solution you choose can grow with you. You don't want to choose a solution that's going to be a bottleneck for you in the future, and that you'll have to switch.

There's a good chance that your company will change a lot in the next few years. Flexibility can be measures in many ways, but here are a few things to look for:

Pricing: You want to make sure that the pricing model is flexible. You also want to make sure that the pricing model is transparent. You don't want to have to guess how much you're going to pay.

No-downtime updates: Make sure that whatever you deploy, doesn't require downtime for upgrades and updates. These are needed to keep your system secure and optimized - and you don't want to have to take your system down because of a 3rd-party dependency.

Open source: Open source solutions are great because they're flexible by definition. You can always fork the project and make changes to it. You can also contribute to the project and make sure that the changes you need are implemented. You can usually also self-host the solution, which gives you a lot of flexibility.

Make a decision! 👩‍⚖

"The Cult of Done Manifesto" is a set of principles written by Bre Pettis and Kio Stark. Let's take a page out of their book and apply it here:

There are three states of being. Not knowing, action, and completion.

People without dirty hands are wrong. Doing something makes you right.

Our final suggestion is to be decisive. You don't want to spend too much time evaluating solutions. You want to make sure you're making an informed decision, and this post was here just for that. Now you can cut down on the time you spend evaluating solutions, and spend more time building your product! 🚀

How can Lunar.dev help?

Assisting developers in crafting incredible applications using APIs is the core mission behind lunar.dev 🌑 🌒 🌓 🌔 🌕. Lunar is designed to streamline your interactions with your business-critical APIs.

With our open-core API proxy, you can easily manage your API consumption, at any stage your company is in.

Lunar.dev is the more coherent alternative for overseeing and managing the third-party APIs that your business relies on, ensuring a smooth and secure journey through the vast universe of application interactions.

‍

If you want to manage your 3rd party API consumption with no sweat, consider giving Lunar.dev a try!

Try out our Sandboxes (fully free, no need to enter any credentials)

Or check out the documentation and OSS Repo