Vehicle insurance — policies, vehicles and trailers without a paper folder

Vehicle insurance — policies, vehicles and trailers without a paper folder

An application for running insurance policies: policyholders, vehicles and trailers in one place, with separate rights for administrators and clerks.

Context

The client brokers vehicle insurance. Data on policyholders, vehicles and policies lived in a mix of paper and spreadsheets — each clerk with their own, with their own column layout.

The consequences were predictable. The same policyholder existed in three versions, a trailer was stored as a separate vehicle so the link to the towing vehicle was lost, and finding a policy that was about to expire meant searching by hand.

The brief

They needed one place for all the data, with clear rules for who may do what:

  • Policyholder, vehicle and policy must be linked — not three separate lists joined by hand
  • A trailer belongs with the vehicle, not as a separate entry nobody connects
  • Clerk and administrator do not have the same rights — the person who enters is not necessarily the person who deletes
  • The application must run in a browser, with no install on each computer

How we solved it

We built a web application where policyholder, vehicle, trailer and policy are linked entities, not separate entries. Open a policyholder and you see all of their vehicles and policies; open a vehicle and you see who insures it and until when.

Access is handled through roles: a clerk does their part of the job, an administrator has full access and manages accounts. Anyone without rights to a page gets a clear message instead of a blank screen or an error.

Registration and login go through a standard security layer, with passwords stored in a form that cannot be read back — a requirement, not an option, when you hold policyholder personal data.

Technologies

  • Spring Boot — application and business logic
  • Spring Security — login, roles and page protection
  • Spring Data JPA and MySQL — linked entities and queries
  • Thymeleaf — pages rendered on the server, without a separate frontend project

What this means today

This is the most common kind of work we do: data that today lives in Excel and on paper, and needs to live in an application used by several people with different rights. The domain changes — insurance, a workshop, wholesale, a membership register — but the problem is the same.

If the company has a spreadsheet everyone opens and nobody is allowed to break, that spreadsheet has outgrown Excel.