TimoDesk

I led the development of TimoDesk at TheSoftKing. The engineering involved Laravel, React, Electron, Node.js, Swift, and C# across the backend, web dashboard, desktop agents, and native system integrations.

The part I did not expect to spend my time on was the question underneath all of it: what happens to a team when software starts watching it.

The product is the agent, not the dashboard

Every demo of a tool like this shows the dashboard, because the dashboard is what a buyer looks at. But nobody buys the dashboard twice. What decides whether a company is still paying in month six is a small application sitting in a tray on a laptop we do not own and cannot log into.

Enlarge

Everything hard lived on the client

The server side is a well understood shape: a multi-tenant Laravel API, MySQL, queues for anything touching storage or email. I have built that shape before. It behaves.

The desktop agent does not behave, because it lives in the real world. Laptops sleep mid-task and wake up in a different timezone. Wi-Fi drops on a train. Someone closes the lid at 6pm on Friday and opens it on Monday with two days of unsent data. Corporate VPNs interfere. Antivirus quarantines your binary because it takes screenshots, which is, to be fair, exactly what malware does.

So the agent is offline-first, decided on day one rather than retrofitted: activity is tracked locally and syncs automatically once the device reconnects. Once you commit to that, three constraints follow immediately, and none of them is reversible cheaply later.

First, the local store is the source of truth until the server acknowledges it, so the sync endpoint has to be idempotent. A retry after a timeout must not double-count an hour. Second, you cannot trust the client clock, because anyone can set their machine forward. The server decides what an interval is worth, the client only reports what it observed, and the two get reconciled rather than merged. Third, uploads have to be resumable and cheap, because a Monday morning backlog from a thousand agents is a thundering herd that arrives on schedule.

The unit of truth is an interval

The design decision I am still happiest with is that TimoDesk does not really record events. It records intervals. Work is bucketed into ten-minute windows, and each window carries how long was actually worked inside it, an activity percentage, and the screenshots captured during it.

Enlarge

Intervals are boring and that is the point. They cap the write volume per user per day at a number you can plan capacity around. They make a partial hour explainable: you can see that 1pm to 2pm holds thirty-six worked minutes and exactly which windows they landed in. And they give you something to reconcile against when an agent syncs late, because a window either arrived or it did not. A raw event stream gives you none of that. It gives you a debugging session.

A dollar a month is an engineering constraint

One plan, one dollar per user per month, every feature included. As a pricing page that is a gift: no tiers to explain, no feature gates to build, no upgrade prompts to design. As an engineering brief it is a discipline, because every feature now has to survive division.

What leading it actually involved

In practice the job was three things. Code review as teaching rather than gatekeeping, which is slower and pays for itself the first time someone catches the bug I would have caught, without me in the room. Writing decisions down, especially the rejected options, because a decision without a recorded reason gets relitigated every quarter by whoever is newest. And saying no, out loud, with a reason. At a dollar a month you cannot ship everything, and a lead who will not close a feature request is only deferring the disappointment to a deadline.

Enlarge

What I would keep and what I would change

Keep: offline-first from the first commit, the server as the only authority on time, intervals instead of events, one flat plan, and an agent light enough that nobody has a reason to complain about it. Keep the flat pricing especially, because the constraint made the architecture better.

Change: I would build the employee-facing view before the manager-facing one. Same data, opposite order, and it would have shaped better defaults everywhere downstream. I would instrument the agent properly before scaling the user count rather than after, because you cannot debug a client you have no telemetry from. And I would treat data retention and deletion as launch features with real interface, not as policy to be written once somebody asks.