Team projects: what I try to do, from building GigShield with two teammates

GigShield is a parametric income-insurance platform for delivery riders. It was a team of three, built with Rishabh and Abhinav, so the credit isn't mine alone. I'll say that every time I talk about it.

This post is about what the project is, which pieces I built, and what I try to do on team projects. Some of those lessons are things I did; some are things I now try to do. I'll be clear about which is which.

The problem

Delivery riders in India are paid weekly and live on thin cash buffers. One day of heavy rain, a hazardous air-quality reading or a platform outage can wipe out a day or two of income. Traditional insurance, with its paperwork, adjusters and reimbursement weeks later, doesn't fit a loss that small and that sudden.

Our answer was parametric cover: instead of reimbursing a loss after someone proves it, it pays a fixed amount automatically when an objective, external signal crosses a threshold.

We priced it the way riders think about money, weekly:

Plan	Weekly price
Basic	₹79
Standard	₹129
Pro	₹179

Each plan has its own daily payout cap and covered hours. The product deliberately covers lost earning hours only: no health, life, accident or vehicle cover.

My part

The role line from the case study, for accuracy: I built the trigger engine, the payout lifecycle and receipts, the rider dashboard, the admin and fraud-review screens, role-based routing and the 3D landing page. The liveness check was built together with Rishabh. Rishabh and Abhinav built most of the authentication, the Express server and the help chat.

The trigger engine

It watches for seven kinds of disruption: heavy rain, heatwave, AQI spikes, platform outages, curfews, local strikes and zone closures. Rather than a bare yes/no, each trigger gets a confidence score, built from:

• a base value per trigger type,
• how reliable the weather data source was,
• and the rider's risk profile (higher risk lowers confidence).

The score maps to a label: Strong, Normal or Weak. In sketch form:

function triggerConfidence(base: number, sourceReliability: number, riderRisk: number) {
  const score = base * sourceReliability * (1 - riderRisk * 0.3);
  if (score > 0.75) return 'Strong';
  if (score > 0.5)  return 'Normal';
  return 'Weak';
}

(That's illustrative. The real thresholds are in the repo. They're reasonable guesses, and I'll explain why that matters below.)

Weather comes from Open-Meteo, with a 2.5-second timeout and an automatic fallback to wttr.in. That way one flaky API can't quietly stop the engine. Cooldown and de-duplication windows stop a single storm from firing again and again, and every trigger is written to an audit trail that syncs to the backend.

Payouts and fraud

A claim moves through a visible lifecycle, pending verification → verified → processing → settled, and riders get a downloadable PDF receipt. In this build payouts are simulated; there's no real payment rail connected.

For fraud, we built a liveness check on risky sessions: the app asks for a random hand gesture, and MediaPipe's hand-landmark model classifies it right in the browser.

What I try to do on team projects

These are practices I'm working towards, informed by this project. I'm not claiming a perfect record.

Split by interface, not by file

Agree the contract between the pieces first (what data crosses the boundary, in what shape), then build each side independently. "You do the frontend, I'll do the backend" fails when nobody has defined what the frontend sends.

Write the contract down

Even a messy README beats arguing in chat. A written contract can be pointed at; a remembered one gets reinterpreted.

Merge small, merge often

Integration pain arrives all at once if you wait. Small merges turn one big collision into many tiny ones.

Agree what "done" means

"Works on my machine" can mean three different things to three people. Agree upfront: does it mean deployed? Tested? Reviewed?

A trap I watch for

Taking over the hard part because it's faster than explaining it. It's a short-term win and a long-term loss for the team. The teammate who never gets to struggle with the hard part never learns it.

What I'd flag as limits

The case study lists these honestly, and they apply here too:

• Trigger cooldown and de-duplication state lives in the browser's storage, which is fine for a demo but belongs on the server in anything real.
• Payouts and parts of the fraud workflow are simulated.
• The thresholds are reasonable guesses. Calibrating them properly would need historical weather and earnings data we didn't have.

If you're starting a team project

1. Agree the contract.
2. Merge small, merge often.
3. Write down who owns what.
4. Credit everyone, publicly, by name.

A one-page team contract

Fill this in at the start of any team project. It takes ten minutes and prevents hours of argument.

PROJECT:           ______________________
GOAL (one line):   ______________________
DEADLINE:          ______________________

OWNERS
  Frontend:        ______   Backend:    ______
  Data / schema:   ______   Deploy:     ______
  Docs / demo:     ______

CONTRACTS
  API shape agreed in: ______ (file / doc link)
  Branch strategy:     main + short-lived feature branches
  Merge rule:          at least one review, merge daily

DEFINITION OF DONE
  [ ] works on the deployed URL  [ ] reviewed  [ ] README updated

IF WE DISAGREE
  Each side writes 3 lines. Pick the option that is easiest to reverse.

A tiny API contract example

Agree on the exact shape before building either side:

// POST /api/claims
// request
{ "riderId": "r_123", "triggerType": "heavy_rain", "triggeredAt": "2026-06-01T08:00:00Z" }

// response 201
{ "claimId": "c_456", "status": "pending_verification" }

// response 409 (duplicate within cooldown)
{ "error": "duplicate_trigger", "retryAfterMinutes": 180 }

(This is an illustration of the format, not GigShield's actual API.) Once both sides agree, the frontend can mock it and the backend can implement it in parallel.

Handling disagreements

Disagreements are normal. Some approaches that help:

• Separate the decision from the person. Argue about options, not people.
• Prefer reversible decisions. If it's easy to undo, just try it.
• Time-box debates. Fifteen minutes, then decide.
• Write down the decision and the reason, so it isn't re-litigated next week.

Teaching while you build

The trap I mentioned, taking over the hard part, has a better alternative:

1. Pair on the first one. Do the hard task together, once.
2. Let them drive. You narrate; they type.
3. Review rather than rewrite. Comment on their version instead of replacing it.
4. Celebrate the learning, not just the result.

It's slower for a day and faster for a month.

Crediting people

On a portfolio or a post, a good credit line states the team size, the names, and which part you built. For GigShield, that's a team of three with Rishabh and Abhinav, and the case study says exactly which parts I built. It's accurate, and it makes your own claims more believable.

What's your best tip for team projects that don't implode?