--- title: "Dogfooding Our CLI: How We Use It Internally" description: "Our engineering team uses the Nowah CLI daily — for testing, debugging, and incident response. Internal feedback drives most CLI improvements. Here is our dogfooding practice." canonical: https://nowah.xyz/blog/dogfooding-cli-use-internally lastModified: "2026-08-07T08:11:11.285Z" --- # Dogfooding Our CLI: How We Use It Internally Our engineering team uses the Nowah CLI daily — for testing, debugging, and incident response. Internal feedback drives most CLI improvements. Here is our dogfooding practice. Our backend engineer was on call at 2 AM when a customer reported a booking stuck in a pending state\. They opened the terminal, ran \`nowah logs tail \-\-request\-id req\_abc123\`, saw the provider timeout, ran \`nowah bookings get bkg\_xyz789\`, confirmed the stuck state, and escalated with full context\. Diagnosis took three minutes\. The next morning, they filed a CLI feedback note: "The logs tail output should show the provider response time separately from our processing time so I can tell if the delay is us or upstream." We shipped that change in the next release. That [feedback loop](/blog/ai-feedback-loop) — using the tool internally, noticing friction, fixing it fast — is the engine that drives most of our CLI improvements. Roughly 80% of CLI UX improvements originate from internal usage, not from external developer requests. ## Every engineer uses the CLI ![Illustration for this section](https://pics.nowah.xyz/website-media/developer-experience-025-img-1-feedback-loop.webp) This is not a suggestion at Nowah\. It is a practice\. Every engineer has the CLI installed and uses it for daily work\. Integration smoke tests run through the CLI\. Production debugging starts with \`nowah logs tail\`\. Webhook verification during development uses \`nowah webhooks listen\`\. The result is a continuous testing surface. More than ten internal engineers running the CLI daily means that rough edges surface quickly. A confusing error message, a slow command, an unintuitive flag name — these get noticed within days and reported within hours. External developers might use the CLI a few times a week. Internal engineers use it a few times a day. The higher frequency means we encounter edge cases and UX problems faster. ## Three internal use cases **Integration smoke tests.** Before any backend deployment, an engineer runs the full booking workflow through the CLI: search, book, verify, check webhooks. This catches integration regressions that unit tests miss. The CLI's sandbox mode makes this repeatable and deterministic. **Production debugging.** When something goes wrong, the CLI is usually the first tool an engineer reaches for\. \`nowah logs tail\` with filters narrows the problem quickly\. The request ID from the log stream feeds into deeper investigation\. We find that engineers reach diagnosis faster with the CLI than with web\-based log aggregation tools because there is less context\-switching overhead\. **\[Incident response\]\(/blog/incident\-response\-travel\-platform\)\.** During incidents, the CLI provides real-time visibility. An engineer can tail logs filtered to error status codes, watch for patterns, and identify the scope of the problem within minutes. The CLI's ability to combine log streaming with webhook monitoring gives a complete picture of system behavior during an incident. ## The feedback channel ![Supporting diagram](https://pics.nowah.xyz/website-media/developer-experience-025-img-2-usage-patterns.webp) We have a dedicated internal channel for CLI feedback. Engineers post observations, pain points, and feature requests. The bar for posting is low — "this flag name confused me for a second" is a valid observation. The CLI team triages the channel weekly. Average triage time is under 24 hours for reported issues. Fixes for small UX issues (better [error messages](/blog/error-messages-ai-agent-lifeline), improved help text, flag name changes) often ship within a few days. We track these feedback items alongside external developer feedback. Internal items get first-pass priority, not because internal engineers are more important, but because they represent real friction that we can fix before external developers encounter it. Catching problems early is always cheaper than catching them after they have affected customers. In the last quarter, internal dogfooding caught three critical UX bugs before any external developer reported them. One was a confusing error message when the API key had insufficient permissions. Another was a race condition in the webhook listener that occasionally dropped the first event. The third was a JSON output formatting inconsistency that would have broken scripts depending on a specific structure. ## The empathy advantage Building tools for yourself creates a different relationship with the product than building tools for others. When I use the CLI and hit a rough edge, I feel the frustration personally. That motivation to fix it is stronger than reading a [support ticket](/blog/every-support-ticket-dx-bug) about the same issue. This empathy extends to [design decisions](/blog/year-in-review-design-decisions-shipped). When we debate whether a feature is worth building, someone can usually say "I needed this last week during an incident" or "I would use this every day for testing." The debate resolves quickly because the team has firsthand experience with the problem. The flip side is that internal usage can create blind spots. We know the API intimately, so we might build CLI features that assume knowledge that new developers do not have. We counter this by also watching how developers interact with the CLI during onboarding sessions and usability tests. Internal usage drives rapid iteration. External observation drives empathy with beginners. ## Starting a dogfooding practice If you build [developer tools](/blog/dogfooding-developer-tools-feedback) and your team does not use them daily, here is how to start: **Make it required for one workflow.** Pick a common engineering task — running integration tests, checking deployment health, debugging issues — and make the CLI the standard way to do it. Not the optional way. The standard way. **Create a feedback channel with a low bar.** Any observation is valid. "This took me three seconds to figure out" is useful feedback even if the tool technically works correctly. **Triage weekly and ship fast.** If feedback sits in a backlog for months, engineers stop reporting it. Fast response reinforces the feedback habit. The investment is modest. The return is a CLI that your own team actually wants to use, which means external developers will too. You cannot fake quality. You can only earn it by using the tool yourself and fixing what hurts. --- 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).