Mission 22: Taking an AI-Built Prototype to Production

Project context

Mission 22 works with veterans and their families, and much of that work runs through volunteer ambassadors organized by state and region.

The Forge is the platform those ambassadors use to talk and run events. The first version was built quickly with AI coding tools. It showed what the platform should do. It needed real engineering before a nonprofit could put its volunteers on it.

What we built

Messaging. Channels by state, region, and group, one-to-one and group DMs, unread states, media sharing, optimistic delivery so messages appear instantly, and notifications.

Events. Approvals, check-ins, venue mapping, cancellations, merch and activity tracking, and review queues scoped to each leader's region.

Admin and moderation. User provisioning, audit history, reports, warnings and appeals, chat and media moderation, email campaigns, and schema drift checks that catch database changes before they break production.

Integrations. Airtable sync for ambassador and operations data, email through Resend, scheduled jobs and webhooks, and staging deploys on Vercel.

Launch readiness. Playwright tests running against Supabase, incident fixes, and skeleton loading states.

Prototype to production

AI tools are good at producing screens. They are much worse at the parts that keep real users safe. For The Forge that meant:

• role-based access enforced with Postgres row-level security, so permissions hold even if the UI has a bug
• a database schema built for real data, with schema drift checks
• end-to-end tests before launch instead of after
• moderation and audit tools for the Mission 22 team

Stack