Projects & tasks
Projects are how you organize work in TimerOS — and how tracked time, budgets, and client visibility all come together. Every plan can create and organize work into projects, tasks, and subtasks; what scales by tier is team-level visibility and roles, not the task structure itself.
On the desktop and web apps you’ll find projects under the Projects view (with a detail page per project) and a dedicated Tasks view, both available on every plan. Projects are also one of the surfaces your clients can see in the client portal, where they browse active work, respond to proposals, and follow milestone, budget, and file activity.
Structure: projects, tasks, subtasks, milestones
Inside a project you can break work down into milestones, tasks, and subtasks. In the client portal, a project opens into a five-tab view that mirrors this structure:
- Overview — status timeline, KPIs for progress, milestones, budget, and days remaining, plus an activity log.
- Milestones / Structure — milestones, tasks, and subtasks (the tab reads “Structure” for proposals and “Milestones” for active projects).
- Budget — client budget total, resource allocations, budget phases, and payment milestones.
- Discussion — threaded notes the client can post and reply to, one level deep.
- Files — a folder hierarchy with upload, download, rename, delete, and move.
Budgets & burn-rate
Each project tracks a client budget total alongside resource allocations, budget phases, and payment milestones. Progress and budget KPIs surface on the project Overview so you can see how work is burning down against what was planned.
Tracked time
Time is captured by the desktop timer bar — the only surface that tracks time — and attributed per day per user as an hours-of-day map; it is not linked to a specific task. A task or subtask’s “actual hours” is entered on the task itself, and that is what drives budget burn-down. Performance breakdowns are computed server-side from the tracked-time data and shown on the Performance page. For how each second is classified, see activity classification and time states.
Visibility & membership
Project access follows your workspace roles and permissions. In the client portal, contacts only see modules they’ve been granted, and requesting a project needs edit permission on projects while approving proposals needs the dedicated approval permission.
Some deeper project capabilities are surfaced inside the desktop and web apps, with the server and the client portal doing the heavier lifting. If a specific workflow you need isn’t here yet, check the roadmap.