Kantan.tech moves faster than their competition

At Kantan, we're changing the lives of tradespeople by giving them the tools to excel in a competitive marketplace. Our product is a React Native app that helps them serve customers, manage operations and grow their business. We have thousands of tradespeople managing hundreds of thousands of jobs on our platform. And we are just getting started.

To enable us to grow and scale on the journey to become the number one application for tradespeople in the UK, we need to move quickly, pushing our product and features to market faster than our competitors whilst maintaining quality and ensuring we have complete control over our production environment.

Managing deployment risk

To achieve this, we have set up a pretty slick continuous integration process utilizing CircleCI to automatically build and deploy all commits to master. Still, as a technology business, you also have to manage risk. Large Pull Requests are hard to follow, and big releases come with increased risk. Both can lead to undesirable consequences in the production environment that can be hard to root cause and resolve.

To manage this process, we like to release little and often, raising and merging PRs to master once we have reached a logical point within the development of a story. This point is often before a story has even been completed and simply allows us to maintain a good cadence of releases to our production environment and managing risk in the process.

Feature Flags in the development process

But how can we release unfinished code to our prod environment? The simple answer is to utilize a feature flagging strategy, and to manage this, we use ConfigCat. ConfigCat has been instrumental in enabling us to effectively manage our features through the software delivery life cycle.

Engineers automatically add feature flags to any new feature, with a default visibility set to off. We then deploy to our staging environment, where we can turn on the feature and smoke test, before deploying to production.

On deploying to production, we turn flags on for internal users and run one last smoke test. Once we’re happy, we enable the flags for all users.

Retiring feature flags or keeping them as emergency kill switches

Once enabled in Prod, we play another task to set the default visibility of the feature to true. Due to the nature of a Native Application, this ensures that when we come to remove the feature flag, we do not remove the feature for older versions of the application. At this stage, we can still turn off the feature if required using ConfigCat until we remove the flag from the codebase after approximately one week.

Wrapping up

The power of ConfigCat really comes from its ability to utilize custom user attributes which allow us to identify predefined user segments to enable feature flags, such as for internal users, to facilitate smoke testing, or for a particular cohort of our end users to trial a release of a new feature in a limited capacity.

ConfigCat's use of Cloud-native Infrastructure and Global CDN infrastructure produce lightning fast response times and ensure high availability of the service. Over the last three years of partnering with ConfigCat their product has truly been the epitome of reliability, ensuring that it is maintained as the bedrock of our feature flagging strategy.