Sagar Batchu - co-founder of Speakeasy
Speakeasy hired its first employee for developer relations before it hired a founding engineer — because the consulting work Sagar Batchu and his co-founder were already doing for early customers had turned into the content that brings in most of their leads today.
Sagar Batchu is the co-founder and CEO of Speakeasy, which helps teams build, test, and run their APIs, starting with SDK generation. He and his co-founder Simon spent close to a year — including time at South Park Commons — narrowing down from a broad API-tooling idea before finding the version of the problem that stuck.
We get into what their first paying customer actually needed, why leaning into consulting-style work early was a deliberate and underrated choice rather than a distraction from building product, and how they decide which open-source maintainers — like Colin from Zod — are worth building a real relationship with.
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.
What does Speakeasy actually do?
Our vision is to help teams build, test, and run their APIs. We started with SDKs because it's a core developer experience problem a lot of us have felt directly. At my previous company, we built a whole internal API platform to solve this — it was twelve developers for a year to build it, settling to about four in steady state, which is well over a million dollars of cost, and it's not even a well-defined cost most companies track properly. The API producer side has gotten more complex — more languages, more runtimes, more ways APIs get consumed — while most API consumers are still left with a three-pane docs site. That's discoverability, not integration. Integration is actually pulling that dependency into your app, and there's a whole layer of last-mile tooling — versioning, deprecated fields, going from an endpoint to working code in your language — that was missing to give people a Stripe-quality experience.
How long did it take to find the actual problem you wanted to solve?
My co-founder Simon and I started in 2022 and spent almost eight months to a year really working the problem from different angles, and we've had at least one big pivot since. The first three months, we were both still working our jobs and mostly talking to team leads and senior developers about the most painful points in how they ran their products broadly, not just API development — then over time we narrowed the scope. Once we had some conviction, we started building proof of concepts and putting them in front of people. Our very first customer actually churned off our first product entirely — we had to come back with something completely different. It takes time to stew in a problem space until you build enough conviction to spend years of your life on it, and I don't think there's a shortcut through that.
What did your first real paying customer actually need?
We got our first paying customer around November 2022, roughly a year after starting. We'd been talking to them for a few weeks, and it worked because we realized they didn't just want an SDK — they were launching an enterprise API for the first time and wanted a partner to follow them through that whole journey. When you launch an enterprise API, today you might need an SDK, tomorrow you need authentication help, then rate limiting, then everything else that comes with running an API properly. We became their expert on call, even for things we didn't formally offer yet, and we learned an enormous amount from being that close to them.
You've said pro services and consulting are underrated in devtools. Why?
Conventional PLG wisdom says don't do consulting, let everyone self-serve. But if you're trying to work with good-sized companies, they want the confidence of getting a partner, not just a login. Our first five or six customers involved a lot of what people would call pro services — jumping into Slack to help them actually get value, especially around their OpenAPI spec, which is this sacred artifact everything else in their organization gets driven from: documentation, SDKs, auth, the gateway. We became the expert who told them how to write a good spec and design that interface well, and they gained real confidence to go do that because we were right there with them. Looking back, I think we were lucky not to try to productize too quickly and instead play that consulting role for months before hardening the product.
How do you avoid that consulting work turning into an unsustainable trap?
It's a fine line — you can go too far down that road and end up without a repeatable product. What I'd say is don't shy away from running heavy support early; think of it less as 'consulting' and more as running support for an immature product, which is naturally going to take more of your time than support for a mature one. The thing to watch for is repeatability: try to get a small cohort, three or four customers, wanting the same thing, rather than building custom work for one. If two or more customers want the same thing, the odds it's useful to many more people go up enormously. It also helps to stay close to an existing open standard — for us, OpenAPI — because then you're not asking someone to adopt something entirely new, you're making their life better around something they already use.
Did that early consulting work turn into your actual growth channel?
Yes — that's actually why Nolan, our first employee, was a DevRel hire brought on before we technically had a founding engineer. All the consulting work we were doing on API development turned into content, and that content brings in most of our leads today. About three or four months after our first paying customer, we hit a point where things were self-serve and people were coming on board on their own, and our content strategy started to kick in — things like specific OpenAPI how-tos, which are still some of our highest-ranked articles. We also do what I'd call 'engineering as marketing': recently we did a big upgrade to our Python generation and there was an internal debate about data classes versus Pydantic for managing schemas — we turned that into a blog post, because plenty of other teams starting a Python stack are having the exact same debate. I picked a cute title for it originally, and someone on marketing had to tell me it needed an actual SEO-driven title instead.
You've said PLG versus enterprise is a false dichotomy. What do you mean?
Early on I worried we were going against conventional wisdom by leaning toward bigger teams — companies of at least 50 to 100 people total, which over time became more specifically an engineering headcount thing. But I've landed on these being two separate axes: PLG is about how you build the product and company for success — self-service, product-led growth in how someone adopts you — while enterprise versus startup is really a question of who your ICP is. You can be fully PLG and still be selling to enterprise; the largest companies we work with still come inbound and discover the product themselves before talking to us once usage crosses a certain threshold. Our day-zero product — coming in and launching an SDK — is useful to a startup or an enterprise identically. It's what we build after that starts to diverge based on company size, which is where you actually have to make a call about who you're building for.
How do you decide which open-source maintainers are worth building a real relationship with?
It's similar to hiring — we try to work with someone for several weeks in some concrete capacity, treated as a paid contracting engagement: maybe they help us fix an issue in a library we use, write a blog post, or review a design decision in a language they're an expert in. That tells you whether there's real chemistry and shared values, and in a space with high mission alignment, it becomes obvious pretty fast — that's exactly what happened working with the Pydantic team. With Colin, the creator of Zod, we'd shipped a TypeScript SDK generator without runtime validation and felt it was missing what a best-in-class SDK should have, so we rebuilt it around Zod rather than writing our own validation library. Adopting his library is also a long-term bet on Zod's direction on behalf of all our future users, so we wanted to be genuinely sure about it — and he's been generous with insight into the roadmap and deep design discussions ever since. The type of person worth this investment isn't a big-personality content creator, it's someone who's put in the ten thousand hours and has real taste and depth in a space, whose decisions the rest of us trust almost implicitly because their work is core to what everyone builds on.
How do you handle negotiating your roadmap with early customers who all want different things?
You have to remember your earliest customers are buying your roadmap as much as your current product, so lean on that roadmap rather than trying to build everything immediately. When you're early and worried about every customer churning, it's tempting to build whatever's asked right away — instead, deliver the value you can now, then ask if something can go on the roadmap for three months out. Three months feels enormous at a startup, but for most of the companies you're working with, it's a very reasonable timeline — even a month, which feels long to you, is actually good certainty for them to have. And you can honestly sell them on the delay being a good thing: if ten more people are going to use this feature by the time it ships, it'll be more durable and better built than if you'd rushed something custom just for them.
What's your advice for other devtools founders?
Most of us are developers or have been, and trusting your gut and intuition is genuinely valuable — but don't forget to actually listen to what your customers say. You're building for the 99% of developers, not the 1% who think like you, and eventually you have to sell to developers outside the Valley and outside Hacker News, including developers at Fortune 500 companies whose day-to-day experience looks nothing like yours. Back your intuition up with a genuinely wide range of developer perspectives, not just the ones closest to you.
Links & references
This episode is brought to you by WorkOS's Enterprise Ready Conf.