How to Build a Time Tracking App Without Code, Step by Step
To build a time tracking app without code, describe what one tracked entry contains, how it gets started and stopped, and what report you need at the end of the month. Zugo generates the app, boots it in a sandbox before delivery, and publishes it live. A three screen version bills as a platform at 12 credits.
Time trackers are abandoned for one reason: logging an hour takes longer than the hour felt like it was worth. Every decision below is downstream of making that one action fast.
What does one time entry need to contain?
Four objects cover almost every use, and naming them before you build saves the expensive kind of change later, the kind that happens after real hours are recorded.
- Entry. Start time, end time or duration, description, the project it belongs to, and whether it is billable.
- Project. Name, client, hourly rate in US dollars, and whether it is active.
- Client. Name, contact, and the projects attached to it.
- User. Who logged the entry, if more than one person will use it.
The billable flag is the field people leave out and then rebuild. Internal admin, unpaid revisions and travel all take real hours you want visible in your totals but excluded from an invoice. One boolean does that, and adding it after two months of data means backfilling every row.
Rounding is the other decision to make in advance. Some people bill in six minute increments, some to the quarter hour, some to the exact minute. Say which in the prompt, because the default will be exact minutes and your invoices may not match your contract.
Should time be a running timer or a manual entry?
Build both, but decide which is the primary one, because it determines the shape of the main screen.
| Input method | Best for | The failure mode |
|---|---|---|
| Running timer, start and stop | Focused work in one block at a desk | You forget to stop it and lose the evening to a 9 hour entry |
| Manual entry after the fact | People who batch their logging daily | Guessed durations, and days that go unlogged entirely |
| Duration typed into today's row | Consultants who think in half hours | Less precise, but almost never skipped |
| Start time and end time typed in | Anyone reconstructing yesterday | More typing, and the case a timer cannot cover |
The pragmatic combination is a big start button on the main screen plus an "add entry manually" option next to it, and the ability to edit any entry's times afterwards. That last part is not optional. Every tracker needs a way to fix the timer you left running overnight.
Ask explicitly for a running timer to survive a page refresh. A timer that resets when the browser reloads is the single most common defect in a first build, and it makes the app untrustworthy immediately.
What should the build prompt say?
Precision about the main screen matters more than a list of features. Describe the one action you do twenty times a day.
A time tracking app for [solo work / a team of N].
Objects:
- Clients: name, contact email
- Projects: name, client, hourly rate in US dollars, active or archived
- Entries: start, end, duration, description, project, billable yes/no, user
Main screen: a project picker, a description box, and a large start button.
While running, show the elapsed time and a stop button. The timer must
survive a page refresh. Below it, today's entries with durations and a
day total, each editable.
Second screen: a week view, entries grouped by day, with a weekly total
and a separate billable total.
Third screen: a report filtered by client, project and date range,
showing hours, billable hours, and the amount at the project rate.
Round durations to [the nearest minute / 6 minutes / 15 minutes].
Currency is US dollars. Dates as YYYY-MM-DD.
The report screen is what turns a stopwatch into a business tool. Without it you have a log; with it you have the number you put on an invoice. General prompt structure is covered in how to build an app with AI.
Where should the tracked hours live?
In a real database, and this is less negotiable for a time tracker than for most small apps. Hours are money, and browser storage is one cleared cache away from an unbillable month.
Connecting Supabase gives the app Postgres storage plus logins under your own account. Start a timer on your laptop, and the entry is there when you open the app on your phone. For a team, each person gets an account and you decide who can see whose hours.
That decision deserves a deliberate pass. Can a team member see other people's entries? Can they edit them? Who can delete? Write the answers into the prompt, then log in as a second user and try to do the thing that should be blocked. Any app holding billing data earns that five minutes.
How do you turn tracked hours into an invoice?
Through the report, and the honest answer is that the app should stop one step short of being an invoicing system. Filter by client and date range, get hours and the amount, and carry those two numbers into whatever you already bill with.
If you want the invoice itself generated, that is a second project rather than a feature. The structure is in how to build an invoicing app, and it has its own concerns: numbering, tax lines, payment status, and a PDF a client will accept.
One useful middle ground costs a single edit. Ask for a "copy summary" button on the report that produces the line items as text: project name, hours, rate, amount. Paste that into your existing invoice and you have removed the retyping without building a second product.
What does a time tracker cost in credits?
Zugo bills per action. A one screen build is 6 credits, a multi screen app bills as a platform at 12 credits for the first three pages plus 3 for each additional page, and an edit is 3 credits.
| Build | Screens | Credits |
|---|---|---|
| Single screen timer with today's entries | 1 | 6 |
| Timer, week view, report | 3 | 12 |
| The above plus clients and projects management | 5 | 18 |
| Add a per user permissions layer | n/a | 3 per edit |
| Change the rounding rule or add a field | n/a | 3 |
Hi-Fi mode doubles those numbers, at 12 for a build and 6 for an edit. An internal tool rarely needs it. Free gives 5 credits, which is under the cost of one build. Pro is $25 a month for 200 credits, which is where an iteration cycle actually lives, and Business is $99 a month. The pricing guide breaks it down.
How do you check the totals are right?
Test the arithmetic by hand before you bill anyone from it. Log a 90 minute entry and a 30 minute entry on the same project and confirm the day total reads two hours, and the amount matches the rate you set.
Then test the four cases that break trackers. An entry that crosses midnight. A timer started, refreshed, and stopped. A non-billable entry that should appear in hours but not in the amount. And a week report at a month boundary, where the last day is included or excluded depending on how the range was written. That last one silently costs people a day of billing every month.
Sandbox verification means a build that failed to open is never handed to you. It does not check that your rounding rule matches your contract, which stays a human job and takes ten minutes.
What will an AI builder not do for time tracking?
Four limits worth stating before you switch off your current tool.
No automatic activity capture. Trackers that watch which app you have open, take screenshots or detect idle time need to run natively on the machine. A browser app records what you tell it.
No accounting integrations. There is no connector into QuickBooks, Xero or similar. Exports and manual entry cover the gap.
No mobile push reminders. A nudge at 18:00 to log your day is not something a web build delivers reliably across phones. Resend can send a daily email instead, which works if you read email.
Complex billing rules take edits. Different rates per person per project, overtime multipliers, retainer drawdowns and approval workflows are all reachable, one rule at a time, not in a single prompt. On a product a company depends on, Zugo gets you a working internal tool quickly and does not replace the team that owns it long term.
What is the first version worth building?
One screen: pick a project, type a description, press start. Today's entries below it with a total. That is 6 credits, and if you use it for a week the missing fields will name themselves more accurately than any specification you write in advance.
Then add the report, because that is the screen that pays for the app. Start with your real project list rather than test data at zugo.dev, and log tomorrow's hours in it before you decide what else it needs.