Case Study • Insurance • South Africa
Designing a Custom Insurance Risk & Claims Management Platform (South Africa)
iMR is a custom claims and client management system built with Flutter (responsive web) and Supabase (PostgreSQL, Auth, Storage) for South African insurance brokerages.
Executive summary
We designed and built a custom insurance risk and claims management platform for South African brokerages. The system centralises client records, policies, claims, renewals, and documents in one secure platform. It serves brokerages that need visibility into client activity and claim progress, with less manual admin and stronger data isolation. Core impact: a single source of truth, reduced risk of missed renewals or claim deadlines, and security enforced at the database level.
Client context & audience
The operational reality for many South African insurance brokerages is multi-user, relationship-driven work: brokers and admin staff need to see the full picture of a client — policies, claims, documents — without switching between spreadsheets and email. Service expectations are high: renewals and claims must be tracked, and nothing should fall through the cracks. The system is built for that context: multiple roles, one client-centric view, and data isolated per brokerage.
The problem
- Fragmented client data across spreadsheets, email, and paper — no single view of the client relationship.
- Manual claims tracking and SLA follow-up — higher risk of missed deadlines or overlooked claims.
- Renewal management done manually — time-consuming and error-prone, leading to missed renewals.
- Documents scattered in email and folders — hard to link to specific clients, policies, or claims.
- Generic CRMs do not model insurance workflows: policy lifecycles, claim logging, insurer fields, or document linkage. Brokerages need a system that matches how insurance is administered.
The solution
One platform with a client-centric data model: clients, policies, claims, renewals, and documents are linked so that each record has full context. Policies and claims sit alongside client records; documents are stored and linked to the relevant entity. The system avoids marketing language — it is a structured tool for managing insurance workflows: logging claims, tracking status and SLA age, storing documents, and monitoring renewals. The responsive web app works on desktop and tablet for office and field use.
Architecture & security
- Frontend: Flutter responsive web — one codebase, consistent experience across devices.
- Backend: Supabase: PostgreSQL, Auth, and Storage. Central data model with relationships between clients, policies, claims, and documents.
- Security: Row Level Security (RLS) for brokerage-level isolation — multi-tenant by design. Each brokerage sees only its own data.
- Audit trails: Key actions and status changes are recorded so that who did what and when is traceable. No table names or implementation detail exposed here.
Key capabilities
- Claims lifecycle tracking with SLA age visibility.
- Client record with full context: policies, claims, documents.
- Policy renewals and reminders.
- Document storage linked to clients, policies, or claims.
- Admin dashboard for visibility into open claims, active policies, and activity.
- Multi-user roles with access aligned to function.
Delivery approach
MVP-first, then phased delivery: core functionality (clients, policies, claims) first, then iteration from feedback. Schema and RLS were designed first so that data isolation and relationships were correct before building workflows and UI polish. Each phase delivered working functionality that could be tested and refined.
Workflow
- Onboard client: Capture client details; manage policies and claims from one place.
- Add policy: Capture policy details and link to client; renewal visibility.
- Log claim: Record claim with insurer details, notes, and SLA age tracking.
- Track claim progress: Update status, add notes, maintain audit trail.
- Manage documents: Store documents securely, linked to policy or claim.
- Renewals & follow-ups: Track renewals and reminders so nothing is missed.
- Dashboard: View open claims, active policies, and client activity at a glance.
Outcomes
The system delivers operational clarity: one place for clients, policies, claims, and documents. Brokerages can reduce the risk of missed renewals and claim deadlines by having visibility and reminders in one platform. Secure data isolation at the database level means each brokerage's data stays separate without relying on application-level checks alone.
Related services
Web Development South Africa · Mobile & Web App Development South Africa
Frequently Asked Questions
What is a claims & client management platform for brokerages?
A claims and client management platform is custom software that centralises client records, policies, claims, renewals, and documents in one system. It gives brokerages a single source of truth, workflow tracking (including claim SLA age), and secure storage linked to each entity. It replaces spreadsheets, email, and paper with a structured, auditable system.
Why not use a generic CRM?
Generic CRMs are built for sales pipelines and contacts, not for insurance workflows: policy lifecycles, claim logging, renewal reminders, and document linkage to specific policies or claims. Brokerages need client-centric data models, insurer-specific fields, and workflows that match how insurance is actually administered. Custom systems avoid workarounds and keep data structured for compliance and reporting.
How does Row Level Security help multi-tenant systems?
Row Level Security (RLS) enforces data access at the database level. Each brokerage's rows are isolated by a tenant identifier; users can only see and modify their own brokerage's data. That gives multi-tenant security without pushing isolation logic into every application query, and reduces the risk of cross-tenant data leakage.
Can this be extended to mobile apps?
Yes. The system is built with Flutter for the web client; the same codebase can be extended to iOS and Android for mobile apps. The Supabase backend (PostgreSQL, Auth, Storage) is already API-driven, so mobile clients would use the same data model and RLS policies.