OnTracksy

A ticket board shows status, not history. “In Progress” for six days looks the same as “In Progress” since yesterday.

OnTracksy renders each ticket as a lane, one segment per state, sized by how long it stayed there — a stalled ticket is visually obvious without reading fifteen tickets one at a time.

It doesn’t solve every kind of timeline. A trip itinerary, for instance, is one sequence of things happening one after another — a single track, nothing to compare side by side. OnTracksy’s value shows up specifically when several things are moving through the same set of states at once and you need to see them together: a sprint board, a hiring pipeline, a queue of support tickets. One track alone doesn’t need this; a dozen tracks changing state in parallel do.

It works two ways: connected to Jira, or fully local, with no login and no data leaving the browser.

×

A framework-free core sits behind one adapter interface — a Jira Cloud adapter and a local-only static adapter both implement it, feeding the same pipeline. That’s the whole trick behind shipping standalone and Jira-connected modes as one product instead of two.

Built solo over about four months, with dedicated accessibility and security review passes rather than something bolted on at the end. Development itself was agentic: the repo’s own process docs define a model-tiering scheme — a planning pass on a stronger model, an orchestrating pass on a mid-tier one, mechanical work on a faster one — plus named roles for specific jobs, like a dedicated code reviewer and a dedicated end-to-end spec author. Every change runs against the actual built and loaded extension through a Playwright/BDD suite before it counts as done, regardless of which tier wrote it.

No content script. The extension opens as a full browser tab and talks to Jira over the user’s own session cookie, with narrow permissions requested at runtime rather than granted at install — avoiding the broad “read your browsing history” warning.

The bet was that one framework-free core could serve two very different audiences — teams already living in Jira, and people who just want a private, local timeline — without becoming two separate products. That held: the standalone extension, the Jira-connected extension, and a Jira Marketplace app all run on the same core today.

What’s actually out: the standalone and Jira-connected extension, published and installable from the Chrome Web Store and Edge Add-ons. The Jira Marketplace app is built and working but hasn’t had a public release yet.

• Polling only, no real-time webhooks — a deliberate scope cut, not an oversight.
• Two accepted accessibility trade-offs, both documented rather than silently shipped: the drag/resize handles on a timeline segment are pointer-only and marked aria-hidden rather than half-working with a keyboard; the lane list’s row/cell markup doesn’t sit inside a proper table/grid ancestor, deferred rather than rushed.
• An API-key Jira auth path exists in the code but was never wired to a UI. The only authentication that ships rides the browser’s own Jira session cookie.
• No Firefox support. Trello/Asana/GitHub adapters are anticipated by the interface, none implemented.

An Insights panel — flow metrics, time-in-status breakdowns — is fully built and sitting behind a feature flag, off by default.

The Jira Marketplace app is far along but hasn’t had a formal “done” pass yet.

The timeline engine itself — libs/core — is already written with zero Angular or Jira dependencies, specifically so it could be pulled out into its own package later. Worth doing if a second consumer ever needs it; not done yet.