Why a desk timer doesn't need your data

If you've ever installed a wellness app and been asked to create an account before you could do anything, you've felt the friction that comes with a question most tools don't want you to ask: what does this app actually need to know about me?

For a sit/stand timer — a tool whose entire job is to tell you when to change position — the honest answer is surprisingly little.

What most desk and wellness apps collect

The pattern is familiar. Download an app that promises to improve your posture, your movement habits, or your workday. Before you start, create an account. Choose a password. Maybe verify your email. The app now has an identity for you on a server somewhere, and your usage data — when you sit, when you stand, how long, how often — starts flowing to that server every session.

Some apps go further. Analytics that fingerprint your device. Location data to know when you're at your desk. Social features that tie your movement habits to a profile. Dashboards on the company's end that aggregate your patterns alongside thousands of other users, because that aggregate is valuable — for product development, for investor decks, for ad targeting, or for all three.

None of this is unusual. It's the default architecture of most software built in the last decade: your data lives on someone else's server, and the app works because it calls home.

The question is whether a desk timer needs any of it.

What a cadence timer actually requires

A sit/stand/move timer needs two things to work: a schedule and a record of where you are in it. The schedule says "sit for 30 minutes, then stand for 20, then move for 5." The state says "you're 12 minutes into a standing block." That's the entire data model for the core loop.

If the tool also keeps a history — how many switches you made today, how long your sitting blocks were, what last week looked like — that history is useful to you, not to the tool's operator. A server doesn't need your Tuesday afternoon sitting block to tell you when to stand up on Wednesday.

This is where the architecture question becomes a design question. If the data the timer generates is only useful to the person at the desk, the simplest architecture is one where it stays with that person. On their device. In their browser's local storage, or on their phone. Not because "privacy-first" makes good marketing copy, but because sending the data somewhere else creates work — servers, accounts, authentication, data-protection compliance, breach risk — that the product doesn't need.

Local-first, in this context, isn't a philosophy. It's the path of least complexity.

The sync question

There's an obvious objection: what if you use more than one device? If your schedule and history live only on the phone you used this morning, they aren't on the iPad you switch to after lunch. Cross-device sync is a real need.

But sync doesn't require a third-party backend. Apple's iCloud infrastructure already exists to move a user's data between their own devices. For an iOS app, using iCloud (specifically CloudKit's private database) means the data travels through Apple's servers — encrypted, stored under the user's own Apple ID, and never accessible to the app developer. The timer maker doesn't run the server, doesn't hold the keys, and doesn't see the data.

A note of honesty here: this is encrypted in transit and at rest, but it is not end-to-end encrypted by default. Apple's Advanced Data Protection offers that, but it's an OS-level setting the user enables — not something the app can claim credit for. The data is in Apple's cloud, not on a DeskRhythm server, and that's a meaningful distinction. But it is still, technically, in a cloud. The claim is "your data goes through Apple's infrastructure, not ours" — not "your data never leaves your device."

That's the kind of precision that matters in privacy claims. Overclaiming erodes the trust that honest disclosure builds.

What about analytics

A timer that runs entirely on-device still faces the question of whether anyone is using it. Aggregate usage data — how many people open the app, which features they use, how often — is genuinely useful for knowing whether the product works and where it doesn't.

The question is what that usage signal needs to contain. It doesn't need an identity. It doesn't need location. It doesn't need an advertising identifier or a cross-app tracking profile. It doesn't need cookies.

Cookieless, anonymous analytics — counting events without attaching them to a person — gives the developer enough signal to improve the product without building a profile of any individual user. It's a narrower aperture than most analytics tooling defaults to, and it's sufficient.

Even here, honesty matters. Anonymous aggregate data still passes through a provider's infrastructure, and that provider receives metadata — an IP address, a generic client identifier. That's not the same as "no data about you ever leaves the phone." It's closer to "no data that identifies you leaves the phone, and nothing goes to us." The distinction is small but worth stating, because the alternative — a sweeping "we collect nothing" — would not be fully accurate.

The Nordic and EU context

None of this is contrarian. The direction of European regulation — GDPR, the ePrivacy landscape, the growing expectation from Nordic consumers that tools handle data carefully — points toward exactly this kind of architecture. Local-first storage. Minimal data collection. Clear disclosure of what does get sent and where.

For a product built in and for the Nordic market, this isn't a differentiator to be marketed. It's the baseline. Swedish and EU users increasingly expect that a tool which doesn't need their personal data simply won't collect it. The question has shifted from "why are you privacy-first?" to "why wouldn't you be?"

What's worth noting is that this expectation is spreading. The EU's data-protection framework is increasingly the global reference. Tools built to respect it from the start — not bolted on after a compliance review — tend to be simpler, because the architecture was never designed around data it didn't need.

A simpler tool for a simple job

A desk timer tells you when to change position. It doesn't need to know who you are, where you work, or what your colleagues do. It doesn't need an account, a profile, or a backend. The data it generates — a schedule, a history, a handful of anonymous usage counts — can live on your device, sync through your existing infrastructure, and never pass through a server the timer maker operates.

That's not a feature. It's the absence of unnecessary complexity, which in software tends to be the most durable kind of design decision.

DeskRhythm is built this way — local-first, no accounts, no tracking. Your rhythm stays on your device, syncs through your iCloud if you use more than one, and the rest is silence.