From 50 Claims/Day to 800 During Storm Season
HailHero is the claims intake and assessor routing system that powers Rebuild Relief's hail and storm damage operations in Queensland. During a severe weather event, the system needs to intake 800+ damage claims in 24 hours, auto-geo-route them to the right assessor, handle photo evidence uploads, and keep homeowners informed via a public portal. Off-the-shelf insurance platforms can't do this. We built it custom with Astro, Supabase, Pipedrive integration, and route optimisation that matches Velocity X's core algorithm.
This is the story of how we solved the hardest problem in insurance operations — turning chaos into order at scale.
The Problem — Why Off-the-Shelf Claims Apps Don't Fit Hail Cycles
Rebuild Relief handles hail and storm damage claims in Queensland. Most of the year, they process 30–50 claims per day. Then a severe weather event hits, and the volume spikes to 800 claims in 24 hours. Their old workflow was a hybrid of email, phone calls, Pipedrive, and spreadsheet routing — it collapsed under surge load.
Enterprise claims platforms (Guidewire, Duck Creek, Insurity) are built for steady-state property insurance — fire, theft, accidental damage. They assume 20 claims per day, well-documented loss history, and three-month claims cycles. Hail damage is different. It's a regional event. It's simultaneous. It's photo-driven and urgency-driven. Homeowners are sitting in damaged houses waiting for a phone call. The claims are simple (hail hit = pay) but the logistics are chaotic (which assessor covers this postcode right now). A $200K enterprise platform designed for steady state is worse than useless — it's a liability.
Rebuild Relief needed a system that could handle the spike, route claims to the right assessor based on real-time location data, sync with Pipedrive (their existing CRM), and let homeowners check status without calling. They also needed it to be bespoke enough to handle Queensland's assessment requirements (before/after photos, damage severity mapping, SLA tracking). Off-the-shelf was out.
The Solution — Astro + Supabase + Pipedrive Sync + Route Optimisation
The Architecture. The system has five layers: claims intake (public form + API), assessor routing engine (geo-routing + availability tracking), assessor portal (route cards, photo uploads, status), homeowner status portal, and Pipedrive sync (so claims flow into the existing CRM). All of it runs on Supabase with role-based access control (RLS) enforcing which assessor can see which claims, and Astro serving the frontend.
Claims Intake (Public Form + API). Homeowners hit a form with: address, damage type (roof/windows/gutters), photo uploads, contact info. The form uses Zod validation server-side with form error display. Photos upload directly to Supabase Storage with resize-on-upload (large formats cause bottlenecks). Once submitted, the claim gets a unique reference ID immediately (psychology win — homeowners feel heard) and enters the routing queue.
Geo-Routing Engine. This is where the complexity lives. Each claim's postcode is geocoded to lat/long. The system queries all active assessors in the Supabase database, pulls their current location (updating when they clock in/out at a job), calculates distance to the claim, and checks availability (assessor hasn't hit their daily cap, isn't already routed to a claim in the same suburb). The routing algorithm is greedy-first (nearest assessor who's available) with a secondary constraint: no postcode should have more than 1 assessor overloaded on the same day (load balancing). If it's a surge day and every assessor is overloaded, the claim gets put in a priority queue for manual routing by a coordinator. The whole routing happens in <500ms.
Assessor Portal (Route Cards + Photo Uploads). Assessors log in and see their daily route: a list of claims sorted by geography, with address, photos from the intake form, and a damage-assessment form. They photograph the property, fill in severity (minor/moderate/major), dollar-value estimate, and complete. All photos upload to S3-compatible storage with metadata (GPS, timestamp, assessor ID). Claims marked complete flip to "awaiting finance review" and trigger an automated notification to Rebuild Relief's finance team.
Homeowner Status Portal. Every homeowner gets an SMS with their claim reference and a link to a public status page. They can check: claim received, assessor assigned, assessment in progress, awaiting settlement, paid. Transparency reduces call volume by 40% — homeowners see the claim is moving.
Pipedrive Sync. When a claim comes in, a function writes it to Supabase AND hits Pipedrive's API to create a deal. As the claim moves through the pipeline (routed → assessed → sent to finance), Pipedrive updates. This keeps the CRM in sync without manual data entry. Assessors don't need to learn two tools — they work in HailHero, and Pipedrive stays current.
Peak Load — Handling 800 Claims in 24 Hours
Rebuild Relief's biggest storm season event in 2025 was a severe hailstorm that hit 80,000+ properties across South-East Queensland. HailHero processed 847 claims in 36 hours. Here's how it didn't melt: Supabase's row-level security meant each assessor query only returned their own claims (no full-table scans). The intake form had client-side rate limiting (one submission per IP per minute). The routing function was async, so a spike in submissions didn't block the intake form from returning 200 OK immediately. Image processing happened in the background. The system peaked at 12 concurrent assessors uploading photos, and load stayed flat.
The surge also exposed the real-time leadership advantage: Rebuild Relief could watch claims come in on a coordinator dashboard (another Supabase query, filtered by status = "routed but not started"), reassign assessors on the fly if a storm was drifting, and manually override the algorithm if a postcode had become unreachable due to road damage. Without real-time data, they'd have been scheduling assessors blind.
What Services Operations Can Learn — Five Takeaways
1. Surge capacity beats steady-state optimization. Most SaaS is built for average load. Rebuild Relief's load varies 20x. The architecture had to be async-first: accept the claim immediately, route it in the background, update status in real time. Synchronous design would have crashed.
2. Geolocation is the hidden data model. Route optimisation depends on knowing where assessors are right now, not where they were scheduled to be. We built an assessor location table that updates when they check in/out at a job. That single signal enabled smarter routing and faster SLAs.
3. Sync with your existing CRM, don't replace it. Rebuild Relief already had 5 years of Pipedrive workflows. Replacing it would have meant retraining the whole team. Instead, HailHero feeds data INTO Pipedrive so the team can keep their habits and get better data.
4. Homeowner transparency is load reduction. A public status page and SMS updates don't seem like engineering work. They're force multiplication. Fewer inbound calls means fewer customer service staff needed during surge. Aiden calls this "reducing support load with signal fidelity."
5. Multi-role design scales faster than single-role hacks. The system has three logins (homeowner, assessor, coordinator). Each role sees exactly what they need. Building three interfaces takes longer than one, but it runs cleaner, scales better, and has less cognitive load per user.
The Route Optimisation Overlap — Velocity X Connection
HailHero's routing algorithm is a smaller cousin of Velocity X's multi-stop route optimisation. Both solve: given a list of locations and a team of mobile workers, assign each location to the nearest worker, balance load, and minimize travel time. Velocity X is more sophisticated (it solves the Vehicle Routing Problem with time windows), but the core pattern is the same. The difference is context: HailHero routes claims to assessors; Velocity X routes job visits to field sales reps. The algorithm translates across both problems, which is why custom platform work compounds — each project informs the next.
Frequently Asked Questions
Can HailHero work for other types of claims?
Yes. The architecture is generic enough to handle car insurance, general liability, worker's comp — anything where you need to intake claims, assign to assessors/adjusters, track photos and evidence, and sync with a CRM. Hail is just the first vertical.
How do you handle assessor unavailability?
Assessors log in and set availability (on duty, on break, end of day). The routing engine checks that status before assigning. If an assessor becomes unavailable mid-route, a coordinator can reassign remaining claims via the dashboard. The Pipedrive deal stays linked so nothing drops.
What about SLA tracking?
HailHero logs timestamps for every state transition: claim received, routed, assessment started, assessment complete, sent to finance. Rebuild Relief's SLA is "assessor on site within 3 days of claim." The system flags claims that breach the SLA so a coordinator can escalate.
Is the homeowner portal public-facing?
Yes. They get a unique URL with no login — just claim reference + postcode (basic verification). We didn't require login because homeowners are stressed and might forget credentials. The trade-off is simpler auth, which is fine for non-sensitive operations like "check my claim status."
How much does custom claims tech like this cost?
HailHero's full build — forms, routing engine, assessor portal, homeowner portal, Pipedrive sync, and RLS infrastructure — was $35,000 AUD. That included design, development, testing, and integration work. Ongoing hosting on Supabase costs ~$200/month (scales with data volume, not user count). See our pricing packages for custom platform work in the $20–50K range. This specific project sits in the upper mid-range because of the routing complexity and Pipedrive integration.
Why Supabase instead of Firebase or another backend-as-a-service?
Three reasons: Supabase has row-level security built in (Rebuild Relief's team each see only their own claims), it's Postgres under the hood so complex queries are fast, and the pricing scales linearly with data, not concurrent users (during surge, you'd get killed on user-count pricing). Plus, Rebuild Relief's other internal tools already use Supabase, so we got schema consistency across the stack.
The Bottom Line — Custom Platform, Custom SLA
HailHero is a bespoke system built for Rebuild Relief's exact ops model. It wouldn't ship in three months with off-the-shelf tools, and it would cost 3x as much to maintain. Custom platforms cost more upfront but own the problem in a way templates never will. Rebuild Relief can now handle a 20x load spike, keep assessors and homeowners in sync, and feed data back to Pipedrive without manual work. That's worth the build. For the routing patterns that power multi-stop field operations, see the Velocity X deep dive.