I never thought my first real hackathon would involve insurance law, AQI thresholds, and wondering if a Zomato delivery guy in Chennai can afford to take a day off when it floods.
But here I am.
The Problem We're Solving
Guidewire DEVTrails 2026 gave us a deceptively simple prompt: protect India's gig delivery workers from income loss due to external disruptions — extreme weather, pollution spikes, natural disasters.
Not health insurance. Not vehicle repair. Specifically lost income — because when it rains so hard that Swiggy shuts down orders, the delivery worker still has rent due on Sunday.
These workers operate on weekly pay cycles. No work = no pay. And they have zero safety net.
That clicked for me personally. I've seen delivery riders push through waterlogged roads. They don't stop because they can't afford to.
What We're Building
It's called a parametric insurance platform — which, before this hackathon, I had to Google.
Parametric insurance doesn't ask you to prove your loss. Instead, it watches external data signals — if AQI crosses a threshold, if wind speed exceeds X, if a flood alert is issued — and automatically triggers a payout. No claim forms. No waiting. Just money in your account when the city decides to fall apart.
Our system has five main pieces:
Risk Assessment Engine — ML model that calculates a personalized weekly premium per worker
Parametric Trigger Monitor — watches live weather/AQI data and fires claims automatically
Fraud Detection Layer — GPS spoofing detection, anomaly detection, duplicate prevention
Payout Processor — hooks into a mock Razorpay/UPI gateway for instant settlement
Dual Dashboards — one for workers (policy + claim history), one for admins (risk + fraud alerts)
The Competition Pressure Is Real
This isn't a casual build. The hackathon runs 6 weeks, with three phases. Late delivery by 3+ days = elimination. Bottom 25% of teams cut after every phase.
There's also a coin economy (DEVTrails Coins) that simulates real startup burn rates — Phase 3 alone costs DC 36,000/week. It's designed to make you feel the pressure of resource constraints alongside technical ones. I'll be honest, it works.
What I've Learned So Far:
- You'll build things you don't fully understand yet. The fraud detection module — GPS spoofing detection specifically — I built it by reading papers and adapting patterns. It runs. I couldn't explain every decision in it under pressure. That's a weird feeling.
- Scope is a trap. We wanted to cover all three delivery personas (food, e-commerce, q-commerce). The rules said pick one. We picked food delivery. That constraint saved us probably two weeks of confusion.
- "Mock acceptable" is your best friend. Almost all our external integrations (weather API, payment gateway, delivery platform data) are mocked or on free tiers. The judges want to see the architecture work — not production-grade API keys.
What's Left
Phase 3 deadline is April 17. Still to ship:
Tighten fraud detection (anomaly scoring isn't where I want it)
Wire up the mock payment flow end-to-end
Build the admin dashboard (currently the most unfinished piece)
Record a 5-minute demo video that doesn't make me cringe
Write a pitch deck
Why I'm Writing This Now
Because this is the part nobody usually documents — the middle, when things half-work and you're not sure if you're on track. Most dev blog posts are written in hindsight, polished, with the answer already known.
I'm writing this from the middle of it. I don't know if we'll make it to Phase 3. I don't know if the ML model is good. I know the parametric trigger fires correctly and I know what I'm building and why — and right now that feels like enough to keep going.
If you're building something similar, or just figuring out your first real project — I'd love to connect. We're probably in the same boat.
This post is part of my Guidewire DEVTrails 2026 build log. More updates as Phase 3 unfolds.
Top comments (0)