The Split Blog

It’s easy to think of the user interface as the primary target for new functionality, with product teams eagerly watching important business metrics such as conversion rates and user engagement for improvements after each release. But behind the scenes, engineers are continually working on server-side innovations such as changes in…

Canary releases and feature flag rollouts are two common feature release strategies for testing in production, increasing the safety of continuous delivery, deploying faster and more often. Both aim to reduce the “blast radius” of unforeseen problems and build confidence in a release. Both gradually expose new code to users…

Product teams that don’t take into account a user communication and user feedback collection strategy as part of their experiments risk not getting enough data to evaluate results. This article walks through a couple key communication steps that products should follow to ensure effective and timely product experiments.

Providing an always-on and highly secure feature flagging and experimentation platform is core to making product decisions with Split. From the beginning, we have designed and built our infrastructure and practices with security and reliability as a top priority and are excited to validate this with SOC 2 Type 2 certification.

Announcing Split’s free Feature Flag Edition, a new offering which allows product and engineering teams to integrate enterprise-grade feature flags and feature flag management into their software development cycle at zero cost. Feature flags separate code deploy from feature release, safely executing continuous delivery at scale.

GoodRx has selected Split’s unified feature flag and experimentation platform to drive innovation for their desktop and mobile application. Using Split allows GoodRx to centrally track and monitor feature flags and experiments on front and backend applications, making it easy to get new features up and running quickly.

At Split we believe in the power of metrics, and are always striving to improve the ways we help our users make more data-driven product decisions. In this previous post we talked about the importance of understanding the impact of a new feature release via key and guardrail metrics. With…

When we speak to our customers, one of the most common reasons they say they made the move towards feature flags was the need to make sure their releases didn’t cause more errors for their users. By leveraging feature flags to ramp the release of their features to just small…

Find faulty features before your customers do One of the most common reasons, our customers tell us, for moving towards feature flags is risk mitigation: the need to make sure releases don’t cause errors for users. Given how frequently organizations are now deploying features, the ability to limit the blast…

Last week we walked The Path To Progressive Delivery. This week, we go deeper. What goals can we meet with the Four Shades of Progressive Delivery? After you read or watch this week’s episode, you will be better equipped to choose a Progressive Delivery approach that works for you. My…

Last week I said I would start a two-part series on progressive delivery. Here’s the promised first installment. Whether you’d rather read or watch the video, let’s jump right in! First “Radical” Idea on the Path to Progressive Delivery: Continuous Integration The story starts with the birth of Continuous Integration.…

Last week, I spoke about the foundational idea of decoupling deployment from release. This week, let’s answer the question, “Why would I want to?” At a high level, there are really just two reasons: #1: You want to prevent code that’s still a work in progress from being exposed to users…

Kicking off an internally developed feature flagging system is standard practice for many companies today as feature flags help engineering teams release faster at lower risk. As use cases for feature flags grow, so do the challenges of building an in-house system. This article will explore 10 challenges of building an in-house feature flagging solution.

This is one post in a series about managing the breakup of a monolithic architecture into a small service. In the first post of the series we looked at some fundamental techniques which allowed us to perform this sort of broad architectural shift as a series of small, safe steps. We started off…

This blog posts describes the sequence of changes a team can use to extract a chunk of functionality out from a monolith while continuing to deliver features and functionality in parallel.