Tarlog

Privacy first time tracking, compliance, and invoicing for freelancers, with local and self hosted workflows.

Comment

Inspiration

Many time tracking tools require users to choose between convenience, privacy, and professional reporting. Local applications often lack synchronization and invoicing, while cloud services may introduce subscriptions, external dependencies, and uncertainty about where sensitive client data is stored.

I wanted to create a tool that treats time records as reliable business documents rather than temporary timer data. Freelancers should be able to record their actual working time, calculate billable time, document corrections, review compliance warnings, generate invoices, and export verifiable records without being forced to use an external cloud service.

That idea became Tarlog.

What it does

Tarlog is a privacy focused time tracking, compliance, and invoicing application for freelancers, consultants, developers, designers, and other independent professionals.

Users can create customers, projects, tasks, hourly rates, daily rates, and fixed fee agreements. They can track work with a live timer or add past entries with a documented reason.

Tarlog keeps actual working time separate from billable time. For example, a 70 minute session can be rounded to 75 billable minutes while preserving the original 70 minute duration.

The application also provides German working time compliance checks, PDF timesheets, CSV exports, invoice generation, cancellation invoices, audit logs, backups, and synchronization conflict detection.

The desktop application works fully offline with SQLite. Tarlog can also be deployed as a self hosted web application using PostgreSQL, allowing multiple browsers to work with the same database.

How we built it

Tarlog is organized as a pnpm monorepo with TypeScript used across the shared packages and client applications.

The shared core package contains the central business logic for time calculations, rounding rules, billing, compliance evaluation, onboarding, and data validation. This allows the desktop, web, and mobile applications to use consistent rules.

The desktop application is built with Tauri 2, Rust, React, Vite, and SQLite. It supports a fully local workflow without requiring an internet connection.

The web application uses Next.js 15, PostgreSQL, REST APIs, WebSockets, PDF generation, and Docker. WebSocket communication provides live updates, with long polling available as a fallback.

The mobile foundation uses Expo, React Native, and local SQLite storage. Its architecture is prepared for future synchronization, but it is not yet production ready.

Drizzle ORM provides database models for both SQLite and PostgreSQL. Monetary values are stored as integer cents. Time values are stored as UTC epoch milliseconds together with an IANA time zone. Records use UUIDv7 identifiers.

Synchronization is based on a server event log, optimistic version checks, and a Hybrid Logical Clock. Outdated updates are rejected and stored as explicit conflict records instead of silently overwriting newer data.

Automated tests verify important invariants such as the single active timer rule, rounding behavior, compliance checks, invoice finalization, PDF and CSV exports, conflict detection, WebSocket updates, and audit logging.

Challenges we ran into

One of the largest challenges was keeping actual time and billable time separate throughout the entire system. Rounding must affect billing without changing the historical record of how long someone actually worked. This distinction had to remain consistent across the database, calculations, exports, invoices, interfaces, and tests.

Synchronization was another major challenge. An offline capable application must handle interrupted connections, duplicate events, outdated versions, partially applied updates, and conflicts between devices.

Tarlog stores incoming desktop events before applying them. The synchronization cursor is advanced only after a successful and repeatable merge. Because the complete native merge workflow is still under development, Tarlog reports an explicit error rather than incorrectly claiming that synchronization succeeded.

Supporting both SQLite and PostgreSQL also required careful design. The same business rules and data integrity guarantees must work in a fully local desktop installation and in a shared server environment.

Compliance features created an additional responsibility. Tarlog can identify possible working time and break rule violations, but these results must be presented as helpful product guidance rather than legal advice.

Accomplishments that we're proud of

We are especially proud that Tarlog already supports a complete local workflow without requiring a server or cloud account.

The application preserves original working time while calculating rounded billable time independently. It also enforces the single active timer rule at the database level, preventing multiple timers from running simultaneously even when requests arrive at nearly the same time.

The self hosted web application supports authentication, PostgreSQL persistence, live browser updates, invoices, exports, audit logs, backups, and synchronization conflict detection.

Tarlog also includes an automated onboarding flow that creates real customer and project data, teaches the core workflow, saves progress between restarts, and does not interrupt existing installations.

The project is continuously verified through builds, type checks, Rust tests, integration tests, and a server smoke test using a real PostgreSQL service.

What we learned

Building Tarlog taught us that professional time tracking is primarily a data integrity problem.

A polished timer interface is important, but the most difficult work involves preserving historical values, documenting corrections, avoiding silent data loss, handling concurrency, generating reproducible documents, and proving critical behavior through automated tests.

We also learned how valuable shared domain logic is. By separating business rules from platform specific interfaces, the same calculations can be reused and tested across desktop, web, and mobile applications.

Another important lesson was the value of transparent limitations. Experimental functionality should be clearly identified as experimental. A system should preserve data and fail visibly rather than display a successful result that cannot be verified.

What's next for Tarlog

The next priority is completing and validating native desktop synchronization with the self hosted server.

This includes connecting every local mutation to the synchronization outbox, completing the local merge process, adding a full conflict resolution interface, improving credential storage, and testing the complete desktop to server workflow.

After that, development will focus on completing the iOS client and its synchronization workflow.

Future plans also include data import, webhooks, improved reporting, a customer portal, optional team functionality, stronger deployment tooling, and additional platform specific interface improvements.

The long term goal remains simple: give independent professionals full control over their time, business records, infrastructure, and data.

Built With

Share this project:

Updates