What I learned building
a lightweight observability platform
The hard part was not collecting every possible signal. It was deciding which signals made operational work clearer.
Building OpenTrace reinforced a simple lesson: observability tools can become heavy quickly. Every new feature sounds reasonable. More charts, richer filters, deeper integrations, smarter aggregation, more provider types. The challenge is keeping the product aligned with the original job.
The original job was small: make scripts, workers, batch jobs, and operational processes visible while they run. That meant the product needed to accept progress, metrics, notes, JSON payloads, and milestones without forcing teams into a large platform commitment.
Clarity beats completeness
A lightweight observability platform should not try to win every observability category. OpenTrace is not meant to replace infrastructure metrics, complex dashboarding, log search, or exception tracking. Saying no to those jobs makes the core experience cleaner.
Adapters matter
Real systems do not all emit clean events on day one. The relay work made that obvious. Database queues, query mode, REST polling, and webhooks are all practical bridges from existing systems into a normalised event stream.
The product is the habit
The biggest value is not the endpoint or the UI by itself. It is the habit of making software explain meaningful work as it happens. If OpenTrace makes that habit cheap enough to adopt, the platform is doing its job.