Production Stripe, shipped in 14 days.
Idempotency is the whole job
Every billable event must be counted exactly once, even if a request retries, even if a webhook arrives twice, even if a deploy lands mid-request. We make the usage event the source of truth, key it deterministically, and report to Stripe from that table, never from the request path.
In our LovedPDF sprint, that single rule, the request path records intent and one reconciler reports usage, is what produced zero billing disputes in three months.
Shadow mode for any pricing change
When a sprint changes how customers are billed, we run the new meter in shadow mode for a full cycle first. It counts everything and bills nothing. Every affected customer sees their exact new number before it ever touches a card.
What a Stripe sprint typically covers
- A metered or usage-based billing layer with idempotent events.
- A subscription model: plans, upgrades, proration, dunning.
- A reconciliation engine matching Stripe against your ledger.
- A migration from flat-fee to usage pricing, run in shadow mode first.
Stripe work, shipped.
Stripe questions.
Yes. We run any pricing change in shadow mode for a full billing cycle so every customer sees their new number before it is charged.
A Stripe feature to ship?
Send a one-page brief. A fixed price and a ship date back by morning.