Pivoting a million dollar startup - DevCycle (Jonathan Norris, Brad Van Vugt & Andrew MacLean)
Taplytics was a real, funded business for a decade — A/B testing, no-code editing, push notifications, a broad marketing automation suite. DevCycle's founders killed most of it anyway, betting the whole company on a feature-flagging side project their own engineers couldn't stop using.
Jonathan Norris, Andrew MacLean, and Brad Van Vugt are on the team behind DevCycle, a feature flag management tool that grew out of Taplytics, the mobile A/B testing and marketing automation platform Jonathan co-founded in 2014.
We get into why a decade-old, genuinely successful business got narrowed down to one product, what it actually took to migrate enterprise customers off deprecated features, why selling to engineers instead of enterprise buyers changes the entire sales motion, and why DevCycle open-sourced everything it possibly could.
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.
Taplytics had been running for over a decade. How did DevCycle actually emerge out of it?
Taplytics started as a mobile A/B testing and no-code visual editing platform and grew into a much broader marketing automation and dev tool suite — web no-code editing, push notifications, audience building, a large set of enterprise marketing tools. About two and a half years before this conversation, we looked at the business as a whole and felt stretched thin across too many different products. So we looked at the granular detail: who's actually using our product every single day for their core workflow? That turned out to be engineering teams using our feature-flagging tools, which we'd originally built as a side project on top of the A/B testing platform, to do continuous deployment. We were even using it that way internally ourselves. This was around 2017-2018, before feature-flags-as-a-service was really an established market category — very early days for that segment.
What are the actual trade-offs between focusing on one thing versus a broad product like Taplytics?
We learned some hard lessons going broad early — as an engineering manager and founder, the constant context-switching, addressing an issue for one customer in one part of the product then having to jump to a completely differently architected part of the product, is genuinely painful and taxing on an engineering team. Focus, especially early on but even as you grow, turns out to be incredibly important for building a cohesive product. When we committed to DevCycle, we tried to go as all-in as possible — we kept people in place to properly support existing Taplytics customers, but we wanted the DevCycle team to have complete, undistracted focus and the runway to build with that single-minded intent.
What was the hardest part of actually executing that pivot?
Moving customers over while maintaining those relationships. The nice part is most Taplytics usage was already code-based A/B testing or feature flagging, which DevCycle supports much better, so it was an easy story for a large percentage of customers. But some use cases, like push notifications, we actively told customers we were deprecating — a much harder conversation, where we partnered with OneSignal to help smooth that transition onto a platform that would support them long term. That balance — genuinely supporting existing customers through the transition — was, and still is, the most delicate part of the whole process. We have customers who've been with us for over 8 years, which is wild in a fast-moving tech world, and a lot of them made the jump with us because we'd invested so much in those relationships.
Practically, how did you manage those customer relationships through the transition?
A lot of Zoom calls, but really it came from having built genuine, in-person relationships and personal connections over time. Because Taplytics focused on enterprise customers, there were a smaller number of large contracts to manage directly, and as founders we made a point of maintaining executive-level relationships at our biggest accounts — connections you can lean on during tough contract negotiations. My advice to founders is: stay close with your biggest customers and their executives, and never lose that connection if you're selling larger enterprise deals.
How did pricing change moving from an enterprise product to a product-led growth model?
We're honestly still figuring it out. The core shift going from enterprise to PLG is landing at a much lower price point, moving toward usage-based pricing rather than seat-based, which aligns cost more closely with actual usage. There are still enterprise levers — permissions, SAML, custom SLAs — that larger contracts get built around, using the same general enterprise mechanics as before. But most of our pricing focus now is on getting mid-market companies to sign up and start using the product at a reasonable, self-serve rate.
Does selling to a more technical buyer change how pricing conversations actually happen?
Significantly. Coming down-market from enterprise, your decision-maker becomes far more technical — engineering directors, engineering leads — and pricing comes up in the conversation much sooner. Technical buyers do a kind of instant gut check on your pricing page: not a detailed cost calculation, but a quick read of whether this is priced for their stage and their team. What language is used, do things scale on usage or seats — those signals matter more than the actual dollar figure. Positioning pricing specifically for developers turned out to be its own skill we're still learning.
Does the sales process itself change when you're selling to engineers instead of executives?
One of the biggest shifts is that you really can't force timelines on technical, infrastructure-facing buyers the way traditional enterprise sales does — offering a discount to sign this week, or a bonus for closing in two weeks, doesn't really work when your product is essentially an API. And that's fine — the better approach is understanding where someone actually is in their own technical roadmap and figuring out how to help, rather than pushing sales for the sake of sales. That's a real shift in the sales team's mental model, one we've had to navigate very intentionally.
How does developer relations fit into that shift?
DevCycle has doubled down hard on relationships as the core mechanism for transitioning people over — the whole conversation internally and externally has been to focus on relationships first, and everything else follows from that. DevRel as an industry basically didn't exist ten years ago because dev tools weren't in a place where that made sense yet; now there's a whole discipline built around building relationships with developers specifically, and that's been a genuinely unique part of this transition for us. For the sales team specifically, most of their time now goes to product-led sales — watching how people are actually using the product, and reaching out at the moment they've deployed to production and are clearly getting real value, rather than blasting every signup with emails immediately.
What does building that kind of relationship-driven community actually look like day to day?
We try to be very open, public, and available — a Discord anyone can drop into and talk directly to a founder or C-level exec most times of day, a lot of engagement on Twitch and YouTube, trying to be as live, human, and accessible as possible on the other side of the platform. The whole team, not just founders, shows up across marketing, sales, and account management — the fact that all three of us are on this podcast together reflects that philosophy. We don't want this to be the Jonathan show or the Brad show; we want it to be the DevCycle developer show, so people see the actual faces behind the technology, because when something breaks, you want to reach a real person in whatever way feels comfortable to you.
How does developer experience actually differentiate DevCycle from established players and internal tools, given that everyone claims to care about DX?
We rarely use the term 'developer experience' internally — it's more of an external industry phrase. What we actually talk about is the quality of the product: the quality of our SDKs, the quality of our API. If you get that right, developers give you an incredible amount of loyalty, but there are a thousand ways to lose their trust quickly. It's not enough to claim your CLI is 'delightful' — what actually matters is that it works as expected, works the first time, works wherever you're working, and works bug-free. We measure ourselves against the question: is the quality of our developer experience high enough to genuinely stand out in this broader market, where there's a dominant incumbent and countless open-source and internal alternatives already.
As a CTO, what changed most about how you think about building features?
Getting out of the mindset of building the flashiest, most marketable features was one of the biggest shifts for me personally. It's not about flashiness or capturing attention — it's about building a great core product that delights more than it frustrates, removing the friction and hiccups every product has, including ours, and iterating on those core things continually rather than chasing the next feature you think will get attention, because most of the time it won't. We spent months building a custom testing system just to ensure consistency and quality across all our server-side SDKs — completely unsexy work that will never headline a marketing page, but it's exactly the kind of thing that pays off over time by keeping every SDK reliably consistent as we make changes.
Why did DevCycle decide to open-source almost everything, when Taplytics couldn't?
Taplytics had patentable technology baked into its early SDKs, which meant we could never fully open-source much of what customers installed into their applications. With DevCycle we wanted to fully reverse that — every piece of software someone installs, whether an SDK, a server integration, or a GitHub connection, we wanted open source. That's led us to support Open Feature, a CNCF sandbox project in the mold of OpenTelemetry — a vendor-agnostic interface for using feature flags in code, so instead of coding directly against DevCycle's SDK, you use Open Feature's interface and plug DevCycle, or any other provider, in underneath it.
Does that open-source angle actually change conversations with developers on the ground?
Enormously. At KubeCon in Chicago, which felt like our coming-out party in the cloud-native world, people would ask why we care about open source, and just being able to say 'because we believe in this community' made the follow-up conversation about our paid SaaS platform a much easier segue. There are several genuinely good, fully open-source, self-hosted feature-flag alternatives out there, so the honest answer to 'why not fully open source' is that our SaaS model lets us dedicate real resources to delivering the best possible developer experience, while still supporting people through open source wherever we can. It's been a huge door-opener for being taken seriously as a genuinely developer-focused company, and it directly helps migration conversations too — a codebase with hundreds or thousands of existing feature flags never wants to migrate providers more than once, so pointing people to Open Feature means they migrate their interface once and can swap the underlying provider freely after that, including migrating off things as simple as raw environment variables or a config file on a CDN, which is honestly where most people actually start.
You've both worked on Battlesnake before joining DevCycle. What did that teach you about building a developer brand?
Battlesnake was about building developer community and trust, and creating what we thought of as safe spaces for senior developers — it's genuinely hard to be a senior developer in public spaces like LinkedIn, which is loud and noisy. The biggest lesson we brought to DevCycle is that developers are people first, developers second — creating experiences they can share their enthusiasm for with the people around them matters enormously. At Battlesnake, people would host watch parties with their families for tournaments. That carried straight into DevCycle: at KubeCon we handed out baby onesies printed with 'future engineer' and our toggle-bot logo, and they were the most popular item at our booth, because senior engineers have families and lives outside the terminal, and giving them something to share that excitement with is a real, underrated part of building a developer brand.
What's the one thing you'd tell another dev tool founder based on everything you've learned building DevCycle?
Focusing on developer experience really means focusing on the core product itself and the relationship you build through the quality of that day-to-day experience — the small frustrations, the documentation, the interfaces — far more than it means shipping the flashiest UI. Those day-to-day details need continual iteration and refinement to build an actually great developer tool, and that work never really finishes. We want people relying on our tools every single day in their workflow, and that's what we stay laser-focused on.