DevCycle's Origin Story

Our Story

Now that it’s been one year since we formally launched DevCycle and broke ground in the feature flagging space, we thought it’d be a good time to (re)introduce ourselves. 

Read on to find out when and why we moved into the feature flagging space, how our roots in A/B testing and experimentation guided our success, and where we’re headed as we look to standardize and revolutionize the use of feature flags in every developer’s workflow.  

With a relentless focus on the developer experience, our vision is to enable teams to build great software, and our mission is to build thoughtful tools that developers are excited to use. Here’s our story. 

Our Roots

Though we did not formally launch DevCycle until 2022, our team has roots in feature flagging that stem all the way back to 2017.  

As some may know, our founders launched Taplytics (a YC company) in 2011. Taplytics is an A/B testing and experimentation platform originally targeted towards product and marketing teams. Though an entirely separate platform from DevCycle, Taplytics is a crucial part of our reasoning for building, and becoming, DevCycle.

Our goal in building Taplytics was to enable product and marketing teams to take more control of their digital platforms through no-code editing and A/B testing. In doing so, we reduced their reliance on their development and engineering teams for things like website updates, UX personalization, and experimentation. Eventually, we built out a full-stack, code-based feature flagging solution within Taplytics so that engineering teams could it for their releases, too.

With the addition of feature flags, Taplytics went from a platform targeted solely towards product and marketing teams, to a platform that more and more engineers were using to release features and develop their mobile apps and websites. Feature flags were a hit.

But Taplytics still had its flaws, particularly within our own development cycle. In January of 2021, we hired a VP of Engineering who came from an organization that was releasing code with feature flags multiple times per day. When he found out our most recent release of Taplytics was 3.5 months prior to him joining, he knew we had to start using feature flags on our own team. 

So, we set out to make our feature flagging capabilities within Taplytics even better, and started using them in our own development process. Very quickly, we saw the positive impact feature flags had on our own team, and on so many of our users' teams as well.

The Shift

Later that year, during a Senior Leadership Team offsite in Northern Ontario’s cottage country, we asked one important question that changed that trajectory of our business:

“What is the data telling us?” 

In asking that question, we came to two conclusions:

1. 100% of our clients were using feature flags in Taplytics.
2. More and more clients were adding their engineering teams to Taplytics to use these feature flags.

The data was undeniable. 

It showed us that product and marketing teams were not the sole proprietors in pushing continuous changes to software. Engineering teams were, and they were doing it with feature flags.

Thus, feature flags were the driving force in releasing good, reliable software; A/B testing was merely a step in the process of releasing good software. This realization forced an entire shift in our business model: Feature flags had to be the primary platform, and A/B testing had to be a feature within that platform, not the other way around.

Knowing this information, we asked ourselves: How can we take this data and use it to build something we’ll get value out of for the rest of our careers?

We knew our feature management capabilities in Taplytics were good, but were they something we could continue scaling, building, and using for the rest of our lives? Probably not. We couldn’t just white label, or create a more robust feature flagging solution within Taplytics. 

To build something as impactful as we hoped, we had to start from scratch. We had to build a brand new feature flagging solution.

The Conception of DevCycle 

Building a new brand is no small feat, but we had done it once, and we could do it again. Even better this time. 

Above all, building a new brand requires intense curiosity – an ability to ask the really hard questions about the industry you’re breaking into. And that’s exactly where we started:

What does the current state of feature management look like? Where is the software development industry headed? What do development teams need? What are other feature management tools doing? What are existing feature flagging tools lacking? How can we push the limits of feature flagging and dev tools to bring something totally new and different to the space? How can we build something that we will get value out of for the rest of our careers?

These questions became the foundation of DevCycle.

Figuring out what was going on with existing feature flagging platforms and what they lacked was the first step. Here’s what we knew about existing tools:

Most existing platforms were built to appeal to executives. 

As developers, we knew we’d need to build a feature flagging platform tailored towards the ones who would actually be using the platform every single day. Existing platforms were more concerned with appealing to decision makers than actual developers, when in reality, both groups matter. We needed to build DevCycle in a way that brought exponential value to every single member of an engineering organization: from the CTOs and VPs to the individual developers. 

From that point onwards, we set out to build the only developer-centric feature flagging platform: A platform that would make developer’s lives easier, and one that they were excited to use. 

Most of them added complexity to their users’ codebases.

The pros of feature flags most certainly outweigh their cons, but technical debt is a real concern for teams considering using feature flags. We knew that existing platforms made it decently easy to create feature flags, but very difficult to know when it was time to remove those flags. Thus, their users were left with an abundance of used flags in their codebase, which became hard to manage and bogged things down. 

We wanted to counteract the idea that feature flags add technical debt by building a platform that made it easy to see the status of all your feature flags, across all of your environments, at all times. DevCycle helps you track flag usage and provides tools to automatically clean up used feature flags so that you can reap all the benefits of feature flagging, without the tech debt. 

Other feature flagging tools became increasingly complex, expensive, and less accessible as flag usage and development teams expanded.

We heard from other feature flaggers that the more they used their platform, the more difficult to navigate it became, and the less people they could trust on their dev team to actually use it. In other words, they were paying for a platform that only 25% of their devs were using. 

From this, we knew we had to build an intuitive feature management platform that could easily scale with a development team as it grew, and that anyone on the team would be able to use. We set out to shift the accessibility of feature flagging and make it something as standard as unit testing in a developer’s workflow. We truly believe that if your feature flagging platform is not intuitive and accessible enough to make every developer’s work easier, it’s not doing its job.

Our list of revelations goes on, and on… and on. 

The central theme was that existing feature flagging tools were causing consistent bottlenecks for teams of all sizes. So, we set out to build a feature flagging platform that addressed these bottlenecks, and brought something entirely new to the space. 

What Makes DevCycle Different

DevCycle became the only developer-centric feature flagging platform that empowers developer teams to build great software. The core purpose of feature flags is to help development teams separate code deployments from releasing features to their users. This is proven to dramatically increase the rate at which the teams can ship great software to their end users. 

But beyond creating really good feature flags, we modeled our entire platform with the flexibility to match how development teams build software. Here’s a few of our core features that make DevCycle, DevCycle. 

We think in features, not flags. 

Our Feature Grouping capability enables teams to group multiple flags together within a single feature to allow for simpler workflows. Existing feature flagging platforms are built around single flags, so managing multiple flags (hundreds to thousands) in multiple workflows is a major pain point for users.

In DevCycle, each feature can have multiple flags and variables within them, and teams can own and control the flags for the features they are currently working on.

Feature flags, without the tech debt.

DevCycle doesn’t just help you create feature flags, we help you manage the entire lifecycle of the flag – including knowing when to remove them. 

Existing feature flagging tools make it difficult to know when your flags should be removed, leading to fragile systems and a bogged down dev pipeline. DevCycle shows you where your flags are used within your codebase, and helps you track flag usage so that you can automatically clean them up when they’re no longer in use. 

We’ve moved decision logic as close to the end device as possible.

With local-bucketing Server SDKs and Edge powered APIs for Client Side SDKs, we’ve made DevCycle more accessible to all team members. 

Usage based pricing.

Speaking of all team members, our usage based pricing model ensures all of your team members have access and visibility into your feature flags, at all times. Whereas existing tools become more complex and expensive as you grow, DevCycle was built from the ground up to scale and maintain cost effectiveness for orgs of all sizes.

Our goal in building DevCycle was to create a feature management platform that acts as a core development tool helping all teams ship more reliable code faster to their end users.

Take a look at some more of our core features below, or visit our docs.

• Feature Opt-In 
• Real-time updates
• EdgeDB
• Integrations with GitHub, Bitbucket, Jira, and more
• SDKs for every major platform

Where We're Headed

Ultimately, DevCycle is the product of our drive to disrupt current norms in the software development industry, and revolutionize feature flags to make every developer’s job easier. We didn’t want to build another tool that would fit in with the pack – we wanted to break away from the pack and build something that dev teams were actually excited to use. 

With roots in A/B testing and our legacy brand, Taplytics, we may have taken the long road to get here. But taking the long road actually ended up being critical to the success of DevCycle and our ability to truly bring something new to the space. 

Now, we’re ready to share the most intuitive, developer-centric feature management platform with you all. We’re dedicated to building thoughtful tools that you actually want to use, so that you can do what you do best: build great software. 

And this is just the beginning. Thanks for being here. See you in the platform.