One Billing Engine Under Every Product You Run

Build billing once and let every product plug into it. Subscriptions, plans, invoices, failed-payment retries, dunning, tax handling: none of it is product-specific, all of it is genuinely hard, and every piece is a place to lose money if you get it wrong. Building it per product means solving the same intricate, revenue-critical problem twenty times and being twenty times as likely to leak revenue through a bug in one of them. A shared billing engine is one of the highest-return pieces of a portfolio foundation, right alongside auth.

Why should billing be shared across products?

Because billing is complicated, universal, and unforgiving of mistakes. Think about what taking recurring money actually involves: plan definitions, proration when someone upgrades mid-cycle, retrying a card that failed, handling a dispute, sending the dunning emails, staying compliant with tax rules. Every product needs most of this, and none of it distinguishes one product from another. A customer never chose your product because its proration logic was elegant.

Solve it once, correctly, and every product inherits working billing. This is the same logic that makes standardizing auth, billing, and deploy once the backbone of a foundation. Billing sits next to auth as the two things I wire into a foundation before any product logic, because both are pure inherited value with real money on the line.

A shared engine also means one place to fix a billing bug. When you find that failed payments were not retrying correctly, you patch the billing engine and every product stops leaking that revenue at once. With per-product billing, the same bug is hiding in twenty implementations and you will not find all twenty until each one costs you.

What the shared billing engine should own

The engine owns the machinery of money. It does not own what each product charges for, which is the part that should diverge.

Shared in the engine:

• Subscription lifecycle: create, upgrade, downgrade, cancel, with proration handled once.
• Payment processing and retries: connecting to the processor, handling failures, retrying intelligently.
• Invoicing and receipts, generated the same way everywhere.
• Dunning, the failed-payment email sequence, run through one owned transactional email path so every product's billing emails actually deliver.
• Revenue events, emitted consistently so you can see money across the whole portfolio.

Per-product, diverging freely:

• What the plans are and what they cost.
• What each plan unlocks in the product.
• Usage metering, where a product bills on consumption specific to it.

The line is the same one that governs the whole foundation: the mechanism is shared, the product-specific meaning is not. This is where products should diverge applied to billing. The engine knows how to charge a card and run a subscription. Each product decides what it is selling.

One place to see the money

A shared billing engine gives you something a portfolio badly needs: a single view of revenue across every product. When billing runs through one engine that emits consistent revenue events, you can answer "how is the portfolio doing" without stitching together twenty separate payment dashboards.

Per-product billing scatters your financial picture across twenty places, each with its own data shape, and reconciling them is a job in itself. A shared engine makes the portfolio's finances legible from one seat, which matters enormously when one operator is running everything and cannot afford to lose track of which products make money. It also feeds clean numbers into bookkeeping instead of forcing you to normalize twenty different exports by hand.

Build it once, inherit it forever

The goal is the same as every other foundation piece: make billing a solved problem a new product inherits rather than builds. A new product should be able to take money on day one, with subscriptions, retries, and invoices already working, because it plugged into the shared engine instead of reinventing it.

I scaffold new products already connected to the billing engine, so Bootspring stands up a product that can charge customers before I write its first feature. Billing stops being a multi-week project per product and becomes a capability that is already there. That is the foundation earning its keep on the piece that most directly touches revenue: every product takes money correctly, from the start, because the hard part was solved once for all of them.