Giving developers what they want with Deepak Prabhakara
BoxyHQ named their SAML product SAML Jackson and leans hard into Pulp Fiction memes to promote it. Deepak Prabhakara's actual growth engine underneath the jokes: he and his co-founder personally monitor keyword alerts on Twitter and jump into threads as themselves, not the company account, before anyone's heard of BoxyHQ.
Deepak Prabhakara is co-founder and CEO of BoxyHQ, an open-source set of building blocks — described as 'Stripe for developer security' — that lets B2B SaaS companies add enterprise-ready features like SAML single sign-on without building them from scratch.
We get into why BoxyHQ started as fully open source and Apache 2.0 licensed rather than SaaS, why they deliberately avoided competing head-on with established auth providers, and the grind of manually monitoring Twitter, Reddit, and Hacker News keyword mentions before the brand had any real recognition.
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 BoxyHQ actually do?
We started BoxyHQ around the problem of developers carrying enormous responsibility, from infrastructure all the way through to building the actual product, and increasingly having to think about security early given the growth in cyberattacks. We asked what 'security in a box' would look like for developers, and built building blocks they can pull directly into their code to make it more robust, compliant, and secure — in a lot of ways, we think of ourselves as Stripe for developer security.
What actually happens to a startup when an enterprise customer starts asking security questions they weren't prepared for?
It's a genuinely complex process, but we can simplify the technical side of it because we've been through this playbook before. The reality is an enterprise isn't buying you for your enterprise features — they're buying you for your core product, the actual workflow you solve. Everything else, the commoditized stuff, is largely undifferentiated. The most common example is enterprise single sign-on, which is typically the preferred way into an application and usually the very first thing enterprises ask about — which is exactly why we built that as our first product.
Why go horizontal rather than staying narrowly focused on one feature like SSO?
We realized quickly that startups usually get asked for two or three of these enterprise-readiness features at once, some of which are effectively mandatory just to get a pilot approved. So our journey started with startups selling into enterprises specifically, because that's the real inflection point where security stops being an afterthought — the moment an enterprise shows up with a security questionnaire and starts probing your compliance posture. Getting those commoditized pieces out of the box from us frees the team to focus on their actual product, and from there we've been growing into developer security needs across companies of all stages.
Why did you choose to be fully open source rather than a standard SaaS product?
We're fully open source, Apache 2.0. Because we sit so close to infrastructure, every developer runs into the classic build-versus-buy question — is this close enough to core to my system that I should build it myself, or is it safe to buy? Open source felt like the natural answer, because that's exactly how I've evaluated software my whole career as both a developer and an engineering leader. Developers don't want to talk to a salesperson — they want to try something against a specific problem and know quickly whether it actually solves it, and open source is what makes that possible.
Is there another reason open source fit particularly well for this specific product?
Yes — we realized developers would want to use this in very different ways depending on their stack. We fit naturally into cloud-native, Kubernetes-based deployments, but we also work in a classic client-server monolith, since you can embed us as a library rather than only running us as a standalone service. Given how diverse developers' actual deployment patterns are, open source was the only model flexible enough to meet them wherever they already were.
What have been the biggest challenges since starting, especially having started the company before the open-source project even existed?
Three things in parallel. First, finding project-community fit before it even becomes a product question — who's actually going to use this, how do they discover it, where do we find them, and why would they stick around. Second, building the actual product while simultaneously searching for product-market fit, since none of that matters unless real people with the real problem find that our solution actually fills the gap. Third, deciding specifically which developers to start with, since 'developers' broadly is far too large a group to target all at once — we raised our seed round last October and only really started building the team and product this past January, so we're still very early in that journey.
Content seems to be a big part of how you've grown. Why lean into that so heavily?
Early on we realized we'd never have the ad budgets a typical SaaS company might, partly because we've intentionally delayed commercialization — we want real adoption and genuine value delivered to the community and product first, before trying to extract any value back. So we've built a lot of developer-facing guides, often framework-specific — how do you add enterprise single sign-on to this particular framework — and integrated with complementary open-source projects that already have an authentication piece but are missing the enterprise SSO layer, which gives us a natural, already-engaged audience.
Did you consider going deeper into authentication generally, given how much opportunity is still left even next to big players like Auth0?
We considered it, but quickly realized that by the time a customer reaches us, they almost always already have some authentication solution in place. Trying to displace something that's already embedded is a much harder sell than adding something new alongside it — getting adoption for a genuinely new capability is hard enough without also asking someone to rip out what they already trust. So instead of competing head-on with established players' core keywords, we focused content on the auxiliary pieces around authentication where our specific expertise, enterprise SSO, naturally surfaces — understanding where competitors already dominate certain search terms let us find the adjacent ground where our content could actually break through instead.
Do you produce all of that content in-house?
Yes, entirely. Outsourcing is genuinely hard here because it requires someone who deeply understands both the highly technical subject matter and how to write it in a way that also performs on SEO — that combination is rare to find externally, especially targeting developers specifically. Everything we produce is directly tied to real code walkthroughs. We haven't gotten to video yet, even though we know YouTube is effectively the second-largest search engine after Google — it's purely a time constraint so far.
Where do you actually distribute this content once it's written?
Wherever developers naturally gather. Hacker News has worked especially well for us, not just for raw distribution but because it lets us lead a real discussion around a piece of content or a specific question, and the audience is opinionated enough to give genuinely useful pushback. Dev.to has been great for long-form guides, and Reddit has performed very well too. The tricky part everywhere is avoiding getting flagged for over-promotion — the healthy approach is engaging with discussions that aren't your own content and asking well-structured questions, rather than constantly pushing your own links.
How do you use Twitter specifically, given you mentioned monitoring keyword alerts?
We track very specific technical terms — SAML, single sign-on, SAML SSO, OpenID Connect — and then look through the actual tweets to see if they're genuinely relevant, since a term like 'single sign-on' is broad and often means something more generic than the specific enterprise SSO problem we solve. It's led to some mismatched inbound before, prospects looking for a broader SSO solution than what we actually offer, connecting to providers like Okta or Azure Active Directory specifically. We're experimenting with tools that can monitor this across multiple channels at once, since right now we do it separately per platform — Reddit, Hacker News, and Twitter via TweetDeck alerts.
When you jump into one of those conversations, is it as the company or as individuals?
As individuals — my co-founder and I post as ourselves, not from the company account, which mostly just maintains a general presence rather than actively engaging. We want to be seen as people first, before BoxyHQ the brand, so it's predominantly the two of us personally starting or joining discussions we think are genuinely interesting.
Is there a repeatable growth hack behind all of this, or is it mostly grind?
We're on that same search for a magic formula too, but honestly, the reality is just consistency. We treat product and distribution as the only two things that matter, everything else is noise, and we try to show up weekly. Because we're still far from having any real brand recognition, our approach is essentially inverted — go wherever people already are, earn a little attention there, and let that lead back to BoxyHQ, rather than expecting people to come find us. It's very similar to classic cold outreach — awkward and unclear at first, but you develop a feel for what resonates and can double down on that specifically.
Are there other channels worth mentioning, like Stack Overflow?
Absolutely, and it's a great channel for this kind of dev tool specifically, since people are already there actively searching with a real question in mind. It's genuinely time-consuming, but the value isn't just distribution — it's real customer discovery. We've made real product changes based on feedback from people who hadn't even used BoxyHQ yet, just looking at what we'd built and suggesting an angle we hadn't considered. Focusing on the underlying problem, rather than your own solution, is what actually earns you those insights, and in that sense these forums are as much about understanding your potential customers as they are about distribution.