How to Build a Time Tracking App: Timers, Timesheets and Reports

How to build a time tracking app: projects, timers and manual entries, rounding, approvals, billable hours, reports, and when an existing tracker wins.

Mythex Team · 2026-09-29 · 6 min read

A time tracking app records who worked on what, for how long, and whether that time can be billed. To build one you need clients and projects to track against, a timer that survives a closed browser tab, a way to add and correct entries by hand, a weekly timesheet, and reports that turn raw entries into totals. An AI app builder can produce a working first version from one clear prompt. The decisions that matter are about rules: rounding, who can edit what, when a week is locked, and what counts as billable.

Decide what you are tracking time for

The same app looks different depending on the reason behind it:

Billing clients. Hours per client, a rate per person or project, and a clean export for invoices. Accuracy and an audit trail matter most.
Payroll for hourly staff. Clock-in and clock-out, breaks, overtime rules, and a manager sign-off. Local labour rules apply, so check what records you are required to keep.
Understanding where time goes. Personal or team insight, estimates versus actuals. Speed of entry matters more than approval flows.

Pick one as the main job for version one. A freelancer's billing tracker and a shift clock for a warehouse share a timer and very little else.

What the app needs

Data

Table	Key fields
Clients	Name, default hourly rate, active yes/no
Projects	Client, name, budget in hours (optional), billable by default yes/no
Tasks or categories	Project, name (design, meetings, support) — optional at first
Time entries	Person, project, task, start time, end time, duration, note, billable yes/no, status (draft, submitted, approved), invoiced yes/no
People	Name, email, role, cost rate or bill rate

Store the start and end time on every entry and derive the duration from them. Entries typed in as "2h 15m" with no times can store the duration alone, but keep a date.

Permissions

Write down who can do what before you build:

People see and edit their own entries.
Managers see their team's entries and approve weeks.
Only admins change rates, and ideally only admins see them at all.
Nobody edits an entry once it has been approved or invoiced, unless an admin reopens it.

That last rule is what makes the reports trustworthy. Our guide to adding login to your app covers the sign-in side, and role-based access control covers the roles.

Decisions and trade-offs

Timer, manual entry, or both

Timers are accurate when people remember to start them, which is not always. Manual entry is fast for people who fill in their week on Friday. Most teams need both, and a way to edit a timer entry after the fact. If you only build one, build the week grid; it is simpler and covers the forgot-to-start case.

Where the running timer lives

A timer that counts in the browser loses everything when the tab closes. Save the start time to the database when someone presses start, and show the elapsed time by subtracting that from now. The timer then keeps running across refreshes, laptops and phones. Decide whether one person can run two timers at once. Usually the answer is no: starting a new one stops the old one.

Rounding

Common rules are rounding each entry up to the nearest 6, 15 or 30 minutes. Keep exact times in the database and apply rounding only in reports and invoices. Show both numbers in reports so nobody is surprised.

Locking and approvals

Without a lock, last month's billed hours can change after the invoice has gone out. A simple model: people submit a week, a manager approves it, and approved entries become read-only. If you invoice from the app, mark entries as invoiced so they cannot be billed twice.

Time zones and midnight

Store times in UTC and display them in the person's time zone. Decide which day an entry that runs from 23:00 to 01:00 belongs to. The usual answer is the day it started.

A first prompt that works

Build a time tracking app for a six-person design studio. Data: clients (name, hourly rate), projects (client, name, budget hours), and time entries (person, project, start, end, note, billable yes/no, status draft/submitted/approved). Pages: a Today page with a start/stop timer and project picker that saves the start time to the database so the timer survives a refresh; a Week page with projects as rows, Monday to Sunday as columns, where people can type hours directly; a Reports page showing hours per client, project and person for a date range, split into billable and non-billable, with CSV export; and an Admin page for clients, projects and people. Only one timer can run per person. Approved entries cannot be edited. Store times in UTC and show them in the user's time zone. Clean, fast, keyboard-friendly design.

It names the tables, the pages, the timer behaviour and the lock rule, which are the things an AI would otherwise guess.

Build steps

Projects and manual entries first. Clients, projects, a form to add an entry, and a list. Make sure totals add up.
Timer. Start, stop, one running timer per person, saved start time. Test by starting a timer, closing the tab and reopening it.
Week grid. Typing hours into a cell creates or updates an entry.
Login and roles. Add them before real people use it, so nobody sees rates or other people's entries by accident.
Submit and approve. Weekly submission, manager approval, read-only after approval.
Reports and export. Date range, grouping, billable split, CSV.
Rates and invoicing hooks if you bill clients. Keep invoice creation in a separate step or app; see how to build an invoicing app.
Test the edge cases. An entry across midnight, a daylight-saving week, two timers started from two devices, editing an approved entry.

Common mistakes

Counting time in the browser only. It works in the demo and loses hours in real use.
Rounding stored values. You can never get the exact time back.
No lock on approved weeks. Reports stop matching invoices.
Everyone sees everyone's rates. Hide rates by role from day one.
Too many required fields. If logging time takes more than a few seconds, people stop doing it, and the data becomes fiction. Make task and note optional at first.
Building a full project manager inside the tracker. Keep projects as simple labels. If you need tasks, boards and deadlines, that is a project management tool, a separate build.

When an off-the-shelf tracker is the better choice

If your team needs a timer, a week view and reports, dedicated time tracking products already do this well. They also come with things that take real work to build: desktop and phone apps, idle detection, calendar and tool integrations, and reminders to fill in timesheets. For hourly payroll, a tool built for it will handle breaks, overtime and record keeping more safely than a first-version custom app.

Build your own when your rules do not fit, when you want hours connected to data you already keep (jobs, work orders, retainers, invoices), when per-seat pricing across a large team adds up, or when time tracking is one part of a bigger internal tool. Our guide on building vs buying software walks through the trade-off, and if your hours currently live in a shared sheet, see how to turn a spreadsheet into an app.

Building it with Mythex

On Mythex you describe the tracker in chat and the agent builds it in a live preview. It adds a dedicated Postgres database when entries need saving, and you can ask for that directly or type /database. The internal tool use case in the docs suggests picking one painful step for version one, which fits here: start with entries and the week grid, then add timers and approvals.

Sign-in for your team is something you add with your own auth approach (add login recipe). Mythex accounts are for the people building, not the people using your app. Once the core flow works, /test has the agent click through the preview (start a timer, add an entry, run a report) and report what breaks. For a visual starting point, browse the app templates.

Questions

What features does a time tracking app need?

A list of clients and projects, a start/stop timer, a way to add or fix entries by hand, a weekly timesheet view, and a report of hours per project and person. Approvals, billable rates and exports come next.

How do I stop a timer from losing time when the browser closes?

Save the start time to the database the moment the timer starts, and calculate the running duration from that saved time. Then closing the tab, refreshing or switching devices does not lose anything.

Should time be rounded?

Store the exact start and end times and apply rounding only in reports and invoices. That way you can change the rounding rule later without rewriting history.

Is it worth building my own time tracker?

Usually only if your rules are unusual or you want hours tied to other data you already keep, such as jobs, clients or invoices. For plain timers and reports, an existing tracker is cheaper and faster.