We almost shipped Planim Time as a Cloud plugin. The Atlassian Marketplace gives you discovery, billing, and an authenticated user on day one — for a small team that’s a serious head start, and the first three months of design assumed that’s where we’d land.
We changed our minds in late 2024, after the third or fourth weekly Cloud incident left a handful of our own beta testers staring at a spinner instead of a timer. The thing we were building was supposed to remove a problem from your day, not add a new failure mode that lit up whenever Atlassian had a bad afternoon. So we threw out the Marketplace assumption and started writing a Rust binary that lives in your menu bar.
A year and a few thousand installs later, here’s what justified that decision.
Cloud plugins inherit Cloud’s bad days
Atlassian’s status page is honest about this: a couple of degraded periods a month, plus a handful of “investigating issue” events on top of that. Most of those are short. The longer ones tend to land between two and five in the afternoon — exactly when several of you are mid-task and the one piece of UI you actually need is a working timer.
A Marketplace plugin shares that fate. The plugin is an iframe inside a UI that just went dark. The session might survive, the timer might not. You won’t know which until the page comes back.
A native binary side-steps the question. The timer is local. So is the SQLite store with the running entry and every worklog you haven’t pushed yet. The app talks to Jira when it can, queues changes when it can’t, and reconciles when the connection comes back. We call this offline mode, it was the first path we tested, and it’s the path most of our paying users actually use. Hit stop on a flight, push when you land. (The reconcile side of that is its own engineering story, written up in Two-way Jira worklog sync.)
Browser tabs are the wrong surface for a timer
Tab-based trackers have two failure modes that are almost impossible to design out of:
The silent re-auth. Your Jira session expires, the tab refreshes, the timer running for 38 minutes resets to zero. Whether the in-progress worklog survived depends on the app. Most save it. Some don’t. You find out by accident, usually a week later, when you can’t reconstruct what you did on Tuesday.
The lost tab. You closed it because the laptop was running hot, or because you were debugging something noisy and pruned a few. Now you don’t know whether the timer was running, and the only way to check is to go look — by which point your concentration is gone anyway.
Neither failure exists when the timer is an icon in the system menu bar. It sits next to the clock and the Wi-Fi indicator. That’s the right place for a piece of state you want to glance at without thinking, and the wrong place to lose to a memory-pressure tab eviction.
Your API token belongs in your keychain
A hosted web app stores your Jira API token on its servers because there is nowhere else for it to live. Even if the vendor does everything right — encryption at rest, audited access, key rotation — the token is now part of someone else’s threat model. If they get breached on a Friday night, you find out about it on Monday morning, and the remediation is on you.
A native desktop app uses the OS keychain. macOS Keychain. Windows Credential Manager. Linux Secret Service through libsecret, which on most distros means GNOME Keyring or KWallet. The same vault your browser uses for saved passwords. We don’t see the token, our logs don’t see it, our backups don’t see it. There is nothing for an attacker who breached us to steal because it isn’t there.
This is the part that converted the most engineers we showed an early build to. The vault block on the homepage makes the same point in a screenshot.
One installer, four flavours of Jira
A Marketplace app targets one Jira flavour. Cloud has its own SDK and review process. Server reached end-of-life in February 2024 but a chunk of regulated and air-gapped teams still run unsupported instances, and they aren’t moving to Cloud anytime soon. Data Center is its own world again, with its own pricing and its own deployment story.
Planim Time is one binary. It picks the right API endpoints based on the URL of the instance you authenticate against, and the UI on top is identical regardless of where Jira is hosted. Engineers on Data Center and engineers on Cloud get the same hotkeys, the same calendar view, the same worklog editor. We don’t maintain four codebases, you don’t have to care which flavour you’re on, and the comparison pages we publish — for instance, Planim Time vs Tempo — apply to all of them.
Where a web tracker is still the right answer
Two cases. We’ve thought about them, and we’re fine losing them.
If you genuinely track time across three or more devices in a day — say a personal laptop, a work laptop, and a phone you log to between meetings — a web app is portable in a way an installer isn’t. We don’t pretend to beat that. The desktop binary is per-machine by design.
If your accounting team needs worklog data to flow into Atlassian’s billing pipeline through the official Marketplace integration — the one that powers their internal cost-allocation reports — that’s a Marketplace plugin’s job. Tempo and Clockwork are good answers there, and we cover both head-to-head on the comparison hub.
For everyone else — the engineer tracking time on their work laptop, mostly to remember what they did last Tuesday at standup, occasionally to send a real worklog up to Jira — a desktop app is the better default. That’s who we built this for.
If you want to try it, the free tier of Planim Time for Jira is the whole tracker, not a teaser. Download it and point it at your real Jira for a sprint. If it fits, the upgrade path is there. If not, no account to delete and nothing of yours stuck in a database we control.