This is part 1 of my dev blog series covering my journey in the Guidewire DEVTrails 2026 hackathon.
When we talk about the gig economy, the conversation usually stops at "getting food delivered faster." But as developers, it’s our job to look at the systems behind the apps we use every day.
For Phase 1 of the DEVTrails hackathon, I decided to tackle a massive unaddressed problem in the Indian gig economy: Income loss due to external climate disruptions. When severe monsoon rains or hazardous AQI levels force a city to a halt, a delivery partner doesn't just rest—they lose their daily wage.
Traditional insurance is reactive (filing claims, waiting weeks). I wanted to build a proactive, Parametric Insurance platform that pays riders instantly based on real-time weather APIs. We started Phase 1 under the project name GigShield.
Here is a look behind the scenes at how I approached the Phase 1 ideation and prototyping.
Architecture & The Tech Stack I needed to build a highly responsive, modern dashboard that could visualize complex data (like policies, risk scores, and weather triggers) seamlessly.
The Stack:
Frontend: Next.js 16 (App Router) + TypeScript
Styling: Tailwind CSS 4 with a dark, glassmorphic UI design
Data Visualization: Recharts for rendering premium trends and claim payouts
Icons: Lucide React
Using Next.js was a strategic choice. I needed SSR (Server-Side Rendering) capabilities down the line to seamlessly fetch and serve live API data from OpenWeatherMap and CPCB without exposing API keys or bottlenecking the client.
For Phase 1, my primary goal was to mock out the frontend context state heavily. I used the React Context API to simulate global state management for Workers, Policies, Claims, and Alert triggers so the prototype looked and felt like a living application.
The Core Problem: Dynamic Premium Calculation The hardest part of Phase 1 wasn't the UI—it was the math. How do you decide what a gig worker should pay weekly?
If a rider in Mumbai faces 15 days of severe flooding every monsoon, and a rider in Bangalore faces 3, charging them the same premium is deeply unfair.
I designed a 7-factor pricing model that simulates an XGBoost Machine Learning algorithm. Before writing any backend models, I built the logic directly into my TypeScript data structures to prove the concept: (Copy your code snippet here!)
By mapping out these specific variables, I created a Risk Profiling Engine that calculates a personalized risk score (0-100) for every user within 2 minutes of onboarding.
Modeling the Parametric Triggers The "magic" of this app is that the worker doesn't have to do anything to get paid. For the Phase 1 prototype, I engineered the data shape of what a "Parametric Trigger" would look like in code.
I defined 4 critical disruption categories we would monitor:
Weather: Heavy rain (>64mm/hr) or Extreme Heat (>45°C)
Environmental: Severe smog (AQI > 400)
Social: City-wide curfews or strikes
Platform: Server outages at Swiggy/Zomato
I mocked a triggerDisruption function in my Context provider. In the UI, clicking a "Simulate Rain" button dispatches an event that instantly scans all active worker policies in that zone, calculates their lost hours, and auto-generates a "Claim" with an auto-approved status.
Wrap Up: What's Next for Phase 2? Phase 1 was incredibly rewarding because it forced me to think like an actuary and a product manager before writing a single block of production backend code. The Next.js dashboard is fast, the Recharts analytics look beautiful, and the core dynamic premium math is sound.
However, during the transition into Phase 2, I realized that "GigShield" sounded too generic. I needed this to be a bolder, more opinionated product.
Spoiler Alert: For Phase 2, we are aggressively pivoting the brand to Floor—promising riders a baseline earning "floor." I'll also be replacing all these simulated triggers with live OpenWeatherMap and CPCB API calls.
Stay tuned for Dev Blog 2 where we dive into the backend and our 4-layer AI Anti-Spoofing engine!
Top comments (0)