Recurring revenue
Subscription billing systems that handle the awkward cases
Most billing systems work fine until a customer upgrades halfway through a term, changes quantity, adds a seat and then asks for a refund. We have spent over a decade in exactly that code.
You are probably here because
If two or three of these are true, this is a problem worth fixing properly.
- Plan changes mid-term have to be done manually by your support team
- Proration is calculated in a spreadsheet, or not at all
- Customers must cancel and repurchase to switch billing frequency
- Renewals fail silently and nobody finds out until churn reporting
- Refunds are worked out by hand and sometimes get it wrong
- Nobody left on the team understands how the billing code works
What you get
- Renewal and term handling
- Automatic renewals, flexible term conversion so an annual plan can move to monthly billing, and expiry-date adjustment that does not corrupt the subscription record.
- Mid-term changes with proration
- Product change, quantity change and add-on management, with a cart preview that shows the customer the exact prorated charge before they confirm.
- Refunds and downgrades
- Prorated refunds against remaining term, configurable discounts on auto-renewal conversion, and downgrade paths that do not strand data.
- Event-driven architecture
- Billing operations published as events so reporting, entitlements and notifications stay consistent without direct coupling to the billing service.
How it runs
-
Audit
One week reading your billing code and data. You get a written list of what is fragile, what is costing you revenue, and what would break under load.
-
Fix the revenue leaks first
Failed renewals, incorrect proration and silent errors get addressed before anything cosmetic. These usually pay for the engagement.
-
Build the missing paths
Mid-term changes, add-ons and self-service downgrades, each behind tests so the next change does not undo this one.
-
Hand over
Documentation, runbooks and a walkthrough, so your team can extend the billing logic without calling us.
Questions we get asked
Should we build billing or use Stripe Billing or Chargebee?
Use the off-the-shelf product if your pricing is simple and standard — it will be cheaper and faster. Build when your pricing model does not fit their schema, when you need billing logic your product depends on, or when you are already committed to a platform they cannot integrate with. We will tell you honestly which case you are in, including when the answer costs us the work.
Can you work on an existing billing system rather than replacing it?
Usually yes, and usually that is the right call. Replacing billing is one of the highest-risk projects a company can take on. We prefer to stabilise what exists, add tests around the revenue paths, and change it incrementally.
What is proration and why does it keep causing problems?
Proration is charging a customer for the portion of a term they actually used when something changes partway through. It causes problems because the correct answer depends on your billing period, your refund policy, tax treatment, and what the customer was told at purchase — so it is a business rules problem wearing a maths costume.
How long does a billing engagement take?
An audit is one week. Fixing identified revenue leaks is typically two to six weeks. Building out full self-service plan changes is usually two to four months depending on how many pricing combinations you support.
Do you work with our existing engineering team?
Yes, and we prefer it. Billing knowledge that only lives with an outside firm is a liability for you. We pair with your engineers where we can so the understanding stays in your company.
What technologies do you use for this?
Most of our billing work has been Java and Spring Boot with Kafka for events and Oracle or PostgreSQL underneath. We also work in Node and Python. The architecture matters far more than the language.
Send us your billing problem
Describe what is going wrong in a paragraph. We will tell you whether it is a quick fix, a real project, or something you should buy rather than build.