How I AIHow a 91-year-old vibe coded a complex church event management system using Claude and Replit
CHAPTERS
- 0:00 – 2:41
Impact Weekend problem: replacing paper registrations with a real system
John explains the church’s “impact weekend” events and the pain of running registrations by hand. He outlines how a simple wish—“have it in the computer”—became a full app built with Claude and Replit.
- •Impact weekends provide multiple free services (haircuts, eyeglasses, car wash, food, etc.)
- •John managed event registrations manually and wanted a scalable digital workflow
- •They drafted an outline, sent it to Claude, and targeted Replit for implementation
- •Early hint at the system’s admin controls, participant list, services, and reports
- 2:41 – 5:16
Meet John Blackman: 91-year-old lifelong technologist and growth mindset
Claire introduces John’s unusually diverse technical and entrepreneurial background, showing a pattern of embracing new tools. John’s personality and curiosity set the stage for why he could successfully “vibe code” without prior software experience.
- •Career highlights: electrical engineering, hardware store, airplane mechanic certification
- •Early adopter and trainer of AutoCAD; worked on fiber optic and Google Fiber projects
- •Continues learning into his 90s, including owning Bitcoin
- •Framing: adopting new tech keeps you productive and engaged for decades
- 5:16 – 5:57
Project kickoff: from a Word doc to Claude (and an all-night build)
John and his grandsons turn the idea into action by prompting Claude to ask clarifying questions and produce a plan. They work late into the night, reflecting the iterative, high-energy style of modern vibe coding.
- •They started with a broad prompt (roadmap) and let Claude pull requirements via Q&A
- •John explicitly told Claude to ask questions whenever information was missing
- •Replit was chosen based on grandson recommendation
- •Two intense work sessions: 10pm–3am, then 10am–5pm the next day
- 5:57 – 7:29
Turning event operations into a roadmap: MVP scope, phases, and flows
The conversation moves from ideas to structured product planning. Claude outputs an MVP feature set and phased development plan, creating a clear blueprint for what to build first and what to add later.
- •Claude produces an MVP plan including admin interface, passport generation, and data management
- •Requirements are captured as a step-by-step user journey (registration and service selection)
- •Emphasis on converting manual workflows into software-supported processes
- •Roadmap structure enables direct handoff to a coding agent
- 7:29 – 8:42
The “Impact Passport” concept: participant guide + printable artifact
John explains the inspiration for an “impact passport” based on another church’s process. The passport becomes a central UX element: a printable, service-by-service checklist that guides participants through event stations.
- •Passport originated as a hand-carried paper sheet used at similar events
- •Goal: auto-generate and print passports instead of handwriting them
- •Passport reflects the services a participant selected during signup
- •Sets up later QR code and PDF generation features
- 8:42 – 10:32
User stories & requirements: multi-user product thinking with Claude
Claude helps translate the church’s needs into user stories, including multiple stakeholder perspectives. John confirms they were largely accurate, requiring only small edits during implementation.
- •User stories cover participant registration and administrative management tasks
- •They consider acquisition channels (Facebook, flyers, neighborhood brochures)
- •Requirements include pastor/ministry follow-up needs, not just event logistics
- •Non-functional requirements appear, demonstrating real product rigor
- 10:32 – 12:51
Multi-tenant, role-based access: system admins vs local church admins
The app’s architecture is clarified as a multi-tenant system with hierarchical permissions. System admins can oversee all churches and approve administrators, while local admins are restricted to their own church’s events and data.
- •Two key roles: system (impact organizers) and local church administrators
- •Visibility is hierarchical: system admins can see all; local admins see only their church
- •Admin approval flow is centralized at the system level
- •This complexity is notable given John’s lack of formal software background
- 12:51 – 14:07
From PRD to Replit: “bloo-whoop” agent build and codebase tour
John describes copying Claude’s output into Replit Agents and watching it generate the application quickly. Claire highlights the breadth of the codebase, including migrations and generated assets, indicating a substantial app.
- •Workflow: copy Claude’s requirements into Replit Agent and let it implement
- •John is surprised by the speed and autonomy of the agent
- •Claire notes real app structure: docs, migrations, and generated passport assets
- •Sets up the guided demo of the system administrator experience
- 14:07 – 15:39
Admin demo: event management, toggled services, and pastor-ready demographics
John walks through the system admin interface and how it manages multiple churches and events. He shows participant lists, service toggles, and a demographics report used both for planning and post-event ministry follow-up.
- •System admin can access and manage multiple churches from one dashboard
- •Local admins (in practice) handle participant management per church/event
- •Services can be turned on/off depending on what’s offered at a specific event
- •Demographics report includes contact info and party size; used for planning and ministry follow-up
- 15:39 – 20:26
Operations reports: service usage, food pantry/lunch, vision center, and waivers
The app generates specialized reports tailored to each service, supporting real procurement and staffing needs. John explains outputs for service utilization, food ordering, vision center intake, and legal waivers.
- •Service usage report quantifies demand across services to improve planning
- •Food pantry + lunch reports produce itemized ordering lists (hot dogs, buns, etc.)
- •Vision center report provides participant details like age for onsite staff
- •Waivers are captured to reduce liability and standardize consent
- 20:26 – 21:49
Participant registration flow: QR code entry, mobile form, VIN lookup, e-signature
The participant experience is demonstrated end-to-end, starting from scanning a QR code to completing registration. A standout feature is the oil-change VIN lookup via an OpenAI API call and an integrated waiver + signature capture flow.
- •QR codes on flyers/brochures open a mobile-friendly registration form
- •Participants choose services (e.g., eye clinic, oil change) during signup
- •VIN lookup returns oil type, quantity, and filter info via OpenAI API
- •Waiver text auto-fills and participants sign digitally to complete registration
- 21:49 – 24:10
Adding features midstream: volunteer name tags and schema changes via agent
John describes ongoing enhancements, including generating volunteer name tags that print on label sheets. The feature requires adding a new volunteer concept and database table, with Replit implementing large changes from a single prompt.
- •New feature: volunteer name tag generation to replace sticky-note markers
- •Requires new data model/table and admin input flow for volunteers
- •Agent performs substantial autonomous implementation with minimal back-and-forth
- •John tests, then provides corrective feedback when behavior is wrong
- 24:10 – 26:09
Managing agent “rabbit trails”: checkpoints, stop commands, and iteration
John shares practical techniques for steering the agent when it goes off-track. He uses simple, human-style instructions (“wait,” “stop”) and often returns to earlier working versions when changes break the app.
- •Agents can wander; John actively monitors and intervenes
- •He tests when the agent claims it’s done and reports failures back to it
- •Uses explicit stop/reset instructions to redirect work
- •Relies on “go back in history to a working point” to recover functionality
- 26:09 – 27:38
Production hurdles & tooling feedback: dev vs prod differences, secrets, and UX
The hardest challenge is production parity—features that work in development failing after deployment. John describes issues with emailing PDF passports and OpenAI key management, plus UX feedback for Claude’s chat history discoverability.
- •Dev/prod mismatch: PDF attachments failed in production until changing PDF format
- •Emailing passports to participants is critical for reducing onsite workload
- •Secrets management issue: old OpenAI key persists, breaking VIN lookup in production
- •Tooling UX request: Claude should better surface/point to chat history sidebar
- 27:38 – 40:28
No prior coding, big results: cost, timeline, community impact, and advice
John confirms he hadn’t written modern code before, yet built a multi-feature system with low spend and fast iteration. He reflects on the value of being open-minded, shares the church’s reaction, and offers lessons on embracing new technology like AutoCAD before it.
- •John’s coding background was limited to simple AutoCAD logic—not TypeScript/app development
- •Total spend around $350; early prototype cost was relatively low for the output
- •Church leaders are amazed; launch pending as John keeps polishing features
- •Advice: learn the new tools to stay effective and have fun; use AI to reduce manual work and expand impact
