# #0006 QuickClaims

> What's missing from this insurance scope?

- Kind: case study
- Status: Active
- Entity: Rise Roofing Supplements · licensed
- Role: Design, build, run
- Stack: Next.js, Drizzle, Neon, Vercel
- Started: Jan 2026
- Platform: web
- Production deploys since Sep 1: 199 (since Jan 30), read live from Vercel
- Last deploy: 7 h ago (2026-10-17T00:22:11.484Z)
- In one line: A four-layer parser that reads carrier PDFs into structured line items at 99%, and an email engine that files correspondence to the right claim.
- Page: https://daltoncox.com/jobs/quickclaims

## Context

Roofing supplement teams read insurance scopes by hand and miss line items that pay. Rise Roofing Supplements wanted the reading done by software, with their people checking the result instead of producing it.

## Role

Design, build, run. One builder, one client, a standing rule that no work starts without a written proposal accepted by all four parties.

## Approach

A four-layer parser that reads the carrier's scope PDF into structured line items, then an email engine that files adjuster correspondence to the right claim by homeowner name and claim number.

## Solution

Scope in, line items out, with the subfolder hierarchy carriers use. Invoice billing with void. A client dashboard with live scope, roadmap, tickets and logged hours.

## Result

Parser at 99% on the client's scopes. Email triage at 95%. Licensed to the client; the parser architecture and training data stay reusable.

## Learned

The spec sheet beat the proposal. When the long-form plan read as fluff, a plain list of what ships and when was what the client could sign.

*Drawing: scope PDF in, line items fill. The clip replaces it when the screen ships.*

## Punch list (3 open)

- Parser handles multi-page supplements
- Email tool: per-user permission model
- Subfolder tabs replace the group-by-trade view