We built a short-term insurance admin system. It was not fun. (Part 1)

· 2 min read

What started as an automated front-end quoting and sales platform quickly became two projects: the platform that sells policies, and the backend administration system that manages them afterwards.

Two systems. Roughly four times the work we initially imagined.

A few lessons from the trenches:

1. Get the architecture right early.

We initially built several components into the front end, only to realise they needed to sit in the backend if that system was going to operate independently and be licensed to third parties.

So, we rebuilt them.

The lesson? Decide early where your business rules belong. Getting it wrong is expensive.

2. Build your scars into the system.

Years of operational experience translate into rules that software needs to understand: debit order processing, collection mandates and regulatory definitions.

Is a policy not taken up, cancelled or lapsed? These aren't interchangeable labels. Your system needs to know the difference, and you need to be able to explain it to the regulator.

3. Design for every sales channel.

Direct sales, call centres and brokers don't operate in the same way.

A call centre may rely on recorded calls as evidence of a sale, while an online journey relies on electronic acceptance and its associated audit trail.

Same policy. Different processes, controls and evidence.

4. Test everything. Then put it in front of real people.

No test plan can anticipate every permutation of human behaviour. We're gloriously creative creatures, particularly when it comes to breaking things in ways nobody anticipated.

A controlled rollout to a cohort of real policyholders can reveal issues no test script ever will.

5. Accept that it's never finished.

There's always another document, business rule, integration, exception or edge case.

The trick is knowing what must be resolved before launch and what can sensibly follow.

The biggest lesson?

The front end sells the policy. The backend has to live with it.

Building insurance technology isn't just a software exercise. It's about translating operational experience, regulatory requirements and commercial realities into a system that works in the real world.

Would I do it again?

Ask me after the next release.

Back to all insightsStart a conversation