SwimBack Legal is a fee-accounting platform for barristers' chambers. A single fee run touches tax, VAT, commissions, direct payments, and Legal Aid Agency contingency repayments. The idea and the working prototype were already there. What it didn't yet have was a way to run as a real product. Somewhere reliable to live, the security a finance system has to clear, the integrations chambers expect, and the day-to-day robustness that lets a chambers trust it with their books.
The brief was straightforward in its outcome and substantial in its detail. Take what existed and make it production-ready, deployed, secured, integrated, observed, and easy to keep maintaining. By the end of the engagement, SwimBack Legal wasn't a project being built; it was a product being used by chambers across the UK.
Choosing infrastructure the team could actually own
The default move for a Java/Postgres stack would have been AWS. We deliberately went the other way. The platform needed an environment the operating team could understand, log into, and manage without dedicating a DevOps role to it.
Backend on Render. Render gave us managed deploys, automatic HTTPS, simple environment management, and predictable pricing. The trade-off against AWS was control over knobs we did not need; the upside was a platform the team could navigate themselves to check a deploy, rotate a secret, or read a log without us in the loop.
Postgres on Neon. The local development database was migrated to Neon, a serverless Postgres with branching, backups, and consumption-based pricing. For a finance platform that ramps with usage rather than running hot 24/7, the cost shape matched the business much more honestly than a fixed-size RDS instance would have.
The shape of the bill matters as much as the size of it. SwimBack Legal can take on more chambers without the running cost stepping up before the revenue does.
Streaming the heavy work so it doesn't break
Fee runs and monthly bills involve processing batches of records, generating PDFs, and posting line items to external accounting systems. The original code path loaded everything into memory at once. That was fine on a developer laptop with a small test dataset; it would not have survived a real month-end at the scale the platform now operates at.
We re-shaped the heavy paths around streaming. That means reading and writing in chunks rather than collecting full result sets, generating documents incrementally, and releasing memory as the run progressed. The practical effect is that a fee run for a chambers with hundreds of fee items completes inside the platform's memory budget, and a larger chambers doesn't change the architecture, only the runtime.
Security worthy of a finance platform
SwimBack Legal handles real money, real bank details, and real tax, for every chambers using it. The security model had to reflect that.
MFA on every admin login. Time-based one-time passwords, enrolment flows, recovery codes, and session policies that match what a finance team would expect from any other tool they use.
Stronger password rules. Length minimums, breach-list checking, and rate-limited login attempts. The unglamorous baseline that keeps an account from falling to a credential-stuffing attempt months after launch.
Transactional email through SendGrid. Account verification, password resets, and run notifications now go through a dedicated provider with proper authentication (SPF, DKIM, DMARC) so the messages land in inboxes and don't pretend to come from anywhere they don't.
Connecting to the systems chambers already use
A finance platform that doesn't talk to the rest of the finance stack ends up creating a new manual job. We wired SwimBack Legal directly into Xero through OAuth so invoices, credit notes, and refunds post into a chambers' books in the structure their accountant already uses, with a clear audit trail back to the originating fee run. CSV exports for Sage and QuickBooks remain as parallel paths for chambers that don't run on Xero.
A test and monitoring suite the team can lean on
Production is where bugs become incidents and incidents become refunds. We built a layered test suite covering the financial-logic services end-to-end, the integration points to Xero, and the high-risk pathways through fee runs and monthly bills. The point was not coverage as a number. It was confidence that a future change to a commission rule or a tax handling case wouldn't quietly break the run for any chambers running on the platform.
Alongside the tests, we set up runtime monitoring so that an exception, a failed export, or a slow fee run surfaces visibly rather than silently. The team gets a heads-up; we get a signal to act on; nothing waits for a chambers admin to email and ask why their PDF didn't arrive.
A CI/CD pipeline that takes the fear out of deploying
Every push to dev ships to a development environment; every push to main ships to production, both gated on the test suite. There is no manual deploy step, no FTP, no "did anyone push that yet?" The development environment exists specifically so changes can be tried against real-shape data without touching the live platform.
For the team, the practical effect is that a request like "can we tweak how this column is labelled on the PDF?" can land in dev within hours and in production the same week, with the test suite and the deploy pipeline doing the work that would otherwise need to be coordinated by hand.
What was delivered
- Backend deployed to Render with managed HTTPS, environment management, and a pricing shape the team can plan around
- Database migrated to Neon serverless Postgres with branching, backups, and consumption-based scale
- Heavy processing paths (fee runs, monthly bills, document generation) re-shaped around streaming so they hold inside memory budgets
- MFA, hardened password handling, and rate-limited authentication on every account
- Transactional email through SendGrid with proper SPF, DKIM, and DMARC authentication
- Direct Xero integration via OAuth for invoices, credit notes, and refunds, alongside CSV exports for Sage and QuickBooks
- Layered test suite covering financial logic, integration points, and high-risk fee-run paths
- Runtime monitoring so exceptions, failed exports, and slow runs surface immediately
- Full CI/CD pipeline auto-deploying
devandmainon push, with a separate development environment for safe iteration
