TimeScribe: a NativePHP desktop time tracker that keeps every hour on your own disk

The problem TimeScribe picks: billing hours without handing over the timesheet

Most time trackers assume a server. You sign up, the timer writes to someone else's database, and the monthly invoice is generated from data you cannot inspect. TimeScribe inverts that. The README states the app is "100% Offline & Private" and that data stays on your device, with no registration and no paywall. The intended users are named directly: freelancers billing clients, remote workers logging hours, and people tracking personal productivity.

The practical consequence is that the billing loop closes locally. Projects carry descriptions and hourly rates, and the app performs the billing calculations, according to the feature list. That matters for anyone who currently keeps a timer in one tool and a spreadsheet of rates in another. It also means there is no vendor account to lose access to, and no subscription that lapses and locks your history. The trade is that nothing syncs. If you work across two machines, the repository does not describe a mechanism for merging those two local stores, and you should assume there is not one.

Laravel, NativePHP and Vue inside an Electron shell

The topic list and build instructions point to an unusual stack for a desktop utility. The primary language is PHP. The build steps are Laravel commands (composer install, php artisan key:generate), and the packaging step is php artisan native:build mac, which is the NativePHP build command. The front end is Vue, and Electron appears in the topic list. So the shape is a Laravel application, wrapped by NativePHP, shipped as a desktop binary, with a Vue interface on top.

That explains a few product decisions. Laravel gives the project a migration and model layer for projects, time entries and absences, and an artisan command surface for building. It also explains why the build instructions look like a web app setup: copy .env.example to .env, generate an application key, then run the native build. The README's Windows build line is marked "coming soon or adjust accordingly", which is a candid admission that the source build path is not symmetric across the two platforms even though the shipped installers are.

What the material does not describe is the storage engine behind those Laravel models. Whether entries land in SQLite, a JSON file, or something else is not stated in the README. That is the first thing to check if you care about backing up or querying your own hours outside the app.

Installing it, and the four paths the README gives

There are four documented routes. The direct route is a release download: TimeScribe-setup.exe on Windows, or TimeScribe.dmg for macOS with separate Apple Silicon and Intel builds. On macOS you open the disk image and drag the app to Applications. On Windows you run the installer.

Package managers are covered on both sides:

brew install timescribe

winget install WINBIGFOX.TimeScribe

Building from source is the fourth path, and it is explicitly labelled for developers:

git clone https://github.com/WINBIGFOX/timescribe.git cd timescribe composer install npm install cp .env.example .env php artisan key:generate npm run build php artisan native:build mac

Two things stand out. First, the app ships with auto updates, so the packaged installs are the low-maintenance route and a source build is mainly for people modifying the app. Second, the environment file matters: the README requires copying .env.example and generating an application key before the native build, which means the build is not a single command and will fail if you skip the key generation step.

Idle detection, app activity and the privacy claim it depends on

The feature list includes auto start and pause based on screen time and idle status, plus an app activity view that separates work from distractions. This is the most sensitive capability in the product, and it is worth being precise about it. To classify app usage, the application has to observe which application is in the foreground. The README's privacy claim is that this data stays local, not that it is never collected.

That distinction is the whole argument for the tool, and it is a defensible one: a local classifier that never transmits is a different proposition from a cloud tracker that profiles your desktop and stores the profile on a server. But it also means the privacy guarantee is only as strong as the absence of network calls. The README asserts the app does not track you. It does not document a network audit, an offline mode toggle, or a way to inspect what the app writes. If you are adopting this on a managed device or under a policy that requires evidence of data flows, the README alone will not satisfy that requirement, and you would need to inspect the source or observe the process yourself.

The categorisation also implies a maintenance burden. Work versus distraction is a judgement the app has to encode, and the README does not describe how rules are defined or whether you can edit them. Treat the app activity screen as a heuristic, not an authoritative record.

Exports, absences and the reporting surface

TimeScribe exports PDF, Excel and CSV, which is the escape hatch for anyone who has to feed hours into an invoicing or payroll system. The absence planning features cover vacation, sick leave and holidays, which is what turns a timer into something closer to a timesheet: you can account for a full month rather than only the hours you remembered to run the clock.

There is also a deep-link API documented for macOS and Windows, referenced in the README as a separate section. That is the integration point for anyone scripting the timer from another tool. The material does not reproduce the URL scheme here, so check the Deep-Link API section of the repository before designing around it.

Keyboard shortcuts are customisable, and the interface is translated into Danish, English, French, German, Italian, Polish, Brazilian Portuguese and Chinese. That language list is unusually broad for a solo-maintained desktop app, and it suggests the maintainer is optimising for individual users across regions rather than for a single enterprise market.

Where TimeScribe is the wrong tool

The offline-first design is the limitation as much as the selling point. There is no server component described anywhere in the material, so there is no shared team timesheet, no manager approval flow, no central rate table, and no way for two people to see the same project hours. If your requirement is "the finance team pulls everyone's billable hours on the first of the month", TimeScribe does not do that. You would export CSVs from each machine and reconcile them yourself.

The platform support is the second boundary. The README lists macOS and Windows only. Linux is not mentioned, and the source build instructions only cover mac and win targets. Anyone on Linux should stop reading here.

The third boundary is durability. Because the data lives on one device with no cloud copy, a lost laptop is a lost timesheet unless you have your own backup covering wherever the app stores its database. The README does not describe a backup or restore feature, and it does not describe where the data file lives, so you cannot build a backup routine from the documentation alone.

Finally, the stack has a cost. A PHP and Laravel application packaged as a desktop binary is heavier to build and debug than a plain native app, and the Windows source build is flagged as unfinished. If you intend to fork and ship your own build, budget for that.

What it is not: a comparison with Toggl Track and Kimai

Two obvious alternatives sit at different points on the same axis. Toggl Track is the hosted option: the timer writes to a service, and the value you get in return is sync across devices, a web dashboard, and team reporting. TimeScribe deliberately gives up that value to avoid the account. The difference is not features, it is where the record of truth lives. If you lose your laptop with Toggl, you log in elsewhere. If you lose it with TimeScribe, you recover only what you backed up.

Kimai is the self-hosted option, and it is the more interesting comparison because both projects reject the cloud vendor. Kimai is a PHP web application you deploy on a server you control; TimeScribe is a desktop binary you install on your own machine. Kimai gives you multi-user timesheets, an API and a browser interface at the cost of running and patching a server. TimeScribe gives you a menu bar timer and zero infrastructure at the cost of single-user, single-device data. The right question is not which is more private. Both keep data off third-party servers. The question is whether you want to administer a service or install an app.

A third pattern worth naming: a plain text file plus a timer script. It is more transparent and more scriptable than any of these, and it has no billing calculations, no absence planning and no app-activity view. TimeScribe's case rests on those features being worth the packaging.

Licence, release cadence and what to verify before you commit

TimeScribe is GPL-3.0. For an end user installing the binary, that means the source is available and the app can be redistributed under the same terms. For anyone modifying and shipping it, the copyleft obligation applies to derivative distributions, and the practical implication is that a closed-source fork is not an option. This is a general description of the licence family, not legal advice; read the LICENSE file and the full text if you plan to redistribute.

The release history shows a steady cadence: v1.13.0 in late April 2026, v1.14.0 in May, v1.15.0 in early June, with the latest push and release on the same day. Auto updates mean packaged users ride that cadence without acting. Source builders do not: every release is a rebuild, and because the build involves composer install, npm install and a native build step, an upstream dependency change can break your build independently of any TimeScribe change. That is the real maintenance cost of the source path, and it is not visible from the release notes.

Before adopting, verify three concrete things. Confirm the Homebrew cask and the WinGet manifest resolve to the same version as the GitHub release, since the README advertises all three. Locate the local data file so you can include it in your existing backup, because the documentation does not tell you where it is. And run one export of a week with a real hourly rate through the PDF and CSV paths to confirm the billing maths matches how you invoice. If those three checks pass, the app does exactly what its first line claims.

Editorial conclusion

Adopt TimeScribe if you are a freelancer or solo worker on macOS or Windows who wants hourly rates, project billing and app-activity categorisation without sending timesheet data to a vendor, and you are comfortable with the data living in a single local store. Do not adopt it if you need a shared team timesheet, a hosted API, or a Linux build, none of which the repository describes. Before installing, verify two things on your own machine: that the current release still matches the Homebrew cask and WinGet manifest versions, and that the PDF, Excel and CSV exports produce the column layout your invoicing or payroll process expects.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. WINBIGFOX/TimeScribe on GitHub