When thinking of insurance people don’t often think of high-tech, state of the art systems. They don’t think of platforms capable of collecting and analysing data in real time. Agile, digital products might not be the stereotype for our industry, but at FloodFlash they are the status quo.

We use IoT (Internet of Things) sensors, micro service software models and static webpage hosting to deliver the world’s first mass-market parametric flood insurance. In this blog I’ll “pop the hood” and break down some of the key tech behind our rapid-payout cover.

FloodFlash tech and cloud computing

From day one FloodFlash used cloud computing. This is essentially computer services accessed via the internet. Amazon popularised the term back in the noughties when they started selling their infrastructure technics and internal tooling. Infrastructure as a Service was born. If you’ve ever used Dropbox, Google Drive or Spotify you’ve used cloud computing.

Cloud computing allows for a much more flexible environment and lower costs than you would have previously had renting servers. Physical computers still store your data, but you don’t access them in a traditional sense, and they’re stored in centres all over the world.

FloodFlash is what’s known as a “Cloud Native”, or “Digital Native”, business. And because cloud computing is safer than ever, all our resources are in the cloud, including the website, our broker portal and our internal documents.

FloodFlash and the Internet of Things (IoT)

One of the key features of every FloodFlash policy is the sensor. Put them all together and our network of sensors is an example of something you may have heard of before – the Internet of Things. The Internet of Things, commonly referred to as IoT, is a network of physical objects with sensors, software, and other technologies. Whilst all these objects may be different, they all share a common purpose: collecting and exchanging data over the internet. FloodFlash sensors collect and exchange flood data for policies all over the country. That’s how we know when a flood has occurred, and it’s why we’re able to pay claims in full within a day of flooding. Here’s how it works…

Engineers install of the beautifully designed (well done Head of Product Pete Codling!) FloodFlash sensors on the insured property at the start of every policy. The sensor has a small computer that uses mobile networks to access the internet, just like in your phone. The computer sends data via the mobile networks to the FloodFlash system at regular intervals where we analyse and store it. This data tells us whether a flood is occurring in real time, which means we can react to claims faster than any other insurer in the market. This data is very useful in assessing and paying claims, but that’s not the only use. After we’ve collected the data we also use it on another system that we call the FloodFlash Portal…

FloodFlash and the portal

The FloodFlash Portal is a web application where our commercial team and broker partners can log into and see everything they might need to sell FloodFlash to a client, or to manage an existing policy. It takes all the complex information that we use to price our insurance – including data from JBA, the Environment Agency, the Ordnance Survey, and our sensor network and presents it in an easy to manage way. Brokers can submit and configure new quotes, and manage FloodFlash renewals through the portal.

Recently we provided another way to access the portal, via our online purchasing journey. This doesn’t give access to all the features though, because we don’t want users to have to create a login with a password just to get a quote – so consider this as a window into the portal, rather than an open door.

FloodFlash tech and the dev team

These individual aspects of the FloodFlash architecture come together to make the entirety of the product (with a few more bells and whistles that would need another blog to explain further). Each aspect of this architecture is developed by team members with specific expertise. To make this easier I’ll explain the composition of the FloodFlash development team as if we were to build a house.

FloodFlash infrastructure developers concentrate on managing and maintaining cloud servers that form the bedrock of our systems. In terms of our house, this would be the foundations of the building itself; what everything else sits on top of. Without the foundation we can’t have a house at all.

Next up we have backend developers. They are responsible for building systems that interpret data and allow the end user to get what they need. See it as the walls and layout of the house. They decide that a bathroom goes here, and a kitchen goes there.

Finally, we have frontend developers. These make sure everything looks and feels the way it should. They focus on making everything user friendly and pushing for intuitive designs. In our house, this would be the interior; deciding on furniture, colour of the walls, fitting of the kitchen and even where your favourite plant sits.

FloodFlash and how to build a digital house

Just like a house, building the FloodFlash tech infrastructure takes time, co-ordination and a lot of team-work. Instead of charging ahead with whatever needs to be done, FloodFlash employs a technique called Scrum from the Agile methodology. After all, you don’t want to do the painting before you’ve done the plumbing, otherwise you’d have to undo all the good work from the interior designer.

The Scrum technique is a simple and flexible Agile methodology commonly used in software development. A Scrum is a simple way to address complex problems of a project in order to deliver a high-value product. It allows for greater flexibility in an ever-changing environment.

Every two weeks (known as a sprint) the team gets together and discusses tasks that need to be completed during the following two weeks. This is known as sprint planning. Tasks depend on deliverables set out by what’s going on in the wider business. For example, we may be looking to launch a new product or change some features on the portal based on broker feedback.

Once the product team has sent a set of tasks to the development team they are prioritised and pointed. Pointed means that they are given an arbitrary value. This could be Small, Medium, Large, known as t-shirt sizing, or 3, 5, 8, known as the Fibonacci system. We use the latter. Points determine how much can be done in a single sprint based on how many points were done in previous sprints. For example, a deployment of a new cloud server could be assigned 2 points, but a portal design change might be 5 points. That’s because the portal changes are a bigger job based on previous experience. This process means that the team has a better understanding of what can be done during the 2 week sprint. This helps reduce over-promising or giving the team tasks that are too large.

There are a lot more aspects that go into Scrum and Sprints, but the main idea revolves around the fact that deliverables and goals can change every two weeks. This means that if a drastic change is needed there is no backlog. It is prioritised and often put into the next sprint.

FloodFlash and the next innovation

The Pointed method also allows us to create time for other tasks such as researching new ideas, fixing bugs in the code or helping the wider FloodFlash company with internal tools and monitoring. This also includes 10% time.

10% time goes by many names; project time, anti-BAU. Every tech company has some version of the concept. Whatever the name, they all indicate the same thing; invention outside day-to-day work. Gmail is one of the most famous products from this idea. Google Developers created the email service during their 20% time. At FloodFlash 10% time allows developers to use some work time (we assign half a day, usually on a Friday) to concentrate on creativity. The time is to develop something that may not be directly related to our work, but that pushes the boundaries of what we do at FloodFlash. The FloodFlash team might not have something that resembles Gmail just yet, but watch this space. It may not be long until you are asking the FloodFlash sensor in your living room to play music or read a weather report.

To find out more about more about our award-winning parametric flood insurance, visit our homepage. For more on our relationship with AWS – visit their blog here.