Skip to content
Turing IT
Turing ITInternal projectSomersetDelivered March 2026

Replacing an expensive invoicing subscription with software we own

We were paying a monthly subscription for invoicing that we did not own and could not change. So we built the replacement, and it is a fair illustration of when building beats renting.

Zero
monthly subscription fees
Self-hosted
our data, our server
Recurring
invoices, reminders and overdue sweeps automated
Owned
source code, no vendor lock-in

The problem we set out to solve

An invoicing subscription that cost money every month indefinitely, could not be adapted to how we actually work, and held our billing data on someone else's terms.

Bespoke software developmentSystem integration

Why this one is different

Every other case study here is client work. This one is ours, and we have included it because it is the most honest demonstration of an argument we make to clients regularly: past a certain point, renting software costs more than owning it, and the cost is not only money.

We were paying a monthly subscription for invoicing. It worked. It also charged us every month regardless, could not be shaped around how we actually bill, and kept our billing history somewhere we did not control. That is a reasonable trade-off for a business that needs invoicing tomorrow. It is a poor one for a software company that intends to still be invoicing in ten years.

So we built the replacement.

What we built

A full invoicing and payments platform, self-hosted.

Billing

  • Invoices and quotes with gapless numbering, several PDF templates, multi-currency and EU reverse-charge support.
  • Recurring invoices on a proper scheduling standard, with automated reminders and an overdue sweep.
  • Partial payments and manually recorded payments alongside card payments.

Money in

  • Stripe Connect, so payments go directly where they should rather than through an intermediary.

The business view

  • Expenses, profit and loss, aged debtor reporting and top-client analysis.
  • CSV and XLSX export, because data you cannot get out is not really yours.

Built to last

  • Team accounts with owner, admin, member and viewer roles.
  • A versioned public REST API with API keys, rate limiting and idempotency.
  • Outbound webhooks with signed payloads and retry handling, so other systems can react to billing events.

It runs on Next.js and TypeScript over PostgreSQL, with Redis for background jobs and S3-compatible object storage for documents. The infrastructure choices are deliberately dull: everything runs in containers on our own server, and the only thing that lives off-box is Stripe.

The result

The subscription is gone, and with it the monthly bill that would have continued forever. More to the point, the system now fits our billing rather than the other way round, the data is ours, and when we need it to do something new we change it rather than submit a feature request and wait.

That is the same calculation we help clients make. It does not always come out in favour of building: where good specialist software already exists, integrating it is usually the right answer, and we say so. But when the rented thing is a poor fit and the rent never stops, building is the cheaper option over the life of the system.

Built with

Next.jsTypeScriptPostgreSQLStripe

Have a process like this one?

If this sounds like a problem you recognise, a similar system could remove it. Book a free process audit and let's find out.

Book a free process audit