Shomik Ghosh - office hours with a DevTools investor
Jack pitches a hypothetical React Native chat SDK to a Bold Start VC as a live office-hours exercise. The first real test money on the table: a hypothetical $200k contract from a company like BP. Shomik Ghosh's answer is to say no — Auth0's first customer was a similarly large on-prem contract, and it warped their roadmap for years.
Shomik Ghosh is a partner at Bold Start Ventures, focused on developer tools investing, with portfolio companies including Snyk and Superhuman, and writer of the newsletter Software Snack Bites.
This episode is a live working session: Jack pitches a hypothetical chat SDK for React Native, and Shomik walks through how he'd think about narrowing the target market, choosing an open-source license, handling an unexpectedly large early enterprise contract, and diagnosing a growth slowdown after early open-source success.
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.
For a hypothetical chat SDK aimed narrowly at React Native, is narrowing the market that much actually a smart move, or does it just shrink the opportunity?
It's clearly a big pain point — plenty of developers want to build chat natively into applications, and writing that from scratch is time much better spent on the core product. Narrowing to React Native specifically compresses an otherwise impossibly broad problem: is your user a back-end developer, a front-end developer, in which framework? By picking one community, you already know where they hang out — specific conferences, specific Discords and Slack channels, specific well-known influencers. People worry that narrowing reduces total addressable market, but actually the opposite is true: starting broad means competing with more products and diluting your own messaging trying to speak to too many personas at once. The largest eventual markets almost always start from the narrowest, most acute pain point, because that's where you avoid all that competing noise.
Once you've won an ecosystem, how do you actually expand from there?
Nothing about this is static. Once you've saturated the React Native ecosystem, you can either broaden your product suite within it — chat leads naturally into customer support or SMS messaging — or replicate the same playbook in an adjacent developer community, like Vue or Angular. Snyk is a good real example: they started narrowly flagging vulnerabilities specifically in the Node.js community, proved the pain was real and deep there, and only then expanded into Python, Java, Ruby, and other languages.
How should a founder decide which parts of a product to open source?
It depends heavily on the specific developer community you're targeting. If React Native developers are already comfortable exploring and contributing to open-source projects as part of how they discover and evaluate tools, that's a strong signal open source is a good entry point for that specific ecosystem — but that may not hold for every developer segment. The next question is whether looking under the hood actually helps that developer — does visibility into how it works build trust, enable customization, or let them contribute integrations you haven't built yet themselves. People commonly try to think three or four steps ahead — what to keep proprietary, are we giving away the secret sauce — when the more useful question is simply whether opening the core even makes sense for that specific end user's way of working, given the actual pain point you're solving.
Doesn't open source risk commoditizing your own growth, if anyone can just self-host instead of paying you?
It's better to think of open source as a sandbox rather than something that cannibalizes revenue. If you nail the underlying pain point, let developers freely explore the open-source project, and then offer a managed service layered with the enterprise features they actually need — RBAC, SSO, painless integrations with their existing tooling — by the time they've read the documentation and trust what they're looking at, a lot of them will happily pay for the managed version just because it makes their life easier. And if some of them do choose to self-host and extend it themselves, they often end up contributing improvements back to the open-source project, which improves the experience for everyone and generates more leads for the managed version. That symbiotic loop is genuinely powerful once it's working.
What license should an early-stage open-source dev tool actually use?
For the most part, especially early on, pick whatever license creates the least friction for developers to actually use the product — MIT or Apache are usually the right call. Some founders, especially in the database space, have shifted to more restrictive licenses specifically to stop large cloud providers from forking and reselling their project, but a restrictive license early on just adds legal friction and hesitation exactly when you're trying to remove barriers to adoption. You can always revisit that decision later, the way Elastic, Mongo, and Confluent did once they'd reached real scale — but that's a later-stage problem, not a day-one one. Realistically, a cloud provider only bothers forking something once it's genuinely huge; a hundred thousand downloads, which is a great milestone for an early company, still isn't remotely enough to be on their radar.
If a company like BP shows interest in using an early-stage open-source project, and dangles a $200-500k contract, should you take it?
Congratulations are genuinely in order, but the real question is whether your team, at this stage, should be focused on the sales cycle a large enterprise like that requires — the security review, enterprise feature requirements, and procurement process are going to be a long, resource-heavy slog. It's incredibly tempting when that much money is suddenly on the table, but taking it this early risks completely skewing your roadmap toward enterprise requirements before you've even validated whether the broader market of millions of other developers actually has the core pain point you think you're solving. Auth0's very first customer was reportedly an insurance company with a large on-prem contract, which then had to be maintained for the company's entire lifecycle — a real ongoing tax on the team's time and focus, running in parallel with a much larger base of self-serve cloud customers on a totally different release cadence.
If you turn down that big early contract, what should you actually focus on instead?
Figure out whether your open-source project is genuinely resonating with your actual target persona, not just with an unusually sophisticated team — a large enterprise might have hired an ex-Facebook React Native lead who understands everything intuitively, which tells you nothing about whether a developer who's barely used React yet can actually follow your documentation and deploy it successfully. If your early adopter is too advanced, or not the persona you intended at all, the feedback they give you will skew your roadmap away from your original core user. Before even deciding hosted-versus-self-hosted, get the fundamentals of the open-source project right: the README, documentation quality, how you handle contributors and issue requests, what your SLA is on responding to them, how you build the community around it. If a Discord you spun up fills entirely with sophisticated engineers from one big enterprise customer, that might quietly scare off the exact broader audience you actually need.
Is there a real trade-off between chasing a big early logo and optimizing for learning speed?
Snyk's first sales hire, Ethan Schechter, has a phrase for this: trade dollars for speed. A $200k enterprise contract sounds enormous, but the deployment and validation cycle at a company that size is going to be dramatically slower than a $5k contract with a customer who starts using the product immediately, understands it's early, and gives you fast, tight feedback loops. The compounding learning you get from that smaller, faster customer can genuinely outpace what you'd learn waiting for a large org to even finish deploying you internally.
If open-source and early hosted growth start slowing down after initial success, how do you diagnose why?
Much of the answer traces back to decisions made from day one. A slowdown might mean the community itself never had enough critical mass of engaged users helping each other through onboarding friction — early on, a handful of committed users might carry newcomers through a hard step by reassuring them it's worth pushing through, but that only scales so far before you need to actually fix the underlying friction point in the product itself. It's also worth examining whether your early growth came from a top-down motion — warm intros through VC and founder networks — that produced happy early customers and real revenue, but never forced you to build the documentation, content, and community infrastructure that a genuinely bottom-up, developer-led growth motion depends on for the long run.
How do you know in advance whether a product should grow bottom-up or top-down?
It comes down to whether an individual developer can unilaterally get real value from the product, or whether the value only exists at the scale of an entire organization. Something like endpoint security only makes sense across a mass of endpoints — a single engineer with one laptop has nothing meaningful to secure, so the decision has to come from a CISO or VP of engineering who can commit the whole org. Something like scanning open-source dependencies for vulnerabilities is valuable to a single developer working alone, right now, on their own code — which is exactly why Snyk could grow bottom-up while something like CrowdStrike structurally cannot. Understanding which category your product falls into early prevents you from wasting time on bottom-up developer adoption efforts that were never going to pay off, or trying to force a single-player product through an unnecessarily heavy top-down sales motion.
What's the one thing you'd want an early-stage dev tool founder to take away from all this?
Start by deeply understanding your end user and their specific pain, and go as narrow and deep on that persona as you can — that's what makes an example like 'React Native developers building chat' actually useful, because it tells you concretely who they are and how they work. That matters far more than mapping out your eventual business model, pricing, or how you'll expand from chat into SMS and beyond — none of that is reachable if you never get the first step right. Get developers genuinely using the product and embedding it into their daily workflow first; pricing and delivery model decisions become much clearer once you're watching real usage rather than guessing in advance.