## Inspiration
Starting January 1, 2027, Indiana will enforce HIP work requirements for many members ages 19–64. The deadline is tighter than it looks: anyone applying in January must already show compliance for October, November, and December 2026. That lookback window is open now.
When Arkansas briefly ran Medicaid work rules, most people lost coverage not because they didn’t work — but because they didn’t submit paperwork correctly in time. Paperwork is what knocks people off.
Existing tools only solve one corner of the problem: employer timeclocks, nonprofit volunteer loggers, or the state’s pre-screener. Nothing pulls one person’s mixed evidence into one place — a DoorDash screenshot, a part-time paystub, and pantry volunteer hours. We built **80 Hours** to fill that gap.
## What it does
**80 Hours** is a proof builder for Indiana HIP (and eventually SNAP) work requirements.
1. **Upload** — Snap a paystub, gig earnings screen, or volunteer sheet from your phone.
2. **Extract** — Gemini vision turns the image into structured evidence (hours, pay, dates, source).
3. **Confirm** — You review and fix any field before it counts. AI assists; you decide.
4. **Track** — Monthly dashboard toward **80 hours** or **$580** earnings (or half-time school).
5. **Exempt?** — A soft quiz that may suggest you *might* be exempt, with a link to FSSA’s official pre-screener. We never say “you are exempt.”
6. **Proof packet** — One-click PDF with month summary, evidence table, totals, and a clear disclaimer — prep evidence, not a filing.
Privacy by design: images are processed in memory and not saved on a server. Evidence lives in localStorage on your device.
> This is **not** an official FSSA tool. Always confirm status and report through [FSSA](https://www.in.gov/fssa/hip/hip-work-requirements/).
## How we built it
- **Next.js (App Router) + TypeScript** for UI and API routes in one repo
- **Tailwind + shadcn/ui** for a fast, mobile-first interface
- **Google Gemini** (vision + structured JSON) via `/api/extract` to read stubs, gig screens, and handwritten sheets
- **Zod** to reject bad AI output before it hits the tracker
- **`lib/rules.ts`** - a pure TypeScript rules engine for hours, $580 earnings, school path, days left, and at-risk status (with Vitest coverage)
- **`@react-pdf/renderer`** for in-browser PDF proof packets
- **localStorage** only - no server database of pay stubs
- **Vercel** for hosting so judges can scan a QR and demo on their phones
- **GitHub Actions** for lint, typecheck, test, and build on every push
- **`RULES.md` + `DECISIONS.md`** so hard numbers and product overrides stay cited to FSSA, not invented by the model
## Challenges we ran into
- **Trust language** - We had to resist saying “you meet requirements” or “you are exempt.” Soft estimates + official FSSA links only.
- **AI extraction is messy** - Paystubs and gig screens vary wildly. We required a human confirm step, Zod validation, and SSN/account-number redaction before anything counts.
- **Cross-month pay periods** - A stub spanning Oct 28–Nov 10 has to be split correctly across months without inventing hours.
- **Domain accuracy under time pressure** - Every threshold (80 hours, $580, lookback, exemptions) had to come from FSSA sources in `RULES.md`, not from guessing.
- **Privacy without a backend** - Keeping evidence on-device meant designing the whole flow around localStorage while still shipping a live demo.
## Accomplishments that we're proud of
- A working end-to-end phone flow: camera → Gemini extract → confirm → dashboard → PDF packet
- A rules engine grounded in cited FSSA numbers, with Vitest coverage for the numeric paths
- Privacy-first design: no server-side storage of pay stubs; redaction for sensitive numbers
- A Maria demo + fake fixtures so judges can try the product without uploading real documents
- Clear product guardrails (`RULES.md`, `DECISIONS.md`, Cursor rules) so the AI doesn’t hallucinate benefits policy
## What we learned
- Paperwork failure - not work failure - is the real coverage risk for work-requirement programs.
- For benefits-adjacent tools, **copy and confidence language matter as much as features**.
- Structured AI output only works if humans stay in the loop and schemas catch bad fields.
- Treating policy docs as source of truth (`RULES.md`) keeps a hackathon prototype from becoming dangerous guesswork.
## What's next for 80 Hours
- Extend the same 80-hour engine to **SNAP** reporting support
- SMS reminders (“18 hours to go, 9 days left”) via Twilio
- Partner with clinics and benefits navigators for assisted intake
- Keep iterating on extraction accuracy with more fixtures and eval scoring
We are table number 4.