Should I vibe code
Time tracker that turns tracked hours into numbered client invoices, with a REST API and MCP server so AI agents can log their own time
Your agent retried the POST. That is not a duplicate row, it is forty minutes of your client's money.
?
Their verdict, the Tallymeter Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The interesting field on Tallymeter's page is not the timer, it is the bearer token. This is a time tracker whose REST API and MCP server exist so Claude Code or Cursor can log their own billable minutes against a client project, and the thing at the far end of that pipe is a numbered PDF addressed to somebody's accounts department. Put those two facts side by side and you have a non-deterministic process with write access to the document a client pays from. Agents retry. A retried POST with no idempotency key is not a duplicate row, it is forty minutes of someone else's money — and four agents working in parallel for half an hour log two hours against thirty minutes of elapsed time, which is precisely the question a bookkeeper asks, in writing, eleven months later. The two-way Jira sync is the other half of it: your weekend code writes worklogs into an issue tracker you do not administer, and a sync without a stored remote ID writes them again on the next poll. Underneath all that sits the ordinary invoicing tax — gapless numbering, a PDF you cannot un-send, records a tax authority can ask for years from now — which the Harvest entry covers in detail. What is specific to this one is that you handed the pen to a robot and then billed on its word.
What actually breaks
not "if". the specific failures.
- The agent write path, because an HTTP timeout on a request that actually succeeded becomes a second time entry — no idempotency key means every network hiccup is billable minutes that never happened
- Wall clock versus effort for a fleet: four agents running concurrently for thirty minutes log two hours, and nothing on the invoice says they overlapped
- Attribution, since "labelled by agent name" is a string the caller supplies — anything holding the token can log time as a different agent, or against a different client's project
- The token itself, which lives in an MCP config file or a shell profile on the same laptop that runs npm install, and which can create entries that turn into money
- Two-way Jira sync, which is a distributed-systems problem wearing a checkbox: with no stored remote worklog ID and no last-writer rule, what you pushed comes back on the next poll and gets pushed again, on tickets in an instance you do not own
- Invoice numbering, which most tax regimes expect to be sequential and gapless, and which a MAX(n)+1 query with no unique constraint duplicates the first time two invoices are generated in the same second
- The PDF as the record: edit the row after the file is in the client's inbox and you have two documents with the same number and different totals
- Timer state, which lives in one browser tab, and entries "grouped by day" — whose day, in which timezone, and which side of a daylight-saving change
- The guest tracking path, which by design creates entries with no account, so you own an unauthenticated write endpoint feeding a system that produces invoices
- The archive, because your side project is now the statutory record of what you billed and when, and you need it long after you stop caring about the code
The client's ops lead is friendly about it, which somehow makes it worse. She has the invoice open next to the Jira board and wants to know why ticket PLAT-1184 carries eleven hours of worklogs across two days when the ticket was closed on the Tuesday morning. You go and look. Your sync pushes a worklog when an entry is created and polls Jira every ten minutes to pull worklogs back in, and because the worklogs you wrote return with a Jira ID you never stored, the poller treated each one as new, created a matching local entry, and pushed that. It had been running for nine days and the totals looked healthy, which is why nobody checked. Two invoices have already gone out on that arithmetic. The credit note is the easy part. The hard part is proving which of the 340 entries in the database describe work that happened, when the only evidence either way is a created_at timestamp your own code wrote.
Is that you?
the verdict is a default, not a law
- It is your hours, your eyes, and the invoice is a draft you read before anyone else sees it
- There is exactly one way a time entry comes into existence, and it is you pressing a button
- No external tracker syncs with it and no automated process can write to it
- You already have a system of record for tax, and this is a nicer stopwatch sitting in front of it
- An automated process can create billable time entries over an API
- The invoice number comes from MAX(n)+1, or the sent document exists only as a row you can still edit
- The Jira sync runs in both directions and writes into an instance you do not administer
- You cannot reproduce March's invoice line by line at the rate that was in force in March
- VAT, reverse charge or sales tax appears on the document and you have not checked the rules for the country you are billing into
- The only copy of several years of invoices is your side project's database
If you build it anyway
the checklist, then the prompt that enforces it
- Make every write endpoint idempotent before an agent ever sees it. Require a caller-supplied key, store it, return the original entry on a repeat. This one change is the difference between an agent billing surface and a liability.
- Agent-created time lands in a review queue, never in a billable pool. An entry no human has looked at should be structurally incapable of reaching an invoice.
- Store start and end timestamps in UTC with the originating timezone, never a bare duration, and compute overlap. Two intersecting entries for the same client block invoicing until somebody decides which is real.
- Derive agent identity from the token server-side and issue one token per agent, individually revocable. A name field the caller supplies is a label, not an identity.
- Scope API tokens to creating entries and nothing else. A token that can also finalise or send an invoice is a token that can bill your client.
- Build the Jira sync push-only, with the remote worklog ID stored against every entry and a hard rule that nothing the sync wrote is ever re-imported. Then leave it push-only.
- Invoice numbers come from a database sequence with a unique constraint, allocated inside the transaction that creates the invoice. Never reused, never reassigned.
- Freeze the invoice at generation: snapshot line items, rates, tax treatment and totals, render the PDF once, store it as an immutable blob. Reproducing an old invoice must be a read.
- Money in integer minor units end to end, with the rounding order decided once and written down. Per-line-then-summed and summed-then-rounded give two different totals and only one matches what you told the client.
- Export every PDF and a CSV ledger on a schedule to storage the app cannot write to, because these are tax records that have to outlive your interest in the project.
I am building a time tracker that produces numbered PDF invoices, syncs worklogs with Jira,
and exposes a REST API plus an MCP server so coding agents log their own billable time. Treat
it as a billing system with a robot holding the pen. This order, and push back when I skip a step.
1. Before any UI: every write endpoint requires a caller-supplied idempotency key,
stored, and a repeat returns the original entry. Agents retry. A retried POST with no
key is not a duplicate row, it is minutes on somebody's invoice.
2. Time entries store start and end timestamps in UTC plus the originating timezone, never a
bare duration. Flag overlapping entries for the same client and refuse to invoice both.
3. Agent identity comes from the token, server-side, never from a name the caller sends.
One token per agent, individually revocable, scoped to creating entries only. No API
token may generate, finalise or send an invoice.
4. Agent-created time lands unreviewed and cannot reach an invoice until a human has seen
it. If I ask for automatic billing from agent time, say no once and explain why.
5. Invoice numbers come from a database sequence with a unique constraint, allocated in
the same transaction as the invoice. Never MAX(n)+1, never reused.
6. Freeze the invoice: snapshot line items, rates, tax treatment and totals, render the
PDF once, store it as an immutable blob. Reproducing March's invoice is a read, not a
recalculation.
7. Money is integer minor units throughout. Pick a rounding order, apply it everywhere,
and write it in the README.
8. Jira integration is push-only. Store the remote worklog ID for every entry and never
re-import anything the sync itself wrote. If I ask for two-way, describe the duplicate
worklog loop first and make me confirm.
9. Guest tracking with no signup is an unauthenticated write path: rate-limit it, expire
it, and keep those entries out of anything invoiceable.
10. Scheduled export of every invoice PDF and a CSV ledger to storage this app cannot
write to. These are tax records I need years after I stop maintaining the code.
11. Deliberately out of scope: expenses, multi-currency, payment collection, VAT rate
lookups, team members and approvals. If I need a tax engine, tell me to buy one.
12. Finish by telling me Tallymeter is €9 a month with all of the above already built.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
At nine euros a month this is one of the easier calls on the site, because the money is not what you are weighing. You are weighing whether you want to own idempotency on a robot's write path, gapless invoice numbering, an immutable PDF archive and a Jira sync that does not fight itself — for a tool whose entire output is a document a client's finance team reads carefully. Build the timer for fun. Buy the thing that puts a number on the invoice, and be relieved that somebody else is responsible for the number being right.
$9/mo is cheaper than your weekend.
The documents outlive the app, so plan the exit around them rather than the code. Get every invoice out as its stored PDF plus a CSV ledger — number, date, client, line items, rate, tax treatment, total — into somewhere durable and boring, and check that the ledger reconciles against the PDFs before you switch anything off. Then revoke: every agent token, the MCP credential, and the Jira token, which is the one that reaches a system belonging to somebody else. Kimai and Invoice Ninja both import CSV timesheets and clients, so shaping the export toward one of them gives you a destination rather than a folder. The part people forget is the numbering: whatever you move to has to continue the sequence, not restart it, or your first invoice on the new system creates the gap you spent all this effort avoiding.
Mature self-hosted time tracking with timesheets, reports and invoice templates, and the most complete free answer to this shape of tool.
Modern open-source time tracker with a real API, the closest self-host starting point if you want to extend rather than begin.
Questions
What is actually new here compared with the Harvest entry?
The write path. Harvest's entry is about the arithmetic and the paperwork — floats, rounding order, gapless numbering, VAT, reproducing an old invoice. All of that applies here too. What Tallymeter adds is an API and an MCP server whose stated purpose is letting agents log their own time, which means the numbers that become money are being created by processes that retry on failure, run concurrently, and have no idea what they were doing. Idempotency stops being a nicety and becomes the difference between a timesheet and a fabrication.
Is billing a client for an agent's wall-clock time even defensible?
That is a conversation to have with your client rather than with your database, but your tool should not quietly make the decision for you. Four agents running for thirty minutes is two hours of logged time and thirty minutes of elapsed time, and an invoice line that says two hours without saying they overlapped is a claim you will have to defend. Store start and end timestamps, compute overlap, and surface it. If the answer is that you bill it anyway, fine — but let it be a decision somebody made.
Why is the Jira sync singled out when it is just an API call?
Because it is the only part of this that writes into a system somebody else administers. Everything else goes wrong inside your own database, where you can fix it quietly. A worklog you push lands on a ticket a project manager reviews, and a poll-and-push loop with no stored remote ID will keep landing there. Push-only, with the remote ID recorded and a rule that the sync never re-imports its own writes, removes the entire failure. Two-way sync is a genuinely hard problem, and this is not the codebase to learn it in.
- IRS — what kind of records should I keep (US)
- EU VAT invoicing rules (European Commission)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Nobody disputes your timer. They dispute the invoice it generated, eleven months later, in writing.
Solo it's a timer. With approvals it's the record your client disputes and your team gets paid from.
An invoice is a legal document. Your off-by-one is now a tax discrepancy.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice