The Problem That Started It All
Every morning, millions of delivery partners across India strap on their helmets, fire up Zomato or Swiggy or Zepto, and head out to make a living. They are the invisible infrastructure of the Indian digital economy — the last mile between a kitchen and your door, between a warehouse and your apartment, between a dark store and your dinner table.
And they are completely, utterly unprotected.
"External disruptions can wipe out 20–30% of a gig worker's monthly income. When that happens, they bear the full loss alone. There is no safety net."
Not a metaphorical safety net. A literal one.
When a cyclone hits Chennai, when the AQI in Delhi crosses 400, when a local strike shuts down an entire delivery zone — the delivery partner simply doesn't earn. There's no sick leave, no compensation, no claim to file. The work disappears and so does the income.
This is the problem Guidewire DEVTrails 2026 asked us to solve.
What Is DEVTrails?
DEVTrails is Guidewire's university hackathon — a six-week structured engineering challenge that takes student teams from ideation all the way through to a production-grade prototype.
The theme this year: AI-powered insurance for India's gig economy.
🗓️ Duration6 weeks, 3 phases👥 PersonaPlatform-based delivery partners💸 Coverage scopeIncome loss only📅 Pricing modelWeekly premiums
This isn't a weekend sprint where you duct-tape a demo together. The challenge is structured with submissions, evaluation, and feedback at each checkpoint. By the end, you're expected to have a real, working platform.
The Technical Challenge, Unpacked
The brief sounds deceptively simple: build an AI-enabled parametric insurance platform for delivery workers. But the constraints are where it gets interesting.
What "Parametric" Actually Means
Traditional insurance pays out when you prove a loss. You submit documents, an adjuster investigates, and weeks later you might get a cheque. That model doesn't work for someone who needs money on Friday to pay rent.
Parametric insurance is different.
Instead of proving a loss, you define a trigger — a measurable external event. When that event is detected, the payout happens automatically. No claim. No adjuster. No waiting. The data does the work.
IF rainfall > 50mm in zone X
AND worker is registered & active policy
THEN → auto-initiate payout for lost hours
For gig workers earning week to week, this is the only insurance model that actually makes sense.
The Disruptions We Need to Detect
TypeExample EventsImpact🌧️ EnvironmentalExtreme rain, floods, heat waves, severe pollutionCannot work outdoors — deliveries halt🚧 SocialUnplanned curfews, local strikes, zone closuresCannot access pickup/drop locations
Important clarification from the problem statement: We are insuring income loss, not the cause of it. If it rains and a worker loses 6 hours of earning time, we compensate those 6 hours. We do NOT cover vehicle repair, health, accidents, or anything that happened to the worker physically. Only lost wages.
Hard Constraints (Non-Negotiable)
❌ No coverage for health, life, accidents, or vehicle repairs — income loss only
📅 Premium model must be weekly — gig workers earn and spend week to week, not monthly
🎯 Must choose one segment: Food (Zomato/Swiggy), E-commerce (Amazon/Flipkart), or Grocery/Q-Commerce (Zepto/Blinkit)
What the Platform Needs to Do
The technical requirements read like a product spec for a real fintech startup. Four major capabilities:
1. 🤖 AI-Powered Risk Assessment
Dynamic weekly premium calculation driven by hyper-local risk factors. A worker in a flood-prone pincode in December pays more than one in a historically dry zone. The model adapts in real time based on:
Historical weather patterns for the zone
Pollution/AQI index
Strike and curfew history
Traffic disruption data
**
- 🔍 Intelligent Fraud Detection** Anomaly detection on claims, GPS and location validation, and duplicate claim prevention. The system needs to know when someone is gaming it:
GPS spoofing (claiming to be in an affected zone while elsewhere)
Claiming during active delivery sessions
Multiple accounts for the same individual
Fake disruption claims using historical data
3. ⚡ Parametric Automation
Real-time trigger monitoring via public APIs. When a threshold is breached, claims initiate and payouts process automatically — zero human in the loop.
Example triggers we're thinking about:
rainfall > 50mm → heavy rain disruption
AQI > 300 → severe pollution event
temperature > 45°C → extreme heat disruption
curfew_flag = true → social disruption
4. 🔗 Integration Stack
Weather APIs — free tier or mocks acceptable
AQI/Air quality feeds — real or simulated
Traffic data — mocks acceptable
Payment gateways — Razorpay test mode, Stripe sandbox, or UPI simulators
The Six-Week Roadmap
Unlike most hackathons, DEVTrails has staged submissions that force you to build incrementally.
📍 Phase 1: Ideation & Foundation
March 4 – 20
Research, persona definition, tech stack decisions, and a minimal working prototype. Deliverables include a GitHub README detailing the full strategy, a 2-minute pitch video, and the initial codebase.
📍 Phase 2: Automation & Protection
March 21 – April 4
Working registration flow, policy management, dynamic premium calculation, and claims management. The goal: a seamless, zero-touch claim experience. Build 3–5 automated disruption triggers using real or mock APIs.
📍 Phase 3: Scale & Optimise
April 5 – 17
Advanced fraud detection, simulated instant payouts, intelligent dashboards for both workers and insurers, a 5-minute demo video, and a final pitch deck. This is the judging phase.
Why This Problem Is Actually Hard
On the surface, "pay workers when it rains" sounds straightforward. The complexity lives in the details.
The Income Baseline Problem
To calculate what someone lost, you need to know what they would have earned. Gig income is wildly variable — it differs by city, zone, time of day, day of week, platform, and individual performance. Establishing a reliable baseline without over-engineering it is a genuine ML challenge.
The Fraud Surface Is Massive
Parametric triggers are great for automation but dangerous for abuse. If rainfall > 50mm triggers a payout, someone will figure out how to claim while still working, or claim in a region they weren't in. The fraud detection layer isn't an afterthought — it's what makes the whole system viable.
Weekly Pricing on Variable Risk
The premium must be affordable — gig workers won't pay for something that feels abstract. But it must also be actuarially sound. Too cheap and the insurer bleeds money in monsoon season. Too expensive and nobody subscribes. Getting this right requires real thinking about loss ratios, seasonal risk curves, and zone-level historical data.
Trust, in an Untrusting Market
Gig workers have been promised things before — by platforms, by government schemes, by financial products — and those promises have often been broken. Any experience that feels complicated, opaque, or corporate will fail immediately. The onboarding, the payout notification, the weekly renewal — every touchpoint has to be designed for someone on a 5-inch screen, on 4G, with three minutes between deliveries.
Where We Are Right Now
We're in Phase 1 — the ideation and foundation sprint.
Right now the work is about:
Defining the delivery segment sharply
Mapping the exact parametric triggers we'll build around
Finalising the tech stack (React Native for mobile, Python/FastAPI for the backend)
Laying down the architectural groundwork that the next four weeks build on
The Phase 1 deadline is March 20. After that, the build gets real.
There's something unusual about working on a problem like this. Most hackathon problems are technically interesting but emotionally neutral. This one has actual stakes.
The people we're designing for — the delivery partner on a flooded street in Chennai, the Swiggy rider who loses a full day's earnings to a curfew he didn't know was coming — they exist. They lose money. Every week.
That makes the technical decisions feel less like puzzles and more like responsibilities.
Top comments (0)