How I AIHow a 91-year-old vibe coded a complex church event management system using Claude and Replit
CHAPTERS
Meet John Blackman: 91-year-old “vibe coder” building for community impact
Claire Vo introduces John Blackman, a 91-year-old church volunteer who used Claude and Replit to build a full event-registration and management system. John frames the real-world problem: Impact Weekends with many free services and a paper-based registration workflow that needed to scale.
- •Impact Weekends provide free services (haircuts, eyeglasses, food, car wash, etc.)
- •John managed registrations manually and wanted a computerized system
- •Claude was used to plan/build, and Replit was used to implement quickly
- •The project was built with help from grandsons and late-night building sessions
A career of learning: engineering, AutoCAD pioneer, and “growth mindset” arc
Claire shares John’s unusually broad background—electrical engineering, running a hardware store, airplane mechanic certification, AutoCAD adoption, fiber optic projects, and even helping with Google Fiber. The chapter sets up why John is comfortable learning new tools late in life and draws a parallel between AI today and AutoCAD adoption decades ago.
- •Worked as an electrical engineer and later ran a hardware store
- •Earned airplane mechanic certification; returned to engineering work
- •Early AutoCAD adopter and trainer; worked on early fiber projects
- •Came out of retirement for Google Fiber launches; still learning at 91
- •Mindset theme: leaning into change creates longevity and fun
How the church app idea started: turning handwritten workflows into software
John explains that the project began as a desire to stop writing everything by hand for registrations and event logistics. He drafted an outline of what he wanted, then sent it to Claude with explicit instructions to target Replit as the build environment.
- •Problem statement: registrations and logistics were manual and time-consuming
- •John wrote an initial outline in a Word document
- •They prompted Claude with the goal and specified “build it for Replit”
- •Grandson Brett influenced the tool choices and kickstarted momentum
Using Claude to create a roadmap and PRD-style requirements
The team begins with a broad prompt—asking Claude how to create a development roadmap—then lets Claude ask clarifying questions. From the outline and Q&A, Claude produces a structured MVP plan, phases, and a requirements-style document that can be handed off to an agentic builder.
- •Start broad: ask Claude for a roadmap, then iterate with Q&A
- •Explicitly tell the model to ask for missing info early
- •Claude outputs phased roadmap: admin interface, passport generation, data management
- •The output becomes a handoff artifact for Replit Agent
The “Impact Passport” concept: participant-facing artifact + QR-driven signups
John introduces the “Impact Passport,” inspired by another church’s paper process, as a printable guide for attendees that lists their chosen services/stations. The passport idea evolves into QR-code-based registration that makes it easy for participants to sign up from flyers and phones.
- •Passport originally existed as a hand-written paper carried at events
- •Goal: generate printable passports automatically from registrations
- •QR code enables quick access to the mobile registration form
- •Design ties participant choices (services) into a clear on-site flow
User stories and roles: designing for pastors, ministry leaders, and attendees
Claude generates user stories that John finds largely accurate, with minor edits as development progresses. The conversation highlights how the system must serve multiple stakeholders—participants, local church admins, system organizers, pastors—plus non-functional needs like usability and reporting.
- •User stories describe desired experience for each user type
- •Stakeholders include pastors and ministry leaders (follow-up and planning)
- •Non-functional requirements appear alongside feature specs
- •John refines stories iteratively as the build reveals edge cases
Multi-tenant architecture: system admins vs. local church admins (RBAC)
The app’s structure becomes notably sophisticated: a multi-tenant, role-based system where system administrators can see all churches and approve admins, while local church admins only see their own events and data. Claire calls out the complexity—this is a real “enterprise-style” access model built from a community need.
- •Two admin levels: system organizers (system admins) and local church admins
- •System admins can see all churches; locals are restricted to their own tenant
- •Admin approvals flow through the system level
- •Architecture supports multiple churches, events, and service configurations
From spec to build: handing Claude output to Replit Agent
John describes the handoff: copy Claude’s structured requirements into Replit, then let the agent generate the codebase rapidly. Claire notes the project’s “meaty” structure (docs, migrations, generated assets), signaling a full-stack application rather than a simple form.
- •Workflow: Claude PRD/roadmap → copy/paste into Replit Agent
- •Replit rapidly generates working code and project structure
- •The codebase includes migrations and generated assets (e.g., passports)
- •John validates outputs by running the app and providing feedback
Admin interface demo: managing churches, events, services, and participants
John tours the system admin login and shows how it drills into individual churches and events. Admins can view participants, toggle services on/off per event, and generate operational reports used both before the event and for pastoral follow-up after.
- •System admin can navigate across multiple churches/tenants
- •Event management includes participant lists and service availability toggles
- •Demographics report supports pre-event planning and post-event ministry follow-up
- •UI details: clear navigation and “toast” notifications for actions
Operational reporting deep dive: food pantry, vision center, oil-change logistics
The system produces specialized reports tailored to different service stations. Food pantry/lunch reports help order supplies; vision center reports capture participant details; waiver flows reduce liability; and oil-change reports combine check-in tracking with parts planning based on vehicle info.
- •Service usage report shows demand across stations (pantry, haircuts, etc.)
- •Food pantry/lunch report generates a shopping/order list (hot dogs, buns, etc.)
- •Vision center report includes relevant participant attributes (e.g., age)
- •Waivers are captured to protect the church and standardize consent
Participant registration flow: mobile-friendly forms, VIN lookup, waiver + signature
The participant journey starts with scanning a QR code, opening a mobile form, selecting services, and completing required fields. For oil changes, the app performs a lookup and then collects a waiver acknowledgement and a captured signature—ending with a completed registration.
- •QR code opens a mobile-friendly registration form
- •Participants enter contact info, choose services, and proceed step-by-step
- •Oil-change flow performs a lookup and returns oil type/quantity/filter info
- •Digital waiver review and signature capture complete the registration
Adding features after launch: volunteer tracking + name-tag generation
John explains how new needs emerge once the core system exists—like printing volunteer name tags on label sheets instead of using sticky notes and markers. The change requires extending the schema (new volunteer table/model) and adding new admin flows, which Replit Agent implements in large chunks.
- •New feature request: generate printed volunteer name tags for events
- •Requires introducing volunteer concepts and data models into the system
- •Replit Agent updates schema/migrations and builds admin input flows
- •Iteration pattern: run app, test, then instruct the agent to adjust
Managing AI “rabbit trails”: prompting, checkpoints, and stopping the agent
John describes the practical reality of agentic building: sometimes the AI goes off-track, so he intervenes with simple commands (“wait,” “stop”) and redirects. A key technique is reverting to a previously working point in history (a checkpoint mindset) and reapplying known-good code.
- •Agents can drift; users must recognize when to intervene
- •Simple corrective prompts (“stop,” “wait”) can prevent wasted work
- •Reverting to earlier working code/history helps recover from breakage
- •“Phone a friend” (grandsons) is the final escalation path
From development to production: deployment friction, PDFs, email attachments, secrets
The hardest problems appear during production deployment: behaviors that work in development may fail in production. John recounts debugging email delivery with attached passport PDFs (solved by changing PDF format) and ongoing issues with environment variables/secret keys (OpenAI key caching) affecting VIN lookup in production.
- •Dev/prod parity issues: features break after deployment
- •Emailing registrations with attached passport PDFs failed in production
- •Fix involved changing PDF generation/format (output differed vs dev)
- •Secrets management issue: old OpenAI key persists/caches in production
- •VIN lookup works in dev but fails in prod due to key mismatch
No prior coding background: why “no preconceived notions” can be an advantage
John clarifies he hasn’t coded traditionally (no TypeScript), aside from some logic scripting in CAD contexts. The group observes that not being opinionated about stack choices can help: John accepts the agent’s defaults and focuses on outcomes, while more experienced engineers may overconstrain the solution.
- •John’s prior “coding” was limited to CAD logic/automation, not modern app dev
- •He relies on agent recommendations for DB, email tooling, and integrations
- •Being less prescriptive can reduce friction with agentic workflows
- •Focus stays on user needs and functionality rather than “ideal architecture”
Cost, timeline, and real-world impact: a complex system built fast
John reports surprisingly low costs—hundreds of dollars total, with early rapid progress in the first two days—and contrasts it with estimates of months of traditional development. Church leaders are impressed, eager to use it, and the system promises to reduce admin burden while enabling better follow-up ministry.
- •Approximate spend: ~$350 total; early runs far lower
- •Two intense build sessions produced a large portion of the system quickly
- •Pastors were “blown away,” though rollout is pending final polish
- •Expected outcomes: less paperwork, better logistics, better ministry follow-up
Lightning round: product feedback for Claude/Replit and advice on embracing AI
John’s “asks” include smoother production deployments, better secrets management, and clearer UX for finding Claude chat history. He closes with practical optimism: AI can be scary, but used correctly it helps people and expands what volunteers can build—echoing how learning AutoCAD extended his career and enjoyment.
- •Key request: reliable dev-to-prod transitions and secrets management
- •Claude UX request: help users find chat history directly in chat
- •Advice: learn the tools—like AutoCAD—so you can keep working and having fun
- •Perspective: AI can do harm, but can do substantial good when guided well
