Inspiration
Last month, one of our team members - Sam - was involved in a car accident after dropping off some birthday presents. Fortunately, aside from being shaken up, he had no injuries. However, it was the start of a long process of reading insurance documents, making claims over the phone and arranging repairs.
One part of this process involved uploading photos of the damage. This was so that the garage could assess what would need to be replaced and order parts in before they receive the car, so that they can do the repair quickly. However, the garage did the assessment wrong. The consequence of this was that they initially ordered the wrong parts and the repair took longer to complete.
Overall, Sam's experience of claiming via his insurance was negative. Having spoken to the Zurich Insurance representatives at HackZurich, we learned that more people have negative experiences than positive ones. So, given the chance to use the power of AI to improve the way in which customers interact with insurance companies, we decided to accept the challenge and solve some of these issues.
What it does
BraveGuard allows customers to upload photos of the damage caused by a car accident as soon as it is safe to do so. It will then harness the power of Google Vertex AI to assess the damage caused. It will then also use this AI to analyse a customer's insurance policy to determine which parts of the damage are covered. This saves the customer from having to write long lists of what has been damaged, and from having to read long insurance documents to check if they're covered.
Furthermore, using a well-trained AI model will remove the chance of human error when it comes to ordering parts; garages will be provided with a list of what is damaged rather than them having to assess it themselves.
In addition, we understand that people will need some help while their car is off the road. So, BraveGuard will automatically recommend taxi and car rental companies which may be of use to the customer.
How we built it
We quickly identified our strengths and planned our roles accordingly:
- Didem Istar - Front End Design, Video Script Writer & Videographer
- Ishwor Giri - Front End Developer
- Quan Zheng - AI Developer
- Sam Hirst - Back End Developer & Submission Writer
We built the front end and back end in parallel, regularly checking in with each other to ensure that we were all keeping to the planned goal.
The back end is written in TypeScript, using the ExpressJS framework to implement a REST API. Key features of this codebase include its:
- modular style: helps to improve code readability
- linting tools: eslint is configured to enforce code style - using Google's style guide
- documentation: a README is provided, in addition to comments throughout the codebase
- deployment: the back end is hosted on a virtual machine in Google Cloud. To reduce latency, it is hosted in Google's Zurich data centre (which is one of its most sustainable data centres!).
The back end integrates with two Google Vertex APIs. The imagetext-predict model is used to generate a description of the image, which is then checked for keywords which may relate to types of damage (such are bodywork damage, fire, smashed glass, etc.). We also use the chat-bison-32k model, with a detailed context configuration, to check what types of damage are covered by a customer's policy.
Additionally, the back end generates a list of nearby businesses which may be able to help a customer following a car accident.
The front end is also written in TypeScript, using the ReactJS framework to create a single page application.
Challenges we ran into
Because of the short timescales involved in a hackathon, our AI model was not as sophisticated as we would have liked. We had hoped to make more specific conclusions about damage caused to vehicles when we analyse uploaded images. However, we were instead able to succeed in making more general remarks about the damage (fire, glass, panel).
In order for the back end to interact with the AI, we had to make use of a Google API token. For reasons we still don't entirely understand, our API token was frequently refreshed - roughly once per hour. This would cause the back end to periodically break down when it failed to connect to the Google API.
A final challenge, towards the end of the project, was finding a good location to record our video. We struggled to find a quiet location which would allow us to have minimal background noise throughout the video.
Accomplishments that we're proud of
We chose this challenge because it was personal to a member of our team, and we are very proud of that fact. We feel that the solution we have devised has the potential to be developed further and improve what is a very stressful and upsetting time for customers.
We are also very proud of the UI and UX of our application. We took the time to make sure that the small details were right, and we feel that these small details add up to make the product look very polished and impressive.
Finally, we are proud of the way that we worked together as a team. Working on multiple tasks in parallel undoubtedly helped us to achieve more in the limited time that we had, and regular communication helped us all to stay on track and produce components that could ultimately be brought together to create a great application.
What we learned
Prior to this challenge, nobody in our team had much experience of working with AI models. We knew that we would face a steep learning curve when taking on the Zurich Insurance challenge, and we feel that we suceeded in that learning journey.
What's next for BraveGuard
We believe that there are many ways in which BraveGuard can be built upon to improve the value that it gives to customers.
First of all, we've only covered car insurance in this proof-of-concept. But this can be extended to other types of insurance too. For example, a user could upload a picture of damage to their house, and BraveGuard could them if the repair would be covered by their insurance possible.
Second, for the car insurance functionality, we would like to improve the AI model so that it is able describe exact components of the car which are damaged. Not only would this help garages to order parts sooner so that they can make quick repairs, but it could also be used to accurately calculate the total cost of the claim. This would help customers to understand what excess they'll have to pay (if any), and help insurers to decide what is worth repairing and what should be written off.
Finally, we would like to use the improved data collection to automatically send claims forms to insurers. This will save customers from the stress and loss of time that they currently face while making insurance claims.
Built With
- ai
- express.js
- figma
- github
- google-cloud
- google-vertex
- jsx
- react
- typescript

Log in or sign up for Devpost to join the conversation.