Killing features with Josh Twist, founder of Zuplo
Josh Twist helped build Azure API Management at Microsoft, then left with a list of ways he thought it should change. Zuplo is that rewrite — API gateway configuration stored in git instead of a database, priced for a startup instead of a Fortune 500 procurement team.
Josh Twist is the founder of Zuplo, an API gateway and management platform. He previously founded Azure API Management at Microsoft — a direct Zuplo competitor — and later worked at Facebook and Stripe.
We get into why he thinks API management has only ever been built for large enterprises, the 'code is cheap, infrastructure is not' philosophy behind Zuplo's architecture decisions, why he rewrote the product's core routing format around OpenAPI even though it broke things, and the tripwire-laying approach to partnerships and content that got Zuplo its first customers.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You actually built a direct competitor to Zuplo at Microsoft. What did that teach you?
I moved to the US and became a product manager at Microsoft, founding several Azure products, one of which was Azure API Management — a direct competitor to Zuplo, acquired through a company called Apigee. I've been looking at this market for a long time, and later worked at Facebook and Stripe, both very API- and developer-focused roles. When I left the API Management team at Microsoft, I actually left with a list of suggestions for how to make the product fundamentally better. My core observation is that API management has really only ever been built for very large organizations — expensive, difficult to learn — and I felt there was a huge missed opportunity for a product that helps even small startups launch a great API experience out of the box.
What specifically is wrong with how existing API management tools work?
Two problems shaped Zuplo's whole manifesto. First, these tools are too hard to learn because they don't fit into a normal development workflow — a lot of configuration lives in a database, which as an engineer is a bit like being told to store lines of code in database rows; you'd throw up. From day one, we made everything text-based, so the entire gateway configuration can be saved in git, enabling GitOps and everything that comes with it. Second, these tools are crazy expensive, because only large companies can afford them — a startup isn't going to pay six figures just to get a salesperson out of bed. If we could build something as easy to use as a developer would want, priced so it's cheaper than hiring engineers to build and maintain the same thing yourself, that's a winning proposition: you don't want to own the workload of authentication, API keys, and distributed rate limiting yourself if buying it is cost-effective.
Why do developers often try to build this stuff themselves rather than buying it?
Opportunity cost, really — and honestly, engineers loving to build things themselves is probably my biggest competitor, especially at the small end of the market. A customer of ours, the head of engineering at Rewiring America, put it well: if he can buy this at a reasonable price, he can spend his best engineers' time on problems unique to his actual product, rather than reinventing API key management and rate limiting to a lower quality than what he'd get out of the box. Don't waste time thinking hard about API key authentication best practices — just use a solution that's already secure and move on to the API that actually matters.
What are some concrete things you've done specifically to make the developer experience good?
GitOps is a big one — hat tip to Vercel and Netlify for mainstreaming this pattern — where a push to GitHub deploys every branch as its own environment. That's a genuine shift in the API management landscape, where spinning up a new environment with other tools typically takes hours and costs real money; we have customers running 250 concurrent production environments because collaborating and previewing is just that easy now. We also support full change history through whatever git tool you already use — GitHub, Bitbucket, GitLab. And critically, Zuplo is programmable: I'm still an engineer at heart, and nothing frustrates me more than a tool that blocks me from using code to solve a problem. Our extensibility layer is built entirely on web standards — Fetch, Request, Response, the same things you'd find on MDN — so writing an extension for Zuplo should feel exactly like writing JavaScript in a browser or in Express, not like learning some unintuitive, Zuplo-specific API.
You've talked about 'removing friction' as a core design principle. Where does that come from?
I learned the power of removing friction at Facebook, which runs an enormous number of experiments and has fantastic tools for measuring even small impacts and how they compound over time. Most prioritization frameworks focus on impact versus cost for big features, and in doing so miss the death-by-a-thousand-cuts problem — the accumulation of small friction points that developers feel constantly. My favorite example of a product built almost entirely around removing friction is Loom — recording and sharing a video was always technically possible with QuickTime and S3, but Loom removes every bit of friction in between: it uploads in the background while you record, so the moment you're done you can send the link immediately without waiting or thinking about permissions separately. We try to think about every feature at Zuplo the same way — the ideal experience should feel like a slippery funnel where you can't help but fall into the pit of success.
How do you balance making a product simple for beginners while still being powerful enough for advanced users?
It's easy to build a simpler version of something by just cutting features, and it's easy to build something complicated and powerful. The real art is a product that's easy for a beginner but scales step by step into something genuinely powerful, without ever losing that gentle onboarding glide path. There's a good analogy to video game design — Mario starts you off just running and jumping left to right, and by the final level you're dodging Bowser's fire. Good game designers build that incremental step-up deliberately; there's no clean flowchart for doing the same thing in product design, but that's the goal. As a company grows, it's easy to get lazy and just bolt a new feature on — the discipline is going back and asking how it affects onboarding and how much conceptual overhead it adds to a beginner's mental model of the product.
How do you decide whether to rework something fundamental versus just adding a feature on top?
One exercise I find useful: imagine you were designing the product from scratch today, knowing about this new requirement — how would you build it differently? Then weigh that delta against the cost and disruption of actually redesigning it, especially with large enterprise customers who hate breaking changes. We're willing to rewrite things a lot at Zuplo — I got the phrase 'code is cheap' from an old boss, Vijay Rajah — a bit like Formula One redesigning the whole car every time regulations change, even though that feels painful after years perfecting the previous version. It's a prioritization trade-off like any other: if the redesign is significantly better, it's usually worth doing.
Can you give a concrete example of a breaking change you decided was worth making?
When we launched Zuplo, we built our own JSON schema called Routes.json to define the gateway's routing table. Over time, it became clear how invested many of our customers already were in OpenAPI, the open standard for API specification, and we realized we should have just extended that format instead of inventing our own. Rewriting the routing table is about as fundamental a change as you can make to a gateway, but we decided it was worth it — we built a CLI conversion tool so existing Routes.json configs could be turned into OpenAPI documents, kept the old version running for anyone who needed it, and now Zuplo is OpenAPI-first. Customers already using OpenAPI get a better developer portal experience and no longer have to translate anything into our proprietary format — a genuine friction-removing decision worth the disruption.
You've talked about deliberately killing features. Why is that important, and why is it hard?
Killing features is genuinely hard in B2B, especially if one big customer is using something — Bill Gates apparently used to talk about wanting to kill certain Microsoft products that a handful of Fortune 500 customers used but that would never be a real business. A chart I think about a lot is a histogram of feature adoption across your customer base: you want most customers clustered on your core features with a modest tail, not one dominant feature and then a long flat tail of two-percent features that all cost overhead to maintain. Zoom beating Skype is the example I keep coming back to — Skype had accumulated a huge pile of features nobody used, which became drag, while Zoom focused relentlessly on the one thing that actually mattered: audio quality and latency. Before building a new feature, we ask honestly whether it'll actually reach meaningful adoption — if not, that time is better spent improving what already works. I genuinely enjoy killing features; we recently retired an experiment, being fully transparent with the one customer using it and helping them find another way to solve their problem.
How did you approach partnerships as a small company?
I generally avoid partnerships with other small businesses — there's a saying that two turkeys don't make an eagle, and I don't think it makes much sense for two early-stage companies to partner. Supabase is a different story — they're much closer to eagle status and have done an incredible job on distribution. Early on we tried cold emails, which worked a couple of times but is genuinely like shooting arrows blindfolded into the woods. So instead we thought about laying tripwires where people already interested in this category would naturally walk — sponsoring rate-limiting libraries, since our own rate limiter is a genuinely advanced, distributed, edge-based feature, and sponsoring developer documentation sites. With Supabase specifically, I realized their Postgres API is great but isn't quite API-first enough to ship as if you were Stripe — so Zuplo plus Supabase gives hobbyist and early-stage developers a Stripe-quality experience over a Supabase backend, and that combination has brought us some great customers.
Your videos are genuinely good. What's your process there?
I've just done it a lot over time and gotten better — I invest in decent equipment now, a good mic, headphones so I can monitor my own audio. Some of our early videos, on the Zuplo channel, are honestly pretty rough — wrong aspect ratio because I assumed everyone was watching on their phones, and we barely got any views for well over a year. That's genuinely disheartening, to the point where you feel a bit ashamed asking someone to appear on a low-view show — but nobody's ever actually said anything critical about it, and it slowly built. A recent video crossed 3,150 views before I even noticed. I edit everything myself, watch a lot of other content to figure out what I actually like, and try hard to cut the fluffy intro — I hate landing on a tutorial video and getting five minutes of 'hey guys' before the actual point.
What would you tell someone trying to build a great developer experience?
Really think about every piece of infrastructure you add — code is cheap, but infrastructure has gravity once it's in place; it's much harder to remove than to add. I also love Brian Chesky's idea of designing an 11-star experience — walk through each star level from a normal five-star experience up to something absurd, like Jeff Bezos personally showing up to do it for you. It sounds silly at the extreme, but it makes the five-star version suddenly feel very achievable, and it's a great thought exercise for figuring out what an exceptional version of your product actually looks like. And more broadly: lay tripwires where your ideal customers already are, rather than shooting blindly into the woods hoping to land a cold email.