🎓 Capstone · College of the North Atlantic · 2025 · Team of 4
🏆 Best in class

Taylor Insurance

Full-stack insurance management platform built by a team of four as a final-year capstone. I owned the entire frontend, built the API layer connecting it to the backend, and deployed it to AWS independently after submission. Every team built the same spec. Ours was best in class.

GitHub →
ReactSpring BootJavaMariaDBAWSREST API
taylorinsurance.ca
Taylor Insurance landing pageClick to enlarge
The Build

Two interfaces. One backend.

The app splits into a customer-facing portal and a separate admin panel, both hitting the same Spring Boot REST API. Customers go through the full policy lifecycle. Admins control the system behind it.

Customer Portal
Get quoted. Buy. Manage.
Customer dashboardClick to enlarge
  • Get instant quotes for auto or home insurance
  • Purchase and activate policies in one flow
  • View, renew, or cancel existing policies
  • Edit profile and contact support
Admin Panel
Reports. Controls. Users.
Admin dashboardClick to enlarge
  • View all policies and active quotes across all users
  • Policies broken down by type, premiums by year
  • Update the rating factors that drive the quote formula
  • Manage all user accounts
Quote Engine

Quote. Calculate. Purchase.

Customers fill in their details and get an instant premium. Admins control the rating factors behind the formula. Change a multiplier and every future quote reflects it immediately, no code change required. I built the frontend side: the forms, the API calls, and displaying the result.

Auto quote formClick to enlarge
Auto: driver age, vehicle, accidents → $752.30
Home quote formClick to enlarge
Home: value, dwelling type, heating, location → $1,487.07
Auto inputs
Driver age, vehicle make, model, year, and number of accidents. Each feeds into the premium calculation as a weighted factor.
Home inputs
Home value, liability limit, date built, dwelling type, heating type, and location. More variables than auto, more surface area for the admin-controlled multipliers.
Dynamic rating factors
Admins update the underlying risk multipliers for both policy types via the panel. The formula reads from the database, not from hardcoded values. Change a factor, every future quote changes with it.
One-click purchase
After the quote is calculated, a single button purchases the policy and adds it to the customer's account. The quote result includes a validity date.
Stack

What it's built with, and why.

⚛️React

I owned the entire frontend: component structure, routing, and all the API calls connecting the UI to the Spring Boot backend. First time building a full SPA against a REST API I was also actively contributing to.

☕Spring Boot

Part of the project requirements. The backend was the team's domain. My contribution was the API layer the frontend depended on, plus debugging and fixing backend issues that surfaced during integration.

🗄️MariaDB

Part of the project requirements. Policies, users, quotes, and rating factors all have clear relationships. The relational model fit the domain well and I got hands-on experience writing queries against a real production-style schema.

☁️AWS

Not part of the original capstone requirements. I deployed it independently afterward: React frontend on Amplify, Spring Boot backend on an EC2 instance, and MariaDB on RDS. A real three-tier deployment, set up from scratch as a personal learning goal.

Screenshots

The full flow.

Customer policiesClick to enlarge
Customer: My Policies
Admin policies by categoryClick to enlarge
Admin: Policies by Category
Admin user managementClick to enlarge
Admin: All Users
Admin user policiesClick to enlarge
Admin: User Policy Detail
Reflection

What worked. What I'd change.

What worked
✓Owned the full frontend end to end: every component, route, and API integration
✓Deployed on AWS independently after submission, outside of the coursework requirement
✓App was fully functional at submission. The deployment was a personal addition afterward.
✓Quote engine fully implemented and working across all auto and home inputs
What I'd do differently
→No tests at all. The quote engine is the core of the product and it has zero test coverage.
→Function came first, visual polish did not. I'd approach the UI design more seriously now.
→Would push for a shared component library earlier. Consistency across the two interfaces was harder to maintain than it should have been.
The Name

About Josh Taylor.

The company was named after our instructor, Josh Taylor. My teammates took it further than anyone expected. They wrote him a complete fictional biography: founder of Taylor Insurance in 2005, deep roots in Newfoundland and Labrador, a background in business, and a vision to put people before policies. The about page shipped with the project.

Taylor Insurance about page featuring Josh TaylorClick to enlarge