Re-platforming a fintech insurance business
Rubber Ring set out to make insurance feel like modern fintech - simple, fast and app-like. Since launching in 2020 their platform had grown and evolved: first a serverless Progressive Web App for tyre insurance, then a re-platform onto a modern, serverless JavaScript stack that brought golf, sports and new products into the fold. By 2026, to scale further - more products, more customers, and richer operations - it was ready for a new architectural foundation. We rebuilt the entire platform on modern technology and an event-sourced architecture, and migrated the live book of policies in a single, carefully planned cutover.
The challenge: modernise a working business, without disruption
The platform that preceded this rebuild was already cloud-native and serverless, and it had served Rubber Ring well. But a growing, multi-product insurance business needed more than that design could offer: a clean separation between the systems that write data and those that report on it, infrastructure defined entirely in code, far richer back-office tooling, and the headroom to add new products quickly. Left unaddressed, the older design would increasingly slow the pace of new products and cap how far the business could scale. And it all had to happen around a live book of customers, with no interruption to cover or claims.
An event-sourced architecture (CQRS)
Rather than simply refresh the old stack, we rebuilt the platform around a clear separation of concerns - known as CQRS - splitting the write side from the read side:
- A single-table Amazon DynamoDB store is the source of truth for every policy, quote, customer and claim - fast and endlessly scalable.
- Change data streams from DynamoDB are processed in real time and projected into an Amazon RDS PostgreSQL read model, purpose-built for querying, reporting and the admin experience.
- The customer application, built with React Router 7 on Node.js, reads and writes against DynamoDB directly, giving customers a fast, server-rendered, app-like experience.
- The admin application, a PHP application with two-factor authentication, queries the PostgreSQL read model to power policy and customer management, claims triage, reporting and a configurable pricing model.
A modern stack, containerised and defined in code
The customer and admin applications run as containers on Amazon ECS Fargate - the right home for two long-running, framework-rich apps - fronted by CloudFront and a web application firewall. Around them sits a set of serverless microservices (AWS Lambda) that each do one job well. And the entire cloud environment is provisioned with the AWS Cloud Development Kit (CDK), so every piece of infrastructure is version-controlled, repeatable and reviewable. AWS lets us run this deliberate mix of containers and serverless under one roof, with the security and compliance controls a regulated insurance business depends on.
- React Router 7 on Node.js: a modern, server-rendered customer application, containerised on ECS Fargate.
- PHP admin application: a rich back-office for the Rubber Ring team, also on ECS Fargate.
- Amazon DynamoDB & change streams: the event-sourced write store and the backbone of the CQRS design.
- Amazon RDS (PostgreSQL) with RDS Proxy: the queryable read model behind the admin and reporting.
- Serverless microservices (AWS Lambda, SQS, SNS & EventBridge): focused, event-driven and scheduled jobs - document generation, customer communications, renewals and expiries, and automated regulatory compliance screening.
- AWS CDK: the whole environment defined as code across multiple stacks, with CloudFront, WAF, ACM and Secrets Manager for secure, fast delivery.
A single, planned cutover
Migrating a live insurance book is unforgiving work. We built and rehearsed a one-shot migration that transformed every existing policy into the new platform's shape, and cut the business over in April 2026. Security, resilience and data integrity were designed in and proven well before that switch, so from the moment new and existing customers were served entirely by the new platform, our focus was operational tuning and refinement rather than shoring up foundations.
