Bringing Feedback Loops to API Development
At Zuplo, we believe that the best way to build is with tight feedback loops.
Not just at a product or project level - although we obsess over receiving quick feedback from customers - but also at the development level: we love using and building dev tools that have short feedback cycles.
Let's categorize these feedback loops as a macro (product) and micro (dev) feedback loops.
Building products: macro feedback loops#
Making the right decisions when building means that you shouldn't build all the features at once but rather include your end user from day 0. Yes, even at the planning level.
At Zuplo, we achieve this by having design partners: customers we work with closely to build our products, with weekly calls to show them the status. (If you're interested in becoming a design partner, please let us know.
Having customers shape the product does not mean they should shape the vision; that still has to come from the builder. However, the tactics and priorities of the vision should be influenced by who is using your product; this way, you avoid building in a vacuum.
The faster you can get feedback from your customers, the faster you can iterate on your product.
Building tools: micro feedback loops#
When we're building, we are constantly receiving feedback from our tools: from our tests running in the terminal, the type checker in your language of choice, or hot reloading features that allow you to see what you've built in action instantly.
A company whose dev tools we like a lot is Vercel, a hosting platform that improved a lot of the feedback loops of building frontend projects. These feedback loops include:
- Deploying every pull request of your frontend project (quickly) so anyone can preview the changes without testing in production directly
- Providing tools to give comments and feedback directly on the deployed site preview
These tools have been game changers in frontend development and have played a massive role in the success of Vercel because they allow developers to get feedback on their work quickly. And quickly getting feedback is the key to building the right thing in iterations (as opposed to making the wrong thing in one go).
Bringing feedback loops to API development#
The same principles that make frontend development so enjoyable can be applied to API development. This is the reason why we're building Zuplo: a platform that allows you to create APIs with tight feedback loops.
How do we achieve that?
-
Running the API Gateway locally: you should be able to configure the gateway by running it in your terminal with hot reloading, so you can see the changes you make to your API immediately.
-
Deploying every pull request: being able to try every pull request of your API in a preview environment so you can see the changes you make to your API immediately.
-
Extremely fast deployments: we deploy your API in seconds (to 300 data-centers), so you can see the changes you make to your API immediately in production. This allows for maximum flexibility and maximum responsiveness.
-
Providing mocking tools: using them is the best way to get feedback on APIs. Generating a mock version of your API (from your OpenAPI document) allows you to test your API without having to build the backend logic first.
-
Focusing on API's TTFC: when we built Zuplo's API Keys, we focused on the time to first call of the API. The best way to get feedback on your API is to use it, so we made it as easy as possible to do so.
We also love open source tools that help achieve the fast feedback loops in API like Vacuum, RateMyOpenAPI or Mockbin to name a few.
Measuring your feedback loops#
At some point, you need more than just the feedback you get from your users. You'd be surprised at how many times what a user says is different from what they actually do. That's why it's essential to look at the data.
We use tools like Posthog to measure how users are using our products. This allows us to see what features are being used and which ones are not.
At an API level, we have built Zuplo Analytics to measure how your API is being used to help you make decisions based on how the API is used (we use this internally with our own APIs).
We also provide analytics to your API consumers so they themselves can understand how they're using your API.
Conclusion#
Feedback loops all the way down, from product level to development; that's how great engineering organizations are built. We hope to help you achieve the same while making APIs. Let us know what you think in our Discord, Twitter/X, or Linkedin.
