--- title: "Dogfooding Developer Tools: Our Internal Feedback Loop" description: "Using your own tools daily catches problems before external developers hit them. Our internal dogfooding requirements, feedback channels, and the empathy advantage." canonical: https://nowah.xyz/blog/dogfooding-developer-tools-feedback lastModified: "2026-08-07T08:11:14.090Z" --- # Dogfooding Developer Tools: Our Internal Feedback Loop Using your own tools daily catches problems before external developers hit them. Our internal dogfooding requirements, feedback channels, and the empathy advantage. During an internal hackathon, one of our engineers tried to use our SDK to build a quick flight search demo. The search call took six lines of code. Six lines to do the most basic operation our API offers. She walked over to the SDK team's desk and said "this should be one line." She was right. The six-line version required manually constructing a request object, calling the search method, unwrapping the response envelope, and extracting the offers array. A convenience method that accepted origin, destination, date, and passenger count as direct arguments would have done it in one line. We shipped the one-liner two days later. Our external developers never had to experience the six-line version because an internal developer caught it first. That is dogfooding. Use your own tools. Find the problems. Fix them before anyone else has to live with them. ## The mandate ![Illustration for this section](https://pics.nowah.xyz/website-media/developer-experience-058-img-1-internal-survey.webp) Every engineer on our team uses the SDK, CLI, and dashboard at least weekly. This is not a suggestion. It is a requirement. Backend engineers use the SDK to write integration tests. Frontend engineers use the dashboard to monitor their development API keys. DevOps engineers use the CLI for deployment workflows. Product managers use the sandbox to test new features from a developer's perspective. The weekly cadence matters. If engineers only use the tools during occasional hackathons, they miss the friction that accumulates in daily use. The CLI command that takes an extra flag that should have a sensible default. The dashboard page that loads slowly. The SDK method that requires an unnecessary parameter. Daily friction is invisible in design reviews and code walkthroughs. It only becomes visible when you actually use the thing. ## Feedback channels We have three feedback channels, each serving a different purpose. A dedicated internal channel for immediate observations. When an engineer hits friction, they post it. "CLI search output is hard to read in narrow terminal windows." "SDK error type does not include the request ID." "Dashboard latency chart Y-axis is confusing." Quick, low-friction reports that capture the observation while it is fresh. Average triage time for internal reports: under 24 hours. Someone on the DX team acknowledges the report, categorizes it, and either files a fix or explains why the current behavior is intentional. A weekly DX triage meeting reviews accumulated internal feedback, prioritizes fixes, and assigns owners. This meeting includes engineers from every team, not just the DX team, because the feedback comes from everywhere and the fixes sometimes span multiple teams. A quarterly internal DX survey asks every engineer to rate their experience with each tool on a scale of 1-5 and provide open-ended feedback. This catches patterns that individual observations might miss. If four engineers independently rate the CLI's search output as 2/5, that is a stronger signal than any single report. ## Bug prioritization ![Supporting diagram](https://pics.nowah.xyz/website-media/developer-experience-058-img-2-before-after.webp) Internal issues get fast-tracked because they predict external pain. If our engineer finds a problem, external developers will find the same problem. The difference is that external developers might not report it -- they will just form a negative opinion and move on. About 80% of CLI UX improvements originate from internal usage observations. The CLI is particularly good for dogfooding because every engineer interacts with it slightly differently, exercising edge cases that formal testing misses. In the last quarter alone, dogfooding caught three issues that we categorize as serious UX bugs before any external developer reported them. One was a race condition in the SDK's retry logic that caused confusing [error messages](/blog/error-messages-ai-agent-lifeline). Another was a dashboard permission issue that showed the wrong data to Viewer role users. The third was a CLI authentication flow that failed silently on certain network configurations. Each of these would have generated support tickets and frustrated developers. Catching them internally saved both us and our developers significant pain. ## The empathy advantage There is a secondary benefit to dogfooding that is harder to measure but possibly more valuable: empathy. An engineer who has experienced the frustration of a confusing [error message](/blog/anatomy-of-perfect-error-message) in their own tool develops a visceral understanding of why error messages matter. They do not need to be convinced by data or arguments. They felt it. This empathy carries over into every decision they make. When reviewing a pull request that adds a new error response, they instinctively ask "will this be helpful when I encounter it?" When designing a new CLI command, they think about how it will feel in their own terminal, not just whether it is technically correct. Empathy is not a substitute for metrics and [user research](/blog/user-research-ai-products-what-learned). But it is a complement that makes engineers better at their jobs. An engineer who dogfoods their own tools makes better [design decisions](/blog/year-in-review-design-decisions-shipped) in the moment, reducing the need for expensive course corrections later. ## Getting started If your team does not currently dogfood your developer tools, start with three steps. **Step one: mandate.** Make it a requirement that every engineer uses at least one developer-facing tool weekly. Pick the one that is most broadly applicable (usually the SDK or CLI) and make it part of standard workflows. **Step two: channel.** Create a dedicated feedback channel. Make it low-friction to post. Acknowledge every report within 24 hours, even if the acknowledgment is just "noted, will triage Thursday." **Step three: cadence.** Set a weekly meeting to review feedback and prioritize fixes. Without a regular cadence, feedback accumulates and nothing changes, which discourages future feedback. These three steps cost almost nothing to implement. The return -- catching bugs early, building empathy, and improving tools continuously -- compounds over time. A team that dogfoods their developer tools builds better developer tools. There is no shortcut around this. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).