Ellen Chisa - Partner at Boldstart Ventures
Ellen Chisa's answer to "should I build a second SDK" is blunt: the number is always one. If a Python developer says no thanks because you're JavaScript-only, that's not evidence you need a Python SDK — there are plenty of JavaScript developers in the world.
Ellen Chisa is a partner at Boldstart Ventures, investing in developer tools and infrastructure at inception, including Snyk and Zuplo. Before that she co-founded Darklang, an integrated programming language, editor, and platform, alongside a co-founder of CircleCI, and worked in product at Microsoft, Lola, and Kickstarter.
We get into why she thinks saying yes to one more SDK is really a hundred invisible no's to everything else on your roadmap, how she used one obsessively-refined ten-minute demo to learn what actually mattered to Darklang's users, and why she thinks 'busy work' — the meetings, the rejections, the interstitial time between building — is an underrated part of what makes any job in this space enjoyable.
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.
How many SDKs should an early-stage devtools startup actually build?
The spicy answer is one, and always one — though it depends on what you consider a startup. When founders ask if they should add a Python SDK on top of their JavaScript one to juice their user numbers, the answer is usually to keep doing the one thing well and reduce your surface area so you can keep iterating and making it better for the users you already have, rather than shipping a new SDK every few weeks. Wait until people are genuinely banging down your door for the next one.
What if a potential user tells you they can't use your tool because you don't support their language yet?
At some point you have to decide who you're building for and build for them. If you're building for JavaScript developers, there are certainly enough of them in the world that the limiting factor right now shouldn't be a shortage of JavaScript people — you probably just had bad luck with the first person who happened to be a Python developer. It's genuinely tempting to want to do right by anyone who shows interest, and it can feel like you're being responsive to users, but someone isn't your user yet until they're actually using the product. That's being responsive to potential future users at the direct expense of the users you already have today.
How do you actually decide when a 'yes' to a new feature request is the right call?
You only have so much time and surface area in your product, so every yes is implicitly a hundred no's you're just not saying out loud — and making that trade-off explicit makes saying yes feel a lot less automatically good. I tend to ask: if we build this and it's successful, what do I expect to happen afterward? You should have that hypothesis in mind before you build, and if you don't have one, that's usually a sign you shouldn't build it yet. Concretely, imagine you've had a JavaScript SDK for three months with only five users, but you keep hearing from Python developers who want one — if you build the Python version and get ten users in the first week, that's a strong enough signal to justify shifting focus. I see far more founders make the opposite mistake: trying to cover the whole language landscape right out of the gate instead of exhausting one community first.
Why is that harder than it sounds — isn't shipping a second SDK often quick?
Developers are not a monolith. Different language communities have completely different norms, different tools they're already using, and different culture around how they discover and evaluate things — you're fitting into a different tool stack every time you target a new one. If you already know who's influential in the JavaScript world and what people there read, that context doesn't transfer to Rust or Go communities at all. There's a lot more under the hood to actually getting an SDK to take off in a new community than just writing the code, even when a generator can produce the SDK itself quickly.
What's a good north star metric for a developer tools company, versus a vanity one?
Number of signups or GitHub stars doesn't really matter — what matters is developers actually using the product and getting value from it on a regular basis, accounting for reasonable patterns like usage dropping on weekends if your tool is a workplace tool. There's also a lot of overlap with consumer growth loops: you want developers who are so much more productive using your tool that they tell five friends about it, the same virality loop you'd design into a consumer referral program.
How does the business model side differ between devtools and consumer products?
Consumer products usually have one clean purchase point — a subscription, a physical good. Devtools businesses are less often a flat $10-per-developer-per-month and more often lean enterprise, frequently overlapping with an adjacent team's budget — Snyk overlapping with the security team, for instance, or the CIO's office — which is why a company might sign a five or six-figure contract structured around usage, tokens, or credits rather than per-seat pricing. Early on with Darklang, I assumed that in the very long run, once we'd replaced enough of the stack, we'd charge for infrastructure the way AWS does. But replacing something like AWS takes a very long time — companies already have deep, comfortable cloud contracts. I'd think less about charging for infrastructure directly and more about what people no longer have to do, and what pain they're avoiding, because your tool exists.
What kinds of pain points make for the best developer tools businesses?
The canonical examples are Twilio, for how painful it used to be to integrate with a telecommunications provider directly, and Stripe, for the same kind of pain in finance. It doesn't have to be technically complex so much as important and genuinely painful — people have to be deeply unsatisfied with how they do it today and actively looking for something better. With Zuplo specifically, the existing API gateway infrastructure companies were heavily enterprise-sales-motion — no self-serve sign-up button, just a demo call with a salesperson — and there was a real gap for a gateway with full programmability, where a developer could adopt just one piece, like rate limiting, rather than the whole thing out of the box. The pain wasn't just technical; it was that developers couldn't self-serve access it at all.
How should an early founder think about creating a brand identity without an existing following?
This is one of the hardest things to actually teach, because it comes authentically from the founder — your company is going to feel like you, flaws included, reflected back a thousandfold. The most reliable way to build that ethos is being out there with your product yourself, rather than assuming you can hire a salesperson to carry the story for you — talking about it online, going to every meetup on the topic because you're genuinely excited to talk to people with the same problem. However you authentically talk about what you've built is what actually creates the brand feeling around it. The founders I admire most, like the Zuplo team or Liveblocks' founders — who came from building a design tool together — have one thing they're spikily, obviously great at, and it shows up consistently in the product, the writing, and the team.
How did you use a single demo to learn what actually mattered to Darklang's early users?
There's a ten-minute demo of me building an office sign-in application in Darklang, in one take, that I'd effectively performed in almost every meeting for about a year before I got to that final version — watching how people reacted each time and noticing which moments people really needed explained to actually understand it. In parallel, I did a lot of live pair programming: getting someone on the phone, asking what they wanted to build, and building it together hands-on-keyboard. That taught me about people's different mental models — whether they wanted to start from a template or already had a specific thing in mind — and about ergonomics: Darklang's structured editor worked well for relatively inexperienced programmers or people mentally flexible enough to try anything new, but it was genuinely painful for someone who'd been an expert in one language for fifteen years and had a fixed way of thinking about code.
What do you look for as an investor that's different because you've actually built a devtool yourself?
I spend an unusual amount of time asking people why they built their product a specific way — not to judge whether the current version is good or bad, since it's not going to stay static, but as a lens to understand who they are and what they're motivated by. For a lot of developers and product people, the product is a manifestation of their ideas, almost like art, and interacting with it is the best way to actually understand how a founder thinks about their company. I also think a lot about message segmentation as devtools scale: talking to a JavaScript conference at a high level about the future of collaboration won't land, and pitching a CIO on deep technical specifics won't either — you have to nail the message to the specific audience in front of you.