Maxio

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Think hard before replacing a billing and revenue platform. **The reason companies pay this much is that the numbers go in front of auditors and investors.**

What the paid product is really selling:
- Revenue recognition under the accounting standards — invoiced and earned are different, and a multi-year contract paid up front is recognised monthly. Getting this wrong is a restatement
- Usage-based billing where the meter, the rating and the invoice must reconcile exactly
- SaaS metrics — recurring revenue, expansion, contraction, churn — computed the same way every month. **A metric computed differently after a change is a broken series**, and this is exactly what an investor will notice

If your contracts are simple and your metrics are internal, the buildable version below is honest.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A payment processor for cards
- Caddy in front

THE LEDGER, WHICH IS EVERYTHING
- ledger: id, account_id, subscription_id, kind, amount_cents, currency, occurred_at, recognised_from, recognised_to, description, ref
- **Append-only. Every invoice, every metric and every report is derived from it.** Never store a balance, never store a monthly revenue total
- kind covers charge, credit, payment, refund, adjustment. Nothing is ever edited; a mistake is a new row that corrects it
- recognised_from and recognised_to on every charge is what makes recognition a query rather than a project

USAGE BILLING
- usage_events: id, subscription_id, meter, quantity, at, idempotency_key — **raw events, kept forever**
- Rate at invoice time from the raw events, never from a running total. A running total that drifts cannot be reconciled with anything
- The invoice shows the quantity and the rating, so a customer disputing it can be answered from the same rows

METRICS, COMPUTED ONE WAY
- Recurring revenue, expansion, contraction and churn as SQL over the ledger, at query time
- **Write the definition down beside the query and version it.** The most common failure here is not a bug, it is two people meaning different things by 'churn'
- Never store an aggregate table. A recomputed history that disagrees with a stored one is a very bad meeting

THE RULES
- Money in integer minor units, currency on every row, and the exchange rate stored per day where conversion is needed
- Payment truth comes from verified processor webhooks, processed idempotently
- Invoices never edited; corrections are credit notes
- Everything an accountant sees exports as CSV with the ledger rows behind it

WHAT MATTERS MOST
An append-only ledger with recognition dates on every charge, and metric definitions in version control. That is the structure that keeps the numbers defensible, which is the only thing this category is actually selling.