Insurance Management System:
Completed & Deployed

It's Done

When I wrote the first post about this project, the foundation was in place but nothing was working end to end. The architecture was right, the layers were defined, the database was connected — but there was no UI, no features, no deployed app. Now there is.

The Insurance Management System is fully built and live. You can sign up, log in, and manage clients, policies, and claims — with risk scoring calculated automatically based on each client's profile and claims history.

What Was Built

The app covers the full insurance workflow that a small broker would need:

• Client management — full CRUD for clients with contact details, policy history, and an automatically calculated risk score
• Policy management — create and manage policies per client, with policy type, coverage amounts, start and end dates, and status tracking
• Claims management — log claims against policies, track claim status, amounts, and dates
• Risk scoring — automatically calculated per client based on their claims history and policy profile, displayed clearly in the UI
• JWT authentication — secure login and signup, with all data scoped to the authenticated user
• Dashboard — overview stats showing total clients, active policies, open claims, and high-risk clients at a glance

The Frontend

The frontend is built with React 19, TypeScript, and Tailwind v4 — scaffolded with Vite. TanStack Router handles all navigation with full type safety on every route. TanStack Query manages all server state — data fetching, caching, background refetching, and loading/error states are all handled cleanly without manual async state management cluttering the components.

All API calls go through a centralised Axios client with JWT interceptors. Every authenticated request has the token attached automatically — components never need to think about auth headers.

Tailwind v4 was a deliberate choice — it's the latest major release and uses a completely different configuration approach from v3. Having worked with both now, I can speak to the differences and tradeoffs from actual experience rather than just documentation.

The Backend

The API follows the same layered architecture established in Part 1:

Every feature — clients, policies, claims — follows the same pattern consistently throughout. The risk scoring logic is a good example of why this matters: it lives entirely in the service layer, completely isolated from the database and the HTTP layer. Changing how risk is calculated means touching exactly one place, and that place is independently testable.

DTOs are used throughout to keep the API contracts separate from the database entities. What PostgreSQL stores and what the frontend receives are deliberately different shapes — this is standard practice in production .NET systems and keeps both sides free to evolve independently.

Deployment

Same deployment approach as Win Stacking — Vercel for the frontend, Render for the backend API. The React app builds automatically on every push to main via Vercel. The .NET API runs on Render with environment variables handling the JWT secret and PostgreSQL connection string — nothing sensitive in the codebase.

PostgreSQL is hosted on Render alongside the API, which keeps the database and backend in the same environment and avoids cross-region latency. Entity Framework Core runs migrations automatically on startup — no manual database management needed after deployment.

Comparing the Two Projects

Win Stacking was built feature-first — get it working, then ship it. That approach is fine for a personal productivity tool, and it produced a clean, deployed app. But the architecture evolved as features were added rather than being defined upfront.

The Insurance app was the opposite — architecture before features. That discipline shows in the codebase. Every layer is clean, every responsibility is clear, and adding a new feature follows a well-defined path. That's how production systems are built, and that's the difference between a portfolio project and a production-ready codebase.

Both are valuable to have. One shows I can ship. The other shows I can architect.