What Is Dogfooding in Software? Why Companies Use Their Own Products
I pushed a critical feature to production, and within minutes, customers started complaining about a bug I had never seen. The feature worked perfectly in my tests, but real users hit an edge case I hadn’t considered. My manager asked the question that changed how I think about development: “Did you actually use this feature yourself?”
That’s when I understood dogfooding.
What Is Dogfooding?
Dogfooding means using your own products internally before releasing them to customers. The phrase “eating your own dog food” originated from Microsoft in the 1980s and has become a core practice at companies like Google, Slack, and Anthropic.
When I skip dogfooding, I develop blind spots:
- I don’t experience real user pain
- Bugs get caught too late in development
- Product decisions lack empathy
- Edge cases are discovered by customers
- Feedback loops are slow and external
How Companies Actually Do Dogfooding
I’ve seen dogfooding work at different levels of commitment.
Level 1: Mandatory Internal Use
The simplest form: all employees must use the product for relevant tasks. Teams rotate between building and using. Internal-only features get tested extensively with real workflows, real data, and real problems.
This is where I started. When my team built an internal dashboard, we required everyone to use it for their daily reporting. Within a week, we found:
- A confusing workflow that took 5 clicks to do something simple
- Missing data fields that users needed
- A slow load time that was acceptable in tests but annoying in daily use
Level 2: Dogfooding with AI Products
Anthropic takes this further. According to discussions on Reddit’s r/ClaudeAI community, Anthropic “leans heavily on automated evals” and they “dogfood Claude” - meaning they use Claude to help build and test Claude.
This creates a self-reinforcing quality improvement loop. Claude helps write code that Claude runs on. But there’s a trade-off: “The fewer human brains involved in the QA process, then the faster you can go, but also the more dumb errors get through that a human brain could’ve caught.”
Level 3: Internal-First Releases
New features get released internally weeks before public launch. This gives teams structured feedback collection, documented known issues, and confidence before external launch.
I implemented this for my team’s API changes:
features: new_api_endpoint: rollout_stages: - name: internal_alpha percentage: 100 groups: ["employees"] duration: 2 weeks success_criteria: - error_rate < 0.1% - no blockers reported - avg_response_time < 500ms
- name: internal_beta percentage: 100 groups: ["employees", "contractors"] duration: 2 weeks success_criteria: - satisfaction_score > 4.0 - critical_bugs == 0
- name: public_beta percentage: 10 groups: ["beta_users"] duration: 1 week
- name: public_rollout percentage: 100 groups: ["all_users"]This structure catches problems early. During internal alpha, our team discovered that the API returned inconsistent date formats - something our unit tests missed because they only checked for valid dates, not consistent formatting.
A Practical Dogfooding System
I built a simple feedback collection system for my team’s internal testing:
interface DogfoodFeedback { userId: string; team: string; feature: string; severity: 'blocker' | 'critical' | 'major' | 'minor' | 'suggestion'; description: string; stepsToReproduce: string[]; impact: 'prevents_work' | 'workaround_exists' | 'annoying' | 'nice_to_have'; timestamp: Date;}
class DogfoodTracker { private feedback: DogfoodFeedback[] = [];
// Quick feedback shortcut (Ctrl+Shift+F) async captureQuickFeedback( feature: string, description: string, screenshot?: Blob ): Promise<void> { const feedback: DogfoodFeedback = { userId: getCurrentUser(), team: getTeam(), feature, severity: 'minor', description, stepsToReproduce: captureRecentActions(), impact: 'annoying', timestamp: new Date() };
if (screenshot) { feedback.screenshotUrl = await uploadScreenshot(screenshot); }
await this.submit(feedback); }
// Weekly dogfooding report generateReport(): DogfoodReport { return { totalFeedback: this.feedback.length, byTeam: this.groupBy('team'), byFeature: this.groupBy('feature'), blockers: this.filterBy('severity', 'blocker'), trends: this.calculateTrends() }; }}The key feature is the quick feedback shortcut. When a team member encounters an issue, they press Ctrl+Shift+F, type a quick description, and continue working. This lowered the friction enough that people actually reported problems.
Famous Examples of Dogfooding
| Company | Product | Dogfooding Practice |
|---|---|---|
| Microsoft | Windows | Engineers ran daily builds on their machines |
| Gmail | Internal use for years before public launch | |
| Slack | Slack | Built their own tool to solve internal communication |
| Apple | iPhone | Steve Jobs used prototypes daily |
| Anthropic | Claude | Claude helps build and test Claude |
| Meta products | ”Move fast” culture with internal users first |
Slack is my favorite example. They didn’t start as a chat company - they were a gaming company. The chat tool was originally built for internal use. Because they dogfooded it extensively, they discovered how useful it was and pivoted.
Risks I’ve Encountered
Dogfooding isn’t perfect. I’ve hit these problems:
Expert bias: Engineers know workarounds that regular users don’t. When I tested my own feature, I unconsciously avoided a confusing workflow because I knew how it worked internally. The fix: include non-technical staff in testing.
Edge case blindness: Internal use is limited to our team’s workflows. Customers have different use cases. The fix: combine dogfooding with external testing and real user metrics.
Echo chamber: “It works for us” becomes a reason to ignore feedback. The fix: track real user metrics alongside internal feedback.
Delayed releases: Waiting for perfect internal testing can block releases. The fix: set deadlines and accept some bugs will be caught post-launch.
How to Start Dogfooding
I started small:
- Make it mandatory: Every team member uses the product for at least one real task per week
- Create easy feedback channels: The feedback shortcut reduced friction dramatically
- Track issues systematically: Weekly reports show trends and priorities
- Include non-engineers: Sales, support, and marketing teams have different perspectives
- Combine with external testing: Dogfooding catches some bugs, external testing catches others
The goal isn’t perfection - it’s catching the problems that matter most before customers do.
When Dogfooding Isn’t Enough
I learned that dogfooding has limits. For AI products like Claude, users provide feedback 24/7 through usage telemetry. As one Reddit commenter noted: “Claude is fantastic at testing, and so are Claude’s users who are giving Claude HQ telemetry data 24/7.”
Internal testing catches obvious problems. Real-world usage catches everything else. The best approach combines both: systematic dogfooding for initial quality, followed by gradual public rollout with monitoring.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments