Work Review: a local-first Rust and Tauri app that turns your day into a reviewable timeline
Automatically tracks which apps you used, which websites you visited, and how much time you spent in each app throughout the day.
At a glance
- What is it?
- Work Review records foreground apps, browser URLs, window titles, usage time and optional screenshots into a local SQLite database, then lets you query and export a daily report. It is a personal recall tool, not an employee monitoring product.
- Who is it for?
- Adopt Work Review if you want a private record of your own working day and are willing to run a Tauri desktop build on macOS, Windows or Linux. Skip it if you need team-wide attendance or manager-facing reporting: the README states it is not intended for employee monitoring, team attendance or performance evaluation.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Work Review solves, and who it is actually for
The README frames the product around recall rather than surveillance. The questions it lists are personal ones: what did I actually do today, what have I been focusing on over the past few days, roughly how much time did a particular task take, which pages and windows did I look at back then, and how do I put today's daily report together quickly. That is a different job from time billing or attendance. The stated audience is a single person reviewing their own work process on their own machine.
The README is explicit about the boundary: Work Review is not intended for employee monitoring, team attendance, performance evaluation or covert tracking. That sentence matters more than any feature list, because the recording model (foreground apps, window titles, browser URLs, optional screenshots and OCR text) is exactly the data a manager would want and exactly the data a worker would not want collected. The project resolves the tension by declaring the personal-use scope and storing everything locally by default, with no server upload.
If your problem is "I cannot remember where the afternoon went", this is aimed at you. If your problem is "I need to prove my team was working", this is the wrong tool, and the README says so.
How the recording pipeline and local store fit together
The stack is a Tauri desktop application: a Svelte and TypeScript frontend under src/, a Rust backend under src-tauri/, and a Cargo workspace whose members are crates/core, crates/mcp-server, crates/skills-engine and src-tauri. That split is visible in the repository layout, and it tells you where the interesting work happens. Collection and storage live in Rust, the UI is a web view, and the MCP server is a separate crate rather than a feature bolted into the app.
The capture layer records foreground applications, window titles, browser URLs, usage duration and category records. Screenshots and OCR are optional and follow multi-display strategies. To avoid inflating the record, the app also uses keyboard and mouse activity plus screen-change idle detection, which the README describes as a way to reduce false records. That is a sensible design: idle detection is what stops a forgotten open window from being counted as hours of work.
Everything lands in local SQLite by default. The Overview, Timeline, Work Assistant and Daily Report surfaces all read from the same local records, which is why the README can claim you can inspect trends and then drill into the underlying context without switching data sources. The crates/mcp-server member is the integration path: it exposes those local records to an MCP client, and the screenshots include an Integrations screen for MCP Server settings. AI features are gated behind your own model configuration and API key, with no third-party relay, and the app works with them switched off.
Installing Work Review and getting a first day recorded
The README points at the releases page for the latest build, and the repository is a Tauri project, so the normal path is to download a packaged desktop build rather than compile from source. The README does not document a package-manager install, so treat the release artifacts as the entry point. Once installed, the first useful step is to confirm that recording is on and that your sensitive applications are excluded.
The repository declares Node 22 or newer in package.json, and the dev and build flow is exposed as npm scripts. If you want to run from source rather than use a release build, the Tauri CLI is wired up as scripts:
npm install
npm run tauri:devThe first command installs the frontend dependencies, including the Tauri CLI and Svelte toolchain. The second starts the Tauri development build, which compiles the Rust workspace and opens the desktop window. Expect a first compile that takes noticeably longer than later runs, because the workspace includes crates/core, crates/mcp-server, crates/skills-engine and src-tauri.
For a distributable build, the same scripts provide the packaging commands:
npm run tauri:build
npm run verify:frontendThe first produces the desktop bundle. The second runs the frontend gate the repository defines: svelte-check, the Node test runner over the *.test.ts files, and a Vite build. Running verify:frontend before tauri:build is the cheap way to catch a type error before spending time on a full Rust release build, which the workspace configures with lto, codegen-units = 1 and strip.
After the app is running, the practical first task is not reading the timeline but setting the recording scope. The README describes per-app settings with three modes: Normal, Anonymize and Ignore, where anonymize mode automatically skips screenshots and OCR. There are also automatic sensitive keyword filtering, a domain blacklist, auto-pause on screen lock, and manual pause and resume. Do that configuration before you let it run for a day, because retroactively cleaning a screenshot store is harder than never capturing it.
Where Work Review breaks down or is the wrong choice
The largest limitation is the one the project states about itself. A tool that records window titles and browser URLs produces a detailed behavioural log, and the README's prohibition on employee monitoring is a scope declaration, not a technical control. Nothing described prevents someone from installing it on a managed machine and reading the database. If you are the person being observed, local storage is not a guarantee you control; if you are the observer, this is not a product you should be reaching for.
The second constraint is capture fidelity. Idle detection based on keyboard, mouse and screen change reduces false records, but it is a heuristic. Reading a long document without input may register differently from scrolling through it, and the README does not describe how those cases are classified. Anyone using the timeline as a billing record should treat the durations as approximate, which is consistent with the README's own phrasing about roughly how much time a task took.
Third, the AI surfaces are optional and depend on you supplying a model and API key. The README states AI is disabled by default and only activates after you configure a model. That means the Work Assistant, the AI-enhanced modes and the cached AI section ordering in daily reports are not part of the out-of-the-box experience. If you evaluate the app with AI off, you are evaluating the recording and timeline layer, not the assistant.
Finally, the release channel deserves attention. The most recent release listed is v1.1.3-rc.1, a release candidate, published on 2026-09-05, after the stable v1.1.2 on 2026-08-22 and v1.1.1 on 2026-08-10. The repository is not archived and the last push was on 2026-09-06. If you want a stable tag, v1.1.2 is the one to install rather than the candidate.
How it differs from RescueTime and other cloud trackers
The obvious alternative category is automatic time trackers such as RescueTime, which also record foreground applications and websites and produce dashboards. The difference is architectural, not cosmetic. Cloud trackers sync your activity to a vendor account and give you a web dashboard; Work Review keeps records in local SQLite by default and states that nothing is uploaded to any server. That changes who can read the log and what happens when the vendor's service changes terms or shuts down.
The second difference is the AI path. Work Review does not run model calls through a relay: the README says model calls use your own API key, and the crates/mcp-server member exposes local records over MCP so an external client can query them. A hosted tracker typically owns that layer. If you already have a model provider and an MCP-capable client, this is a meaningfully different integration story.
The third difference is scope discipline. RescueTime-style products are sold to both individuals and teams, and the team tier is where attendance and productivity reporting live. Work Review declines that market in the README. If you need per-person reporting across a group, you are not choosing between two implementations of the same thing; you are choosing a different product category.
Maintenance, upgrade cost and the MIT licence
The repository is not archived and the last push was on 2026-09-06, so the codebase is moving. The release cadence visible in the release list is roughly two to three weeks between versions across August and September 2026, with a release candidate at the top. That cadence is a cost as well as a signal: a personal activity database is something you may keep for years, and schema changes in a fast-moving app are the kind of thing that makes upgrades worth reading the changelog for. The repository ships a CHANGELOG.md, so check it before moving between versions.
Upgrade cost also depends on how you installed it. A packaged release is a normal application update. A source build means re-running the Tauri build after pulling, and the workspace release profile (lto, codegen-units = 1, strip) makes that a slow compile. The frontend gate is cheaper and the repository provides it as npm run verify:frontend.
The project is MIT licensed, which is permissive and places few obligations on you if you fork or redistribute. Two caveats worth checking yourself rather than assuming: the repository includes a THIRD_PARTY_NOTICES.md, so bundled dependencies carry their own terms, and the README mentions a Desktop Avatar Beta, which in a work-review tool usually means bundled character assets with separate licensing. The MIT file covers the project's own code; it does not automatically cover every asset shipped in a release. That is a question for the notices file and, if it matters to your use, for a lawyer.
Editorial conclusion
Adopt Work Review if you want a private record of your own working day and are willing to run a Tauri desktop build on macOS, Windows or Linux. Skip it if you need team-wide attendance or manager-facing reporting: the README states it is not intended for employee monitoring, team attendance or performance evaluation. Before installing, check two things: whether the release you pick is a stable tag or the v1.1.3-rc.1 release candidate, and whether screenshot and OCR capture are acceptable on the machine, since anonymize mode skips both.
Frequently asked questions
What is Work Review?
It is a local-first desktop application, written in Rust with a Tauri and Svelte frontend, that records foreground apps, browser pages, window titles and usage time, then lets you review a timeline and generate daily reports. The README describes it as a personal work review tool rather than a monitoring product.
What should I say in a Work Review daily report?
The app generates structured daily reports from your local records, with Markdown export, auto-export, paragraph editing and pin or hide controls. You edit the generated paragraphs rather than writing from a blank page, and AI section ordering is only available once you configure a model.
What is an example of a good review in Work Review?
The README does not provide sample reports or templates. It describes the report as structured and exportable to Markdown, and the Work Assistant answers questions such as what you did today and how long a task took, based on your own local records.
What is Work Review called in other words?
The repository topics describe it as a time tracker and time-tracking tool with a daily report, dashboard, work log and privacy focus. The README itself calls it a local-first personal work review tool.
How is the quality of work reviewed in Work Review?
The app does not score or grade your work. It records usage duration, window titles and categories, and the Overview shows a one-sentence summary, KPI cards with week-over-week deltas, and a today rhythm card with category composition and per-day investment.
Community notes