Dogfooding
OpenTrace
The best way to find missing telemetry is to become the operator of your own system.
I do not want to ask other people to instrument their software before instrumenting my own. If OpenTrace is meant to make background work easier to understand, then OpenTrace itself should be one of the first systems forced to explain what it is doing.
That makes dogfooding less about product ritual and more about credibility. New features should survive contact with OpenTrace's own operational workload. If something is awkward to use internally, it probably needs redesigning before it becomes someone else's problem.
Real operation exposes real gaps
Synthetic examples are useful, but they rarely create the same pressure as operating the product daily. Real systems have startup phases, cleanup jobs, notification workers, relays, background tasks, missed expectations, and awkward edge cases that do not appear in polished demos.
Every time I ask "I wonder what it's doing?", I try to teach OpenTrace to answer that question itself. A recurring operational question is usually a missing signal waiting to become a feature.
Features in context
Dogfooding creates natural places to exercise the product: progress tracking for background tasks, expectations for scheduled jobs, milestones during startup, JSON notes for diagnostics, internal health collections, and self-monitoring for relays, cleanup jobs, and notification workers.
Those are not just feature checklist items. They are answers to concrete questions that appear while running the system: did the relay start, is the cleanup job progressing, which notification worker handled the event, and what did the diagnostic payload say?
Friction becomes design input
Operating the product daily reveals friction that a feature plan might miss. A payload may be too hard to scan. A milestone may need better naming. A view may make the common question take one click too many. The value of dogfooding is that these problems become hard to ignore.
Credibility compounds
OpenTrace should evolve from real operational friction, not hypothetical use cases. The product is more trustworthy if its own development keeps proving the same principle it recommends to users: important work should explain itself while it runs.