Doubling down on Privy developer success
John Dempsey
|May 16, 2025
Building at the frontier makes it easy to lose oneself in exciting tech. This is why our north star at Privy is building close to our customers. Put simply: all work at Privy is done in collaboration with a partner—we never do any work unless we know who we’re doing it for and how they’ll plan to use it. We gauge our success by looking at how the developers we serve think about Privy. This collaborative model for development helps us live our value “impact by usage,” but it requires constant upkeep.
Over the next quarter, we will be experimenting with ways to scale this model and we’d love your help, feedback, and support. Tell us where we can improve, what’s working great, and where you see gaps.
The collaborative development model
Building close to developers means 3 core things for Privy:
Customer-driven feature development — by having all new feature development be driven by a clear developer need, we think in terms of capabilities rather than technical primitives. For instance, as we roll out support for 7702, a lot of our early experimentation was based on clear use cases like enabling subscriptions or better gas sponsorship, rather than a blanket need to “support 7702.” We believe this makes for better tooling.
Forward-deployed engineering — Every new use of Privy is a new deployment that teaches us how the product can be used. Accordingly, our FDE team works alongside customers on key deployments to help them roll out Privy, understand how it is being used, and bring back core learnings through this form of productive dogfooding. Our FDEs are not just here to unblock integrations—they’re builders. They scope and shape new solutions for customers.
In the trenches with Privy devs — We work side-by-side with all Privy developers daily to help you ship better products. Whether you are a one-person hackathon team in our dev Slack or a public company with an enterprise contract, helping you debug and ship gets you where you want to go faster and helps us refine Privy’s surface.
Our most successful features come from building directly alongside our customers. From global wallets with Abstract to progressive security with Echo, lightning-fast trading experiences with Hyperliquid, smart wallet integrations with Zora, and more — we know that building great infrastructure means working close to our customers’ needs.
With that said, this working style also entails real tradeoffs as we balance our priorities helping each and every developer ship, and ensuring we tackle the long-term deliverables from our roadmap.
Developer engagement as a core product surface
Our goal with scaling Privy has always been to work with a tight-knit group of experienced developers focused on the essentials. But as demand has grown over the past years, it’s also time for us to scale our efforts massively. With over 4,000 developers in our dev Slack, over 3,000 making active API calls every month, and close to 1,000 apps live with Privy, the ways in which we have supported developers since we started are being put to the test. Some are scaling beautifully, others are not.
At times we’ve struggled to keep up with inbound requests in our dev Slack, or we’ve noticed our documentation gets stale as we support an ever-growing list of SDKs and chains. This is not acceptable—great developer experience isn't just a layer on top of the product, it is the product.
Scaling support
Ensuring our product scales is not just about database load balancing and SDK cohesion, it’s about better support so anyone can use and scale with Privy easily. Over the last month, we’ve entirely revamped our documentation to reflect Privy’s maturity and this is just the start. Throughout Q2, a core company goal is to actively experiment with Privy’s support stack and partnership model so we better retool as we continue to grow.
What does this mean, concretely?
First, we’re hiring more Forward Deployed Engineers, Support Engineers, and Developer Relations leaders to scale this motion. But we’re not just growing—we’re also evolving how we work. Some of the experiments we’re excited about running:
Iterating on documentation and adding more starter repos and recipes across SDKs,
Improving error handling (and how it’s documented) across our SDKs,
Powering better integrations with AI tooling, from better LLM support in our docs to MCP-compatibility for Privy.
We know this is an iterative process. As we work on this, we’d love your help and feedback so we can continue to improve and course correct. If we break something you love, tell us. If you think we should focus elsewhere, let us know! We’re here to help.
Thanks for building with us. We’re just getting started.
