Should I vibe code
Invoicing, quotes, payments, expenses, and client portal software
An invoice is a legal document. Your off-by-one is now a tax discrepancy.
?
Their verdict, the Pro 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
Generating a PDF is easy and generating a correct one is not. Sequential numbering, tax rules, currency rounding and multi-year retention are requirements, not polish.
What actually breaks
not "if". the specific failures.
- The client portal, which is authentication you wrote, guarding other companies' financial documents
- A portal link emailed as a permanent unguessable URL, which is a password that never expires and gets forwarded
- Currency conversion, where the rate on the invoice date, the payment date and the reconciliation date are three different numbers
- Rounding applied per line rather than per total, so the PDF and the payment differ by a few cents forever
- Multi-year retention, on a database whose backups you have never restored
A client forwards their invoice link to their bookkeeper, who forwards it to someone at their accountant's office. The link is a long random string with no expiry and no login, because that was the frictionless design and clients loved it. Nine months later you realise those URLs were indexed — one client's portal page was linked from a public help thread — and the pages show line items, rates and payment history for a business that is not yours. Nobody has done anything wrong except you, once, at the design stage.
Is that you?
the verdict is a default, not a law
- It generates draft PDFs and a real system issues, numbers and stores them
- There is no client portal — invoices are attachments you email
- One currency, one jurisdiction, and you are the only user
- Clients log into anything you built to see their financial records
- Portal access is an unguessable URL rather than an authenticated session
- You invoice in more than one currency
- You have never restored the backup
If you build it anyway
the checklist, then the prompt that enforces it
- The client portal is real authentication with expiring sessions. A long random URL is a password that cannot be revoked and will be forwarded.
- Store money as integer minor units, and store the currency and the FX rate used with its date on every document.
- Round once, at the total, using a stated rule — and use the same rule in the PDF, the portal and the payment request.
- Set noindex and no-store headers on every portal page, and never expose a document without a session.
- Test a full restore from backup before you invoice anyone, and repeat it on a schedule. Retention is only real if the restore works.
- Issued invoices are immutable; corrections are credit notes. Keep a copy of every generated PDF as a file.
Before you build invoicing with a client portal, apply these and push back if I ask you to break them.
1. Ask me how clients will see their invoices. If the answer is an unguessable
link, refuse and explain that it is a non-expiring password that gets
forwarded to bookkeepers and accountants and can end up indexed. Build
authenticated sessions with expiry instead.
2. Set noindex, nofollow and no-store on every portal page, and require a
session for every document fetch including PDFs.
3. Represent money as integers in minor units. Never floats.
4. Ask me whether I invoice in more than one currency. If yes, store the
currency and the exchange rate with its date on the document itself, and
tell me the invoice date, payment date and reconciliation date will use
three different rates.
5. Round exactly once, at the total, with a documented rule. Use the identical
calculation for the PDF, the portal display and the payment request — a
two-cent difference between them is a support conversation forever.
6. Issued invoices are immutable. No edit, no delete. Corrections are credit
notes. Store the generated PDF as a file at issue time and serve that file,
never a re-render.
7. Allocate invoice numbers from a gapless sequence inside the committing
transaction.
8. Before I send a single invoice, walk me through restoring the database from
backup and confirm the restore works. Tell me retention obligations here are
measured in years.
9. Never handle card data directly — hosted checkout only.
10. Ask which country's rules apply and write the retention period into the
README.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
As soon as clients need to see anything. $14 a month is genuinely cheap for authenticated portals, currency handling and immutability — and Invoice Ninja is open source, so self-hosting the real thing gives you the control you wanted without writing the auth that guards someone else's books.
$14/mo is cheaper than your weekend.
Keep every issued PDF as a file alongside exportable rows, so the documents survive independently of the application and the database schema. Verify a restore before you rely on it, and export to a format your accountant already accepts — retention obligations here outlast most side projects by several years.
The product's own open-source invoicing platform.
Questions
Clients hate logging in. Isn't a magic link the friendly option?
A magic link is fine if it expires and exchanges itself for a session. The failure here is the permanent link that is itself the credential — it gets forwarded through several inboxes, cannot be revoked without breaking the client's bookmark, and shows financial records to whoever ends up holding it.
How is this different from the FreshBooks entry?
FreshBooks is about the records themselves — immutability, numbering, tax dates. This one adds a portal, which means you are also running authentication that guards other companies' financial documents, and multi-currency, where rounding and rate dates create discrepancies that are nobody's bug and everybody's problem.
- 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