The API Tooling Crisis
efp.asia
efp.asia
AI makes it harder for vendors to enshitify products by adding bloat, gating features, or inflating enterprise pricing, without losing customers. Teams can spin up internal alternatives quickly.
I’d argue this extends beyond API tooling. In our organization, we considered FinOps tools like Vantage or ProsperOps to manage cloud costs. They can get expensive. Instead, we piloted having Claude build a focused internal tool that delivers similar outputs but only includes the features we actually need. It turned out to be surprisingly effective. Not identical, but good enough without the enshitified enterprise price tag.
AI is shifting buy vs. build decisions. Vendors with real differentiation will be fine. Those relying on pricing complexity or inertia may struggle. They’ll need to treat their customers better instead of focusing solely on short term profit if they want to exist more than a few years.
But where things are still hard is maintaining that tool, security, reliability, UX, integrations, and long-term tool evolution - especially when its not core to their business.
Those don’t disappear just because the first version was generated quickly. Operating a tool well over years is still expensive and requires discipline. Again that is not to disagree with your statement, but trying to highlight the difference between building a plane vs operating an airline. there are significant challenges that should not be discounted.
But I see the issue around existing tools - why they end up becoming unfriendly to developers or development teams when they all start with great intentions is because their entire business identity is tied to being “the API tool.” Be it postman, insomnia (perplexes me even more why kong has to push it so hard), even bruno to some extent is forced to find a viable monetization strategy. In any case, all this creates strong pressure to monetize aggressively. When survival depends on one product, paywalls, feature gating, and pricing complexity become almost inevitable, even with good intentions.
Part of why we built Voiden differently (https://github.com/VoidenHQ/voiden) is that it started as an internal tool. We used it ourselves for nearly two years, shared it with few teams to get feedback and incorporated it, before open-sourcing it. We also run an established API marketplace, which is our actual business. So Voiden isn’t something we’re trying to turn into a product line. The intent from the start has been to treat it as long-term community infrastructure — closer in spirit to tools like VS Code or Backstage — open, free, and evolving in the open.
Interestingly, much of what the article describes as the “ideal API tool” maps closely to how Voiden ended up being designed. That’s largely because we never tried to build “a better Postman” or “an open Insomnia.” We wanted to rethink API tooling from the ground up: markdown-based workflows, reusable blocks, versioned artifacts, and workflows that work well for both humans and AI agents. No need for Postman's Postbot or whatever AI solution the tools are locking the users into - use the integrated terminal in Voiden to use claude or any other agent of user's choice.
Maybe I’m going out on a limb, but I think this style of tooling will become the norm over the next few years, or at least push the category to evolve.
AI is changing how fast we can build. It’s not changing what ultimately matters: trust, usability, sustainability, and developer experience. Teams will keep using tools that respect those fundamentals, and walk away from ones that don’t.
And to be clear, I’m not sharing this to promote Voiden. The broader point is that we need more genuinely novel approaches to modern API challenges. Voiden is just our take on that problem. Other teams will arrive at different answers, and that’s healthy and I want people to be bold enough to shed the legacy tooling's "hangover".