Dogfooding Like a Pro: How to Safely Test in Production
Staging is a polite fiction. Learn how to use feature flags and internal cohorts to catch bugs in the real world before your customers do.
Published on May 1, 2026
The feature looks perfect on your machine. QA gave it the thumbs up in staging. The PM is happy. But ten minutes after the production deploy, the Slack alerts start firing.
Why? Because staging is a polite fiction. It’s the clean-room version of a world that is actually messy, cached (it’s always the cache), and full of weird edge cases, like DNS.
Staging has its place, but your pristine mock data never survives first contact with real-world production chaos. If you want to stop that sinking feeling of a production bug surfacing right as you’re about to head to the pub on a Friday afternoon, you need to test in the wild.
The most effective way to lower your Change Failure Rate without sacrificing Deployment Frequency is “dogfooding” your software in production using internal user cohorts. Google does this at scale, and infact, so does all big tech. They test their features out in the wild with internal users first before everyone else sees it.
What is Production Dogfooding?
Dogfooding is just a fancy way of saying “use your own product.” But doing it safely in production requires separating the technical act of deploying code from the business decision of releasing a feature.
By wrapping your new feature in a feature flag, you can push the code to your live servers while keeping it invisible to the public. You then use a user cohort to flip the switch only for your internal team.
The Dogfooding Framework
For Product Managers and QA teams, the ability to segment users isn’t a luxury, it’s a tactic. Here is a framework for testing safely in the real world:
Deploy, but hide it First, your engineering team wraps the new feature in a feature flag and deploys it. The flag is set to “off” globally. The code is live in production, but the blast radius is zero because no one can see it.
Target the “Home Team” Forget the tedious process of whitelisting individual user IDs or begging engineers to run database scripts. Create an “Internal Testers” cohort based on your company’s email domain (e.g., @yourcompany.com). Enable the feature flag specifically for this group.
The Production Reality Check Now, your entire team: devs, marketers, and support can log into the live app and use the feature exactly as a customer would. Since they are interacting with real production infrastructure and actual data, those sneaky, last minute bugs finally show their faces.
The Confident Handoff Once the internal team has squashed the bugs, you don’t need another deployment. You just update the flag rules. You can transition to a canary release to see how the system handles the load under 5% of traffic. Need a primer on canaries? Read this post.
The Dogfooding Checklist
To make this process truly “Elite” tier, don’t just “turn it on and look around.” Give your internal team a specific mission. Here is the checklist we use at RocketFlag before we even think about a canary rollout:
- [ ] The "Identity" Check: Ensure the user identity in production correctly maps to the internal cohort.
- [ ] The "Performance" Sniff Test: Does the page feel slower? Check the network tab for any unexpected ballooning in payload sizes.
- [ ] The "Dirty Data" Test: Try to use the feature with an old account that has complex legacy data, not just a fresh test account.
- [ ] The "Kill Switch" Drill: Turn the flag off while someone is mid-action. Does the app degrade gracefully back to the legacy state, or does it crash?
Breaking the Collaboration Tax
Historically, managing these internal testing phases meant PMs and QA had to clutter the engineering backlog, begging for configuration changes or manual deploys. This is what I call the “Collaboration Tax.”
When it costs a fortune to add a user to your flagging platform, companies restrict access. PMs and QA leads end up locked out, forcing teams to share a single admin login or wait in a queue for a dev to flip a switch. This creates a massive security risk and a bottleneck that artificially inflates your Lead Time.
We built RocketFlag to kill that bottleneck. RocketFlag offers an unlimited seat model on paid plans, so you never have to choose who gets to participate in the release process.
Take Your Release Process Out of the Clean Room
Stop relying on the “polite fiction” of staging. Bring your entire team into the release process, start dogfooding like a pro, and ship with absolute confidence.
If you’re still nervous about shipping, I recently wrote about how to end No-Deploy Fridays using exactly this framework. Give it a read, then give your team the keys to production.
– JK @ RocketFlag
