Should I vibe code
Track project time, turn approved entries into simple invoices, and export reports
Nobody disputes your timer. They dispute the invoice it generated, eleven months later, in writing.
?
Their verdict, the Teams 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
A timer, a project list and a rate field is a Saturday afternoon, and the agent will hand you a working one. What you have at that point is a spreadsheet with a stopwatch. Harvest is the three steps after: approved entries become line items, line items become an invoice with a number and a tax line, and that invoice becomes an amount somebody's finance department pays. Every joint in that chain is arithmetic performed on other people's money and stored in a document a tax authority can ask you to produce years later. Money kept in floats, a rate that changed in April applied retroactively to March, an invoice regenerated under a number you already sent — none of these crash anything. They produce quiet, plausible numbers that arrive by email and get paid.
What actually breaks
not "if". the specific failures.
- Money held as a floating-point number, so the invoice total disagrees with the sum of its own line items by a cent — which is exactly the kind of thing a bookkeeper notices and nobody else ever does
- Invoice numbering, which most tax regimes expect to be sequential and gap-free, and which a regenerate button quietly reuses
- An invoice edited after it was sent, leaving the PDF in the client's inbox and the row in your database as two different documents wearing the same number
- Time entries and daylight saving, where a session logged across the spring change is billed for an hour that did not exist
- Tax — the VAT line you did not add, the reverse charge you did not apply, the sales tax you collected and now owe to someone
- Rates, changed once and applied backwards to hours already approved, because nothing versioned the number that was in force at the time
- Rounding order: per-line then summed, or summed then rounded, gives two different totals and only one of them matches what you told the client
- The archive, which you have to be able to produce long after you have stopped using the app and lost interest in maintaining it
The email arrives on a Tuesday, politely, from a client's bookkeeper, with a spreadsheet attached. She has added up the line items on invoice 0148 and made it $4,312.50; the total printed at the bottom says $4,312.49. She has done this for eleven invoices going back to January and four of them disagree. The amounts are trivial. The implication is not, because her next question is whether the hours are right either — and that is when you discover you cannot reproduce the March invoice at all. The generator reads the project's current rate, the rate changed in April, and you never stored what the line items were at the moment the document went out. You are now reconstructing a year of billing from a database that only knows what is true today, for a client who has started keeping their own copy.
Is that you?
the verdict is a default, not a law
- You are the only person tracking time and the output is a CSV you paste into whatever actually invoices
- Nothing the app generates leaves your machine with an amount and a due date on it
- You bill fixed fees, so no client's total depends on your arithmetic
- The timer feeds a report you read, not a document someone pays
- The app produces the document a client pays from
- Colleagues log hours that their pay, or a client's bill, is derived from
- You cannot answer "show me invoice 0102 exactly as it was sent" with a stored file
- Sales tax or VAT appears anywhere on the output
- Anyone else can edit a time entry after it has been billed
If you build it anyway
the checklist, then the prompt that enforces it
- Store money as integers in minor units and durations as whole seconds. Round exactly once, at a point you have written down, and make the invoice total the sum of the rounded line items rather than the rounding of the sum.
- Invoices are immutable the moment they are issued. A correction is a new document — a credit note plus a replacement — never an edit under the same number.
- Snapshot everything into the invoice at issue time: rate, quantities, client address, tax rate, wording. A regenerated invoice must never read the current value of anything.
- Allocate numbers from one sequence that never gaps and never reuses, and write the test that runs the generator twice and asserts it did not.
- Keep the sent PDF as a file, not a template plus a promise. The document the client holds is the document that matters in a dispute.
- Store time in UTC with the originating zone recorded, and test an entry that crosses a daylight-saving boundary before you bill one.
- Do not compute tax. Either a flat, human-entered rate you can defend to an accountant, or a real integration — a homemade VAT engine is a liability you built for yourself.
- Decide the retention story in week one: readable exports that survive the app being deleted, for as long as your jurisdiction expects you to keep books.
I am building time tracking that generates invoices clients pay from. Treat
the invoice as an accounting record with legal weight, not as a report. The
timer is the easy part and comes last. Push back if I ask for these in the
other order.
1. Before any feature: decide the money representation. Integer minor units,
durations in whole seconds, one documented rounding point, and the total is
the sum of the rounded lines. No floats anywhere near currency.
2. Then invoice identity. Numbers come from a single gap-free sequence,
allocated once, never reused. Write the test that calls the generator twice
and asserts the second call did not reuse a number.
3. Then immutability. Once issued, an invoice is frozen: rate, quantities,
client details, tax rate and wording are copied onto it and nothing is read
live afterwards. Corrections are a credit note plus a new invoice.
4. Persist the rendered PDF at issue time and keep it. If any design you
propose re-renders a sent invoice from current data, say so out loud.
5. Then export: every invoice, payment and time entry as files a person can
read without the app running. That is the retention story, and it comes
before any UI work.
6. Store time in UTC with the originating timezone recorded, and include a test
for an entry spanning a daylight-saving change.
7. Version rates. Stamp each entry with the rate in force when it was logged,
and never apply a change backwards.
8. Do not implement tax calculation, VAT rules or reverse charge. Take a flat
rate as input or integrate something that owns the problem; if I ask you to
generate VAT logic, refuse and tell me why.
9. Payments link out to a hosted checkout, no card details reach my server, and
billed entries lock — later corrections are new adjusting entries.
10. Out of scope on purpose: payroll, currency conversion, and filing anything.
If I want those, say that paying for Harvest is the cheaper answer.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
The moment the app generates something a client pays. $11 per seat per month is less than the hour you will spend explaining a rounding discrepancy to a bookkeeper, and roughly nothing next to an invoice you cannot reproduce. If you want the timer and nothing else, keep the timer and let Harvest, an accountant or a hosted invoicing API own the document.
$11/mo is cheaper than your weekend.
Time entries and clients export as CSV without much trouble; the invoices are the part with an obligation attached, so keep them as issued PDFs plus a machine-readable ledger of number, date, client, lines, tax and payment status. Do that from the first invoice and migrating is an import. Do it later and you are reconstructing documents from a database that has been quietly overwriting the values those documents were built from.
Mature open-source time tracker with projects, rates, exports and invoice generation.
Self-hostable invoicing and payments platform that already owns numbering, tax lines and PDF archives.
Questions
Isn't this just Toggl with a PDF button?
The PDF button is the entire entry. A timer records something for you; an invoice asserts something to someone else and then gets paid. The first is a table you can fix quietly, the second is a document with a number on it that two parties and possibly a tax office now hold copies of.
I invoice three clients a month. Is that really regulated?
Volume is not what triggers it. One invoice still needs a number, the right mandatory fields, and to still exist when someone asks about it years from now. Small scale makes the consequences survivable, not absent — and it is small scale where nobody ever notices the arithmetic is wrong.
Can I build the tracking and let something else do the invoice?
Yes, and that is the recommendation. Hand approved time to Stripe Invoicing, a bookkeeping API or your accountant, and everything sharp in this entry — numbering, immutability, tax, retention — becomes somebody else's tested code. You keep the part that was fun to build.
- 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.
A timer and a table. If you bill from it, treat the table like an accounting record.
Solo it's a timer. With approvals it's the record your client disputes and your team gets paid from.
Your rounding bug is not a bug. It is a discrepancy on a filing with your name on it.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice