Building Trade Sentries: lessons from shipping an AI-powered contractor AMS

Trade Sentries is a contractor-focused agency management system we built for an insurance agency serving the Placer County trade economy. It’s been in production for over a year. This is a candid breakdown of how it came together — what worked, what didn’t, and what we’d do differently if we started today.

The starting point

The agency came to us with a specific pain: managing certificate of insurance (COI) renewals, contractor license tracking, and policy paperwork at scale, with a 4-person back office, using a stack of Google Sheets, Outlook folders, and a generic AMS that didn’t fit their niche.

The pain wasn’t theoretical. Three months before we started, the agency had nearly lost a major commercial client because a COI expiration slipped through the spreadsheet cracks and the contractor lost site access for two weeks. The renewal saved at the eleventh hour; the trust did not fully recover.

Their ask: software that made these failures impossible.

What we built (high level)

The production system handles:

• Contractor profiles with all coverages, license numbers, bond information, and historical documents in one place.
• Job assignment tracking — which contractors are working on which client job sites, with the specific insurance requirements per site.
• COI lifecycle management — automated tracking of issuance, expiration, renewal, and re-issuance to specific GCs on request.
• Renewal automation — daily review of every contractor’s expiring coverages, automated outreach drafted in the agency’s voice.
• Document intake with AI extraction — incoming certificates, licenses, and forms get processed automatically into the system with confidence scoring.
• Audit log for everything — every document received, every renewal touched, every change to a contractor record.

The system runs on Cloudflare Workers + D1 + R2 with OpenAI handling the document extraction. Total monthly operating cost is in the low hundreds.

What worked

A few choices we’d make again without hesitation.

Discovery before code

We spent the first 4 weeks (paid) doing nothing but observing the back office in operation. No screens. No demos. Just sitting next to the staff doing the work, asking why, and writing down what we saw.

This produced a 32-page workflow document that became the spec for the build. It also produced humility: the agency owner described the workflow one way, and the actual work was meaningfully different. Without observation, we’d have built the described workflow and shipped software nobody used.

Cloudflare for the whole stack

D1, R2, Workers, KV, Cron — all on one account with one billing relationship and consistent APIs. We’ve used AWS for past projects of this shape and the integration friction alone consumed 30% of our time. Cloudflare cut that to under 5%. (We wrote up the broader stack rationale here.)

AI as a focused tool, not a foundation

We were deliberate about where AI showed up. Three specific jobs: document extraction, email classification, and outreach drafting. Everything else is conventional software — the data model, the business logic, the UI, the workflow engine. This matters because AI is genuinely the right tool for those three jobs and the wrong tool for everything else.

The mistake we see in other “AI-powered” tools: AI woven through every screen as a chat assistant, when most users want a clear UI they can master, not a conversation. Trade Sentries has zero chat surfaces. AI runs in the background.

Audit log from day one

Regulated workflows require audit logs. We built the audit log in the first week, before any user-facing feature. This made everything else cheaper — instead of retrofitting auditability into existing features, every feature was audit-aware from creation.

What didn’t work

The honest part.

The first data model was wrong

Our first schema modeled contractors as standalone entities with coverages attached. Two months in, observing real usage, we realized that the actual unit of work was the “contractor-on-a-specific-job-site” relationship, with separate compliance requirements per pairing. A contractor working on three different commercial job sites might need three different COIs — same contractor, different requirements per site.

We rewrote core schemas in week 9, lost roughly 3 weeks of progress, and shipped a system that actually matched the work. The lesson: even with good discovery, the data model becomes more accurate as the team uses the system. Plan for one significant schema migration in the first 90 days.

We over-engineered the first UI

The first attempt at the contractor detail page tried to show all possible information about a contractor on one screen. The agency team’s actual workflow needed quick scan-and-act views, not comprehensive views. We rewrote the UI for “what does this user need to do right now” rather than “what could this user possibly want to know.”

The lesson: defaults should match the most common job, not the most thorough audit.

The first AI extraction prompts were too clever

We initially tried to extract every possible field from incoming COIs in one prompt. Accuracy was a respectable 88%. We split it into three smaller prompts (carrier info, coverage info, named insureds) and accuracy jumped to 97%. Smaller, focused prompts beat ambitious, comprehensive ones almost every time.

We waited too long to ship to real users

We polished for 3 extra weeks before letting the back office use the system on real data. Every one of those polish items was rendered irrelevant or wrong by what we learned in week 1 of real use. We should have shipped a rougher version 3 weeks earlier and learned faster.

What we’d do differently

If we were starting today:

1. Ship a vertical slice to one user in week 3 or 4. No “v1.” Just one user, one workflow, real data.
2. Plan for one major schema migration in month 2 or 3. Build the migration tooling early.
3. Start with the smallest possible AI surface. One prompt, one job. Add second use cases only after the first proves itself.
4. Charge for discovery separately and explicitly. This protects both sides — the client gets a real spec, the builder doesn’t subsidize requirements work in the build budget.

The result, plainly

Trade Sentries has been in production for over a year. The agency has:

• Reduced administrative headcount per active policy by ~35%
• Eliminated COI lapse incidents (which were happening 4–6 times/year)
• Grown the active book of business by ~28% with the same team size
• Onboarded new staff in ~3 weeks instead of ~10

The total project cost was in the $150,000 range over 9 months. The labor savings in year 1 alone were ~$140,000. The growth-attributable revenue is harder to attribute precisely but is materially larger.

That’s the actual product: not “AI for insurance,” but “an agency that does more with the same team.” AI is one tool among several that made it possible.

Whether this fits your situation

If you run a contractor-serving business, a small agency in a regulated category, or a back-office operation that lives in spreadsheets, you might have a Trade-Sentries-shaped problem. The signals:

• 4–25 staff with at least one full-time administrative role
• Documents (certificates, forms, contracts) flowing in regularly
• Renewal cycles your business genuinely tracks
• A spreadsheet count in the dozens, not the single digits
• A clear primary decision-maker willing to be in the room for discovery

If that sounds like your operation, reach out. We’ll have a 30-minute call and tell you honestly if it’s a fit.