
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.