[2026]
Quote-to-cash invoicing for small businesses — quotes, invoices, payments and delivery, in strict monochrome.
01 — What it is
Bepari takes a small business from a quote to money in the bank: customers, catalogue, quotes, invoices, payments, and the paperwork in between.
A quote goes out. The client says yes. Somebody retypes the whole thing as an invoice, gets one line wrong, emails a PDF, and then spends a month working out who has actually paid. That loop is the entire product.
In Bepari a quote converts into an invoice without retyping. Payments are recorded against invoices, partial ones included. Status is worked out from the numbers rather than set by hand. PDFs and emails go out from inside the app, and a client can open their invoice through a private link without an account.

02 — Why it matters
Small businesses don't usually fail at selling. They fail at collecting. The gap between work delivered and money received is where cash disappears, and the tools that close that gap are either spreadsheets that quietly lie or accounting suites that need a week of training.
The bet here is that most businesses need one clean line — quote, invoice, payment — done properly, and nothing else. No modules to configure. Open it and send an invoice.
03 — Planning
The design rules were written before the schema, and I didn't break them once.
Strictly monochrome. No colour anywhere, including status — an overdue invoice says 'overdue', it doesn't glow red. Components come from one library and nowhere else. Money is set in tabular numerals so columns line up down the page. The reasoning is simple: financial documents are read, not admired, and colour-coded status is the first thing that becomes wrong when the rules change.
The build was seven phases: auth and schema first, then master data (customers, products, tax and currency settings), then quotes, then invoices, then payments, then PDF and email delivery, then notifications, dashboard and settings. Each phase had to be usable on its own before the next one started.
Left out of v1: multi-user teams, inventory, recurring invoices, and any kind of accounting ledger. Bepari is the front half of the money flow, and I wanted the front half to be unambiguous rather than the whole thing to be approximate.
04 — Building it
Money is stored as a fixed-precision decimal, never a float, and rounded once per line rather than at the end — so what the client sees on the PDF is exactly what the totals sum to. Floating-point money is one of those bugs that only shows up in front of a customer.
Invoice status is derived, not stored. Paid, partially paid, overdue and open all fall out of the amounts and the due date at read time. There is no status column to drift out of sync with reality, and no background job needed to flip an invoice to overdue at midnight.
Line items are immutable snapshots. When you add a product to an invoice, its name, price and tax rate are copied onto the line. Raising a price next quarter does not silently rewrite last quarter's invoices — a mistake that's easy to make with foreign keys and impossible to notice until an audit.
Client-facing share links sit behind long unguessable tokens on a narrow read-only path that can return exactly one invoice and nothing else. No login, no account, no way to walk the URL to someone else's document.
PDF generation and email delivery were the fiddliest part. Getting a PDF that looks right at A4, with the same monochrome type as the app, and that renders identically whether it's downloaded or attached, took more iterations than the invoicing logic did.
What shipped: the full quote → invoice → payment path, master data, PDF and email delivery, notifications and the dashboard.
What's still open: recurring invoices, multi-user access, and a reporting view that goes beyond the dashboard tiles.
The thing I'd carry into any money-handling product: decide what is stored and what is derived on day one, and never store something you can compute.