Dogfooding

Also called: eating your own dog food, internal beta

Last updated:

Dogfooding means using your own product, including the parts you have not released. Staff run the new code in their daily work, which surfaces friction and broken edges that a test suite and a staging environment both miss. None of that needs a separate build or an internal-only deployment. One targeting rule turns the feature on for your own accounts, in production and against production data, while every customer keeps the current behaviour.

How to target internal users

The rule matches something only your team has. An email domain is the quickest version of this, using an endsWith condition on the email attribute, and an isStaff attribute your application already sets is the sturdier one, because it survives people signing up with personal addresses. Wrap either in a segment and every flag can reuse the same internal audience without restating the rule. The segments guide walks through building one.

Where dogfooding sits in a rollout

A bad build here costs an afternoon of your own team's time, which is what makes the first exposure the cheapest one to get wrong. Catch anything embarrassing at this stage, before a beta puts the feature in front of real users and well before a percentage rollout widens it to everyone. Your staff are also unrepresentative, and that caps what the stage can tell you. They know the product too well to hit the confusions a new user will, so expect this stage to surface bugs while usability problems survive it.

Want the full picture? Read the concept guide: Segments →

Try it in your own app

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call — sign up and ship.