Flagsmith

In fintech, a bad release costs everyone money. When a payment flow breaks, real people can’t move their money, which is why you need to be prepared. Monzo went down for two hours in January. Customers could still pay, withdraw, and transfer because Monzo had engineered for failure with an independent backup system. Assume releases will go wrong, and then build to protect your customers when they do. Feature flags are the release-level version of that. They decouple deployment from release, so you can: → Ship code to production when it's ready → Release it to users when testing is done, and approvals are in place → If something goes wrong, kill the flag in seconds, with no rollback and no redeploy Komerční Banka, a Société Générale bank with 1.6 million customers, runs every feature in production with Flagsmith for 24 hours before enabling it for everyone. Moving to this model eliminated merge conflicts and multi-week release branches that had been slowing them down. Plus, the compliance layer comes free: four-eyes approvals, full audit trails on every flag change, and role-based access. When the SOC 2 review or DORA assessment lands,  prospects and regulators have the evidence they need. If you still treat deployment and release as the same event, you're carrying risk your regulators – and your customers – won't sign off on. Read our ungated playbook to learn more: https://lnkd.in/eVfcUpRX

Setting up an A/B experiment used to involve stitching together a stats tool and a data pipeline. Here's Asaph, our Head of Product, doing the whole thing inside Flagsmith… in one seven-minute take. In the demo, he: → Connects a warehouse in two clicks → Creates a live experiment built on an existing A/B flag → Defines a rollout configuration and the metric to measure → Tracks entries and conversions with two new SDK methods → Gets back win probabilities and credible intervals, improving as data comes in If you're already using flags to ship, you're one step away from using them to test and learn. Experimentation is in closed beta now. Watch the demo, then get in touch if you want to try it yourself. What's the first thing you'll test? https://lnkd.in/eQdAD7Dr

You have a productive quarter ahead. Twelve experiments planned, a roadmap that promises product experimentation as a cultural pillar, full buy-in from the VP, and some exciting hypotheses to test. Now think about the codebase underneath it: you have new flags to monitor and deprecate, a rollout that needs to be gradual, a targeting rule copied from an old test that might be out of date, and a rollback process that can’t rely on Slack messages. If you aren't prepared for all that, your team doesn't have an experimentation problem; you have an infrastructure problem. This article covers what product experimentation actually is and the types of experiments worth running, then gets into the framework that keeps things from breaking. https://lnkd.in/euM5DRMp

Changing the right feature flag in the wrong environment is an easy mistake. Our new Flagsmith CLI is designed to make it much harder. You can now manage feature flags from your terminal instead of the Flagsmith website. Run flagsmith init once, and it writes a small config file to your repo. From then on, anyone who downloads the repo is automatically pointed at the right Flagsmith project. The same commands produce readable tables for developers and structured data for scripts or AI coding agents. Plus, you can use it directly inside CI/CD. For example, add this line of code to your pipeline. flagsmith evaluate --test It will stop any build if a required flag is switched off, blocking the deploy before it ships. We’ve also added keyless CI authentication. Normally, to automate feature flag changes, you have to create a key and store it in your CI secrets indefinitely. With the new CLI, your pipeline can prove its identity using OIDC and receive a token that expires after an hour, meaning nothing long-lived to store. Flagsmith's CLI is free, open source, and MIT licensed. Try it here: https://lnkd.in/ez6VBxFs

If your product team is putting out more PRDs than prototypes, you’re doing AI-assisted software engineering wrong. Vibe coding is far from perfect. But it’s great for building prototypes, validating ideas and experimenting with new feature releases. Quickly and efficiently. Tools like Claude and Codex flip the product development cycle: - Skip the PRD - Ship a prototype with Claude - Use feature flags to put it in front of the right users - Monitor how users respond - Learn Then write the PRD, get engineering to turn the prototype into a real product, phase out the prototype. We call that disposable software: software built solely with the purpose of validating, learning and iterating fast based on real usage. We’ve put together a playbook on how you can ship faster with disposable software, read it here: https://lnkd.in/eCKDb6cG

🚀 Excited to welcome another keynote speaker to Dutch Cloud Native Day 2026. Joining us in Utrecht is Simon Schrottner, Fractional Developer Advocate at Flagsmith. 🎤 Two Standards Walk Into an Agent: Runtime Agent Control with OpenTelemetry and OpenFeature As AI agents become increasingly autonomous, questions around observability, control, governance, and runtime decision-making are becoming more important than ever. In this keynote, Simon explores how #OpenTelemetry and #OpenFeature can be combined to create an open, vendor-neutral control layer for AI agents, enabling visibility, control, permissions, and rollback without relying on proprietary platforms. A thought-provoking session for anyone working at the intersection of AI, #CloudNative, #observability, platform engineering, and open standards. 📍 Jaarbeurs Utrecht, The Netherlands  📅 29–30 October 2026 #DutchCloudNativeDay #PlatformEngineering #OpenSource #Kubernetes

Testing in production is wrong. You should never do it… Unless you’re doing it right. In which case it is the gold standard in progressive delivery. Especially now that AI is speeding up the software development life cycle. So how do you test in prod without blowing up your entire environment? By using feature flags. Testing in prod doesn’t completely negate the need for staging / QA environments and infrastructure. They’re still useful for load testing and stateful applications that rely on database migrations. But using feature flags to test in prod significantly reduces the need for staging. You also don’t need to wonder whether your staging / QA environment correctly mirrors prod. Plus you get to: - Keep a steady stream of deploys - Up shipping velocity - Test and improve continuously If you’re looking to ship, iterate and learn faster with feature flags, we’ve put together a playbook on AI-assisted software engineering with Pete Hodgson Check it out here: https://lnkd.in/dgiNNhkQ

A feeling isn’t a decision. Data is. 📊 We recently debated whether to require a business email at signup. Instead of guessing, we ran an A/B test. The twist? We ran it using our own Experimentation tool. "Dogfooding" our own tool in production meant we caught friction points early and refined the SDK before it reached our users. Want to see how we combined feature flags with product experimentation to make data-driven decisions safely? Read our latest blog post here: https://lnkd.in/dqt82w_N Interested in trying the beta? Get in touch! #SaaS #FeatureTesting #SoftwareDevelopment #Flagsmith #Experimentation

TIL about Jevons paradox: the concept that tech innovations in efficiency don’t decrease the overall use of a resource. They increase it. That’s what AI is doing to software engineering. Speaking from experience, it’s definitely the case for us at Flagsmith. You constantly hear about layoffs and companies replacing engineers with AI. I mean, just look at Anthropic’s marketing playbook. It’s all they talk about. And yet, they keep hiring more engineers. Our engineering team has remained the same size as pre-agentic coding. But we’ve significantly boosted our output and productivity since Claude Code launched: - Shipping velocity went up 70% - Nearly 2x’ed overall deploys - Backend deploys are up 270% I know it’s rough out there for a lot of engineers, especially juniors, but I’m optimistic about the future of software. I’m convinced there’ll be more software in the future, not less. I think the same applies to engineering jobs. Especially for engineers who commit to AI-assisted development. Some roles will disappear, some roles will change. But software engineering isn’t going away.

Coding agents can accelerate the entire PDLC, not just coding, but only if you use them effectively. In the ebook I lay out specific practices and architecture that lets delivery teams use AI to turbocharge product experimentation, then fast-follow with robust production-grade software.