Draft — MVP Definition
Daymark is a simple, local-first desktop application for tracking time spent on personal tasks.
The product prioritizes:
- extremely low friction;
- fast task switching;
- accurate local time tracking;
- useful daily history;
- simple analytics;
- privacy;
- cross-platform desktop support.
The application does not require an account, backend, cloud service, or internet connection.
Daymark is open-source software licensed under the Apache License 2.0.
The MVP targets:
- macOS;
- Windows;
- Linux.
The proposed application stack is:
- Electron
- TypeScript
- React
- Vite
- Electron Forge
- SQLite
- Drizzle ORM
- better-sqlite3
The renderer must never access SQLite or Node.js APIs directly.
All privileged operations are executed by the Electron main process and exposed to the renderer through a restricted preload API.
product/prd.md
Defines:
- problem;
- product goals;
- MVP scope;
- functional requirements;
- non-functional requirements;
- product behavior.
product/ux-design.md
Defines:
- application structure;
- screens;
- states;
- interaction patterns;
- timer behavior;
- task history behavior.
domain/data-model.md
Defines:
- domain entities;
- SQLite schema;
- relationships;
- invariants;
- time calculation rules.
architecture/architecture.md
Defines:
- application architecture;
- Electron process boundaries;
- persistence strategy;
- IPC;
- security;
- packaging;
- testing strategy.
roadmap/roadmap.md
Defines the recommended order in which the MVP should be developed.
Each feature is implemented from an individual specification under:
docs/specs/
Each implementation-ready specification also has a companion tasks.md that breaks
the specification into small, dependency-ordered, independently verifiable tasks.
The specification remains the source of truth for behavior.
The first feature is:
docs/specs/001-core-time-tracking/spec.md
Starting or switching work should normally require one click.
Task totals are derived from recorded intervals.
Accumulated duration should not be stored as a mutable counter.
A task may be worked on across many days.
Starting an existing task creates another interval instead of duplicating the task.
History is grouped by day for usability.
Tasks themselves are independent of calendar days.
All task and tracking data is stored locally in SQLite.
No account or network connection is required.
The application must calculate elapsed time from timestamps.
The UI timer is only a representation of persisted timestamps.
The MVP does not include:
- accounts;
- synchronization;
- teams;
- clients;
- billing;
- invoices;
- projects;
- tags;
- productivity scoring;
- cloud backup;
- automatic idle detection.
These features may be evaluated after the core workflow has been validated.