Insurance Policy Platform
An insurance company reported seven-figure annual software spend. The proposal for a platform it could own estimated a five-figure annual replacement cost, including the build. That was a projection, rather than a measured operating cost.
I worked across strategy, design, and engineering on an insurance policy platform. The build covered the workflow from a customer's quote through payment and policy documents, along with the tools for administering policies and configuring broker access.
We used a legacy policy-administration product as a reference for the scope. The initial build took a few weeks, using a stack and a component library that were already in place. Most of that time went into the insurance behavior: rating, eligibility, policy state, documents, and the relationships between agencies and brokers.
Following a quote through the product
The customer-facing work included landing pages, account creation, quote forms that branch by product and jurisdiction, and online payment collection. The platform generates policy documents, declarations, and notices, with policy management available to the people administering the business.
The way someone finishes depends on the program they enter through. Some customers pay online; other quotes go to a broker for submission.
Those pieces share the same backend. Product and jurisdiction affect the quote flow; policy state and document templates govern the documents. The interface has to present those differences while keeping the underlying records connected.
Customers can change their coverage at checkout, and that choice updates the saved quote. The payment must use the same selection that staff see in the admin record.
Configuring agencies and brokers
The scope included both an agency configuration and an MGA-style organization working with multiple brokers. They needed different branding, forms, products, commissions, and document templates, with access controlled by role.
We handled those differences through the data model, permission boundaries, and configurable components. The application could share its forms, tables, and navigation while applying the configuration for a particular tenant.
Reusable quote templates have separate partner assignments. The same template can serve multiple partners while each keeps its own branding, links, and default flow. Agent links inherit their partner's configuration.
That was a substantial part of the work. The number of screens alone doesn't describe the combinations of products, jurisdictions, and broker access the platform needs to represent.
What was already in place
The build started with Next.js and TypeScript, a typed API client, PostgreSQL, deployment, and observability. The component library already covered forms, tables, navigation, and dashboards, including focus states and dark-mode styles.
The interface and API share one Next.js runtime. Business rules and access checks run on the server. TypeORM handles database access, while external services handle payments, address validation, and policy submission.
That existing work explains the short initial build. We could spend the time on quote rules, policy behavior, payment hooks, and tenant configuration.
Recovering an accepted policy submission
The external provider can accept a policy even if updating the customer record in our system fails. Retrying the whole process could create a second submission. The application keeps the accepted result and lets staff retry the local customer activation, linking the recovered record to the existing policy. If the result of a payment operation is uncertain, it requires review before another attempt.
