TimeScribe: offline time tracking for macOS and Windows, built on Laravel and NativePHP

The problem TimeScribe targets: billable hours without an account

Most time trackers assume a server. You sign up, the timer runs against a hosted workspace, and your hours live in someone else's database until you export them. TimeScribe inverts that. The README states the app is 100% offline and that data stays on your device, and the repository topics include offline-first, no-cloud and privacy-focused. There is no registration step and no paywall mentioned in the install instructions.

The audience is narrow and clearly stated: freelancers billing clients, remote workers logging hours, and people tracking personal productivity. The project's own feature list includes projects with descriptions, hourly rates and billing calculations, plus absence planning for vacation, sick leave and holidays. That combination points at a single person who invoices, not at a company running payroll. If your timesheet has to be approved by a manager, TimeScribe's local database is the wrong shape for the job.

How TimeScribe is built: Laravel, NativePHP and a local SQLite file

The repository layout is a Laravel application wrapped as a desktop binary. The top level holds app/, bootstrap/, config/, database/, routes/, resources/, storage/ and artisan alongside package.json and vite.config.ts. The front end is Vue 3 with Inertia, TypeScript and Tailwind, bundled by Vite; the devDependencies list @inertiajs/vue3, vue 3.5, vite and laravel-vite-plugin, and apexcharts handles the day and week charts.

The desktop packaging is NativePHP, visible in the NATIVEPHP_* keys in .env.example: NATIVEPHP_APP_ID, NATIVEPHP_UPDATER_PROVIDER, NATIVEPHP_UPDATER_ENABLED and NATIVEPHP_DEEPLINK_SCHEME=timescribe. The deep-link scheme matches the Deep-Link API feature in the README, which is how an external tool can start or stop tracking. Persistence is local: DB_CONNECTION=sqlite in the example environment, with SESSION_DRIVER=database and QUEUE_CONNECTION=database. Nothing in that file points at a remote API.

The consequence is that the whole application, including its HTTP layer, runs on your machine. That is why the app can work with no account, and also why there is no shared workspace: two installs do not see each other's data.

Installing TimeScribe on macOS and Windows

The README gives four install paths. On macOS with Homebrew, one command installs the cask; the README then says to launch TimeScribe via Spotlight or from the Applications folder.

brew install timescribe

On Windows with WinGet, the package identifier is the publisher and app name.

winget install WINBIGFOX.TimeScribe

If you prefer a manual install, the latest release page hosts TimeScribe-setup.exe for Windows and TimeScribe.dmg for macOS, with separate Apple Silicon and Intel downloads on the project site. On Windows you run the .exe and follow the setup; on macOS you open the .dmg and drag the app into Applications. The README does not document an uninstall procedure or where the SQLite database lives on disk, so plan to find that file yourself if you want to back it up.

For a first real use, open the app, start the timer from the menu bar, and stop it after a short interval. Then create a project with a description and an hourly rate, and assign the tracked time to it so the billing calculation has something to work with. The README lists export as PDF, Excel and CSV, so the end of that loop is an export you can attach to an invoice.

Building TimeScribe from source, and what the build steps imply

The README's fourth install option is aimed at developers, and it doubles as documentation of the stack: PHP with Composer, Node with npm, and the NativePHP artisan commands for packaging.

# Clone the repo
git clone https://github.com/WINBIGFOX/timescribe.git
cd timescribe

# Install dependencies
composer install
npm install

# Copy the example environment file
cp .env.example .env

# Generate an application key
php artisan key:generate

# Build for macOS
npm run build
php artisan native:build mac

# Build for Windows (coming soon or adjust accordingly)
php artisan native:build win

Read that last comment carefully. The README itself hedges on the Windows build with "coming soon or adjust accordingly", which means the source build path is documented with more confidence for macOS than for Windows. The shipped Windows installer is a separate matter from building it yourself. The .env.example also leaves NATIVEPHP_APP_VERSION, NATIVEPHP_APP_ID and NATIVEPHP_UPDATER_PROVIDER empty, so a local build has to fill those in before packaging produces something coherent.

There is no documented test command for the desktop shell, though phpunit.xml and a tests/ directory exist and package.json defines typecheck, lint and style scripts. The dependencies are also unusually current: TypeScript 6.0.3, Vite 8, ESLint 10, Tailwind 4.3. Building this in a year will mean resolving a lot of major-version drift.

Where TimeScribe stops: no mobile app, no sync, no team view

The README lists macOS and Windows as supported platforms and nothing else. There is no iOS or Android client, no web app you log into from a phone, and no documented sync service. People looking for an iPhone or Android version of TimeScribe will not find one in what the project publishes. That is a direct consequence of the offline design rather than an oversight, but it is a real limit: if you track time away from your desk, you either note it elsewhere and enter it later or you lose it.

Collaboration is the second gap. Projects, hourly rates and billing calculations are described as features of the local app, not of a shared workspace. A two-person studio cannot both edit the same timesheet, and there is no role or permission model mentioned. The absence planning feature is likewise single-user.

A third limit is the data itself. Because everything lives in a local SQLite database, a lost laptop, a wiped profile or a corrupted file takes your billing history with it. The README does not document an automatic backup, a sync target or a restore path. Exporting to CSV, Excel or PDF on a schedule is the only backup mechanism the documentation implies, and that is a manual habit, not a feature.

Finally, the app is closed to the idea of a server-side API. The Deep-Link API is a local integration point for starting and stopping tracking, not a remote interface for pulling hours into another system. If you need your time data to flow into an invoicing service automatically, you are building that bridge yourself from exported files.

TimeScribe compared with ActivityWatch and Clockify

The two names that come up around this project are ActivityWatch and Clockify, and they represent opposite ends of the same decision.

ActivityWatch is also open source and also local-first, and it is the closer comparison in spirit. The difference is what it measures. ActivityWatch is built around automatic tracking of application and window usage, and TimeScribe ships a comparable feature: the README lists seeing app usage and categorizing work versus distractions, alongside auto start and pause based on screen time and idle status. Where TimeScribe goes further is the billing layer. Projects with descriptions and hourly rates, absence planning, and PDF, Excel and CSV export are all in its feature list. ActivityWatch is not described as a billing tool. So the choice is roughly: ActivityWatch if you want passive insight into how you spend screen time, TimeScribe if the output has to become an invoice.

Clockify sits at the other end. It is a hosted, account-based service with a free tier, which is exactly the model TimeScribe was written against. The trade is real in both directions. Clockify gives you a team workspace, a browser and mobile client, and data that survives a dead laptop, at the cost of an account and your hours sitting on someone else's infrastructure. TimeScribe gives you a local SQLite file and no registration, at the cost of the mobile client, the team view and any sync. Neither is strictly better; they answer different questions about who owns the timesheet.

Licence and the maintenance cost of a Laravel desktop app

TimeScribe is GPL-3.0. For someone installing the binary and tracking their own hours, that changes nothing. For anyone embedding it in a product, the copyleft terms matter, and this article is not legal advice; read LICENSE and talk to someone qualified if you plan to redistribute or link it into a commercial offering.

The upgrade picture is mixed. Releases have been frequent, with v1.13.0 on 2026-04-22, v1.14.0 on 2026-05-20 and v1.15.0 on 2026-06-02, and the README lists auto updates as a feature. The last push to the repository was on 2026-06-02, so the project has been quiet for roughly three and a half months as of this writing. That is not abandonment, but it does mean recent issues may sit unanswered for a while.

The deeper cost is the toolchain. A desktop app built on Laravel, NativePHP, Vue 3, Vite, TypeScript and Tailwind inherits the upgrade cadence of all of them. The pinned versions in package.json are aggressive, and the project's own scripts include check-update and update-all, which tells you the maintainers feel that pressure too. If you build from source, budget for dependency maintenance, not just for the initial build.

Editorial conclusion

Adopt TimeScribe if you are a freelancer or solo worker on macOS or Windows who wants billable hours to stay on your own disk, and you accept that there is no mobile client, no team workspace and no server-side sync. Skip it if you need a shared timesheet that several people edit, or if you work from an iPhone or Android device, because the README lists only macOS and Windows builds. Before trusting it with client billing, install v1.15.0 through Homebrew or WinGet, create one project with an hourly rate, run a single timed session, and export it to CSV to confirm the rounding and the rate arithmetic match what you invoice.

Frequently asked questions

Official sources

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