Work / Brokerage operating system
Brokerage operating system
Live demo belowBuilt for an independent insurance brokerage running a book of business across five carriers and four wholesalers in spreadsheets. Clients, policies, and markets became real records — and a certificate of insurance stopped being a fifteen-minute retyping job.
- Client
- An insurance brokerage — name withheld at their request
- Our role
- Discovery, product design, full build, ongoing maintenance
- Scope
- CRM, policy register, carriers & wholesalers, certificate engine, client portal
- Stack
- React · Node · PostgreSQL · PDF generation
This is a live sandbox, not a slideshow. The interface below is the real one, running in your browser against invented data — no real insured, policy, or premium appears here, and the certificate you can generate is not a document of any legal effect. Click anything. Reload the page to reset it.
How it is built
A React application over a Node API and PostgreSQL, with server-side PDF generation for every document the brokerage puts its name on. It is a small system by line count and an unusually careful one, because the records it holds are the evidence in a dispute about whether someone was covered.
The model that matters
A brokerage does not have customers and products. It has an insured, a policy written by a carrier, sometimes reached through a wholesaler, in a term with a start and an end. Getting those five as first-class records — rather than columns in a spreadsheet named after the client — is what makes everything else possible: renewals become a query, commission becomes arithmetic, and market concentration becomes a chart instead of an argument.
Renewals are a query, not a reminder
Every policy carries its expiry. The system continuously flags anything inside the renewal window and puts the count where a producer will see it. Nobody has to remember to check, and nobody owns a spreadsheet tab whose loss would cost the agency a book of business. A lapsed commercial policy is not a missed sale — it is a client with no cover who believed they had some.
The certificate engine
Certificates of insurance are the daily grind of a commercial brokerage. A general contractor will not let a subcontractor on site without one naming the right holder, and they always need it today. Ours composes the certificate from the policy record: insured, carrier, policy type, limits, term, and the holder-specific text — generated, numbered, stored against both the policy and the client, and delivered as a PDF. Every issued certificate is retained exactly as it was sent, because six months later the question is not what the policy says now, it is what the certificate said then.
Access and audit
Producers see their own book; account managers see the agency's; the insured sees only their own records through the portal. Those rules live in the API, not the interface. Every write is journalled with actor, timestamp, and previous value — partly for the errors-and-omissions file, mostly because in insurance "who changed the limit and when" is a question that eventually gets asked in earnest.
What we would build next
- Carrier downloads — ingesting policy data directly from carrier feeds instead of keying it.
- Commission reconciliation against carrier statements, which is still a monthly spreadsheet.
- Renewal marketing workflows — remarketing a policy to several carriers and comparing what comes back.
Is your book of business a spreadsheet?
Agencies outgrow spreadsheets at around two hundred policies. The tell is usually the certificate request that takes twenty minutes and a phone call to answer.