Should I vibe code
Invoicing, expenses, time tracking, payments, and accounting for small businesses
Your rounding bug is not a bug. It is a discrepancy on a filing with your name on it.
?
Their verdict, the Lite price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Invoicing you can survive. Once expenses, tax categories and payment reconciliation are in scope you are keeping statutory records, and “the AI wrote it” is not an accounting policy.
What actually breaks
not "if". the specific failures.
- An edit button on an issued invoice, which is the single most natural feature to build and the one accounting forbids
- Invoice numbers with gaps, because a failed insert consumed a sequence value — required to be gapless in much of the EU
- Money in floating point, so a hundred line items reconcile to a penny off and nobody can say which one
- Tax applied at today's rate rather than the rate on the invoice date, silently wrong for every historical document
- Records deleted on a whim that you were required to retain for years
Your accountant asks for invoice 0147 because the client's copy shows £2,400 and your books show £2,600. You remember now: they queried a line, you fixed it in the app, and it re-rendered. There is one row in your database and it holds the new number. The PDF in their inbox holds the old one. Nothing logged the change, because you wrote an UPDATE, and an UPDATE is what any reasonable developer writes. You are now reconstructing what you charged a client eight months ago from your own memory and their email archive.
Is that you?
the verdict is a default, not a law
- It reads your accounting system and produces reports, writing nothing back
- It drafts invoices that a real system issues, numbers and files
- You are the only client and the only jurisdiction is one you can recite from memory
- It issues the invoice of record, the one a client or an auditor will rely on
- It calculates or files sales tax, VAT or GST
- It reconciles against a bank feed or moves money
- You cannot say how long you are legally required to keep these records
If you build it anyway
the checklist, then the prompt that enforces it
- Issued documents are append-only. There is no edit and no delete — corrections happen by issuing a credit note. Build it this way from the first commit or not at all.
- Money is integer minor units, never a float. The type system should make a float impossible to pass in.
- Invoice numbers come from a gapless sequence allocated inside the same transaction that commits the invoice.
- Tax rates are stored with effective dates, and every calculation uses the rate as at the document date.
- Every state change is an event in an immutable log, with who and when. That log is the actual accounting record.
- Set an explicit retention period in the README, and make deletion require a deliberate, logged administrative action.
Before you write any code for invoicing or bookkeeping, apply these and push back if I ask you to break them.
1. Issued documents are immutable. Do not build an edit or a delete for an
invoice that has been sent. If I ask for one, refuse and explain that
corrections are made by issuing a credit note, and that an UPDATE on an
issued invoice destroys the record an auditor relies on.
2. Represent all money as integers in minor units. Never a float, never a
double. If a library hands you a float, convert at the boundary and say so.
3. Allocate invoice numbers from a gapless sequence inside the same database
transaction that commits the invoice. Tell me that several jurisdictions
require sequential numbering without gaps, so a failed insert must not burn
a number.
4. Store tax rates with effective-from and effective-to dates. Every
calculation uses the rate in force on the document date, never today's rate.
Never hardcode a rate.
5. Write every state change to an append-only event log with actor and
timestamp. Treat that log as the record and the current-state table as a
cache of it.
6. Do not touch card data. If payments are in scope, use Stripe Checkout or a
hosted equivalent so card numbers never reach my server.
7. Ask me which country's rules apply and state in the README how long records
must be retained there. Make deletion an explicit, logged admin action, not
a button in the UI.
8. Generate the PDF once, at issue time, and store that exact file. Never
re-render a historical document from current data.
9. Out of scope unless I say otherwise, and say so plainly: tax filing,
multi-currency revaluation, payroll, bank reconciliation.
10. Tell me that this is a statutory record, not an app, and that $23 a month
is cheap next to an afternoon with an accountant untangling it.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
Almost always, and sooner than you think. $23 a month buys immutability, gapless numbering, dated tax tables and retention defaults that were shaped by regulators rather than by a weekend. The build is not the hard part; being wrong about it is expensive in a way that involves your name on a filing.
$23/mo is cheaper than your weekend.
Export to a standard accounting interchange — CSV your accountant accepts, or better, the format your eventual real system imports — and run that import for real before a tax year closes inside your own tool. Also keep every issued PDF as a file on disk, because those are the documents that matter if the database ever becomes unreadable.
Open-source invoicing platform with payments, clients, and quotes.
Questions
Why can't I just edit an invoice before anyone notices?
Because the moment it was sent, a copy left your control. Accounting treats issued documents as immutable precisely so that your record and your client's record cannot silently diverge — and when they do, the burden of reconstructing the truth falls on you, months later, without a log.
Is drafting invoices and letting something else issue them a reasonable split?
Yes, and it is the SHIP IT version. Owning the drafting UI, your line-item library and your templates is genuinely useful and carries almost no risk. Let a real system own numbering, tax, immutability and retention — the parts where being wrong is a filing problem rather than a bug.
- IRS — what kind of records should I keep
- EU VAT invoicing rules
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice