How I AI: How a 91-Year-Old Vibe-Coded a Complex Church App with Claude and Replit

A 91-year-old retired electrical engineer replaced handwritten church event logistics with a multi-tenant web app built through Claude and Replit. John Blackman now runs QR-code registration, automated reports, role-based admin access, PDF passports, and VIN-powered oil change planning for outreach events that once relied on paper and clipboards. He had never built software like this before, but he has spent decades adopting new technology early, from AutoCAD to Google Fiber.

John’s church runs outreach weekends with free haircuts, eyeglasses, food, dental care, oil changes, and other services, and every registration workflow was manual. Volunteers tracked schedules and services by hand across multiple churches.

At 91, John decided to build software instead. The result is an operations platform with separate admin levels, mobile registration, automated exports, digital waivers, and personalized participant schedules called Impact Passports. In this episode of How I AI, he explains how he planned it, built it, and kept the AI from drifting into rabbit trails.

John's process has two parts. Claude turns his rough outline into user journeys, requirements, security considerations, and phased plans; Replit then uses those materials to build the application. John does not write the TypeScript himself, but he continually tests the workflows and redirects the agent when it drifts.

Turning a church workflow into a real product spec

John’s project started with a bottleneck: registrations for his church’s "Impact Weekends" were completely manual. Coordinating services like haircuts, food, dental care, and oil changes meant juggling paper forms, handwritten schedules, and volunteers across multiple churches.

Planning before coding

John did not start by asking Claude to generate an app. He started with a Word document describing the workflow, then asked Claude to help create a development roadmap covering registration flows, service selection, participant information, and scheduling.

One key concept was the Impact Passport, borrowed from another church. Participants would register in advance and receive a personalized schedule instead of handwritten instructions.

• Participant Registration: What data to collect from attendees.
• Service Selection: A list of available services like haircuts, dental care, etc.
• The 'Impact Passport': A concept he’d seen at another church, where participants get a printed schedule of the services they signed up for, which he wanted to digitize.

He treated Claude like a planning partner, not a chatbot. He told it the final app would be built in Replit and instructed Claude to ask follow-up questions whenever requirements were unclear. That back-and-forth turned a rough outline into something much closer to a real product requirements document.

Using Claude like an AI product manager

Claude translated John's operational knowledge into user stories, permissions, and phased plans before implementation. The AI product-manager workflow shows how to turn that domain expertise into a blueprint a coding agent can follow.

• User Stories: Claude broke down the needs of different users. It created stories not just for participants and administrators, but also for specific roles like the pastor or ministry leader. For example: "As a system admin, I want to be able to see all data across all churches, but as a local church admin, I only want to see data for my own church."
• Multi-Tenant Architecture: The chat outlined a sophisticated system with role-based access control. It defined a system admin who could oversee all church events, and local admins who could only manage their specific event.
• MVP and Phased Rollout: Claude proposed a minimum viable product (MVP) with core features like an admin interface, passport generation, and data management, followed by a phased development plan.
• Non-Functional Requirements: John even got Claude to outline requirements like security and data privacy, showing a level of detail you'd expect from a professional product manager.

John said the output was surprisingly accurate from the start. He adjusted details as the project evolved, but most of the operational logic already matched what he had in mind. By the end of planning, he had structured workflows, requirements, and rollout phases instead of scattered notes.

Building the app conversationally in Replit

Once the planning was done, John moved into implementation. He copied the Claude-generated requirements into the Replit agent and let it begin scaffolding the application.

The pattern is simple: humans define workflows, permissions, and business rules while coding agents handle implementation.

From requirements doc to working software

The handoff itself was simple. John explained, "I just took and copied what Claude had put together. And put it in the Replit, and then started going and there it was." He pasted the roadmap, requirements, and user stories into Replit, and the agent began generating database schemas, backend logic, frontend interfaces, and file structures.

John described watching the agent work almost in disbelief: "It was so fast, I couldn't believe it."

Designing for multiple churches, volunteers, and services

What John built goes far beyond a simple form app. The platform manages multiple churches, admin permission levels, participant registration, volunteer coordination, reporting, and service logistics through conversational prompts in Replit.

The feature set became surprisingly deep. System admins can oversee every participating church while local admins only see their own event data. Churches can turn services on or off depending on volunteer availability, and organizers can generate exports for follow-up and purchasing.

One workflow handles free oil changes. Participants enter a VIN during registration, the system uses the OpenAI API to identify the correct oil and filter, and the app generates shopping lists for volunteers. Another workflow creates mobile-friendly registration forms from QR codes, then generates PDF Impact Passports and emails them through SendGrid after participants sign digital waivers.

The app also produces reports for pastors, food pantry teams, and vision clinics. It feels less like a demo and more like operational infrastructure.

• Admin Dashboard: A secure login for system admins and local church admins. The system admin has a global view of all events and participants, while local admins are restricted to their own church's data.
• Event and Service Management: Admins can create events and toggle services on or off. If a service like "free haircuts" isn't available for a specific event, it can be easily disabled.
• Reporting Suite: John built several automated reports that can be exported to Excel. These include a demographics report for pastor follow-up, a service usage report to track popular services, and specialized shopping lists for the food pantry.
• VIN Lookup for Oil Changes: This is a pretty clever feature. When a participant signs up for a free oil change, the form asks for their car's Vehicle Identification Number (VIN). The application then hits the OpenAI API to look up the exact type and amount of oil and the correct filter needed for that specific car. This generates a precise shopping list for the event volunteers.
• Participant Registration & Passport: Participants can scan a QR code on a flyer, which takes them to a mobile-friendly registration form. After signing waivers with a digital signature feature (watch out, DocuSign!), the system generates a personalized "Impact Passport" PDF that is emailed to them using SendGrid.

Adding features through plain-English prompts

John kept extending the system after the first version was working. New functionality often started as a plain-English request to the Replit agent. One example was replacing handwritten volunteer badges with automatically generated name tags. He prompted the agent:

I want to add a function that will populate a volunteer list when a local administrator fills an input page.

The Replit agent responded by creating a volunteer table, updating the schema, wiring up the admin interface, and generating the related workflows.

But the process was not autonomous. John constantly reviewed output, tested features, and corrected the AI when it drifted away from the requirement. He learned to interrupt aggressively with comments like "Wait" or "Stop" if the agent is going down a "rabbit trail."

That loop is the real shape of vibe-coding right now. The AI moves quickly, but someone still has to catch broken features, changing requirements, and production bugs. One difficult issue involved generating PDF passports correctly in production email flows even though everything worked in development.

John defines workflows, tests outputs, restores checkpoints when something breaks, and decides what matters for event organizers. The Replit full-stack workflow follows that conversational build loop without confusing generated code with validated operations.

What is actually worth copying from this workflow

What impressed me most is the gap between the resources and the result. For roughly $350 and a few weeks of late-night sessions, John built software that coordinates volunteers, generates reports, handles permissions, creates PDFs, sends transactional emails, and manages real event logistics.

He did not start by learning frameworks or databases. He started with a clear understanding of the problem.

John compares this moment to the arrival of AutoCAD in the 1980s. Many of his peers resisted learning it, but adopting the technology extended his career for decades. "That's another reason to learn this technology," he says. "Because if you learn it, you can be having fun well into your seventies, eighties, and nineties."

What I like about John’s workflow is that it solves an operational problem first and treats AI as the implementation layer second. The app reduces paperwork, coordinates volunteers, improves follow-up, and helps outreach events scale without adding administrative chaos.

The process is also worth copying. Use AI to clarify the workflow and generate structured requirements, then move into implementation with a coding agent while staying closely involved in testing and review. This works especially well for internal tools and operational systems where the builder understands the real-world process.

Human judgment still matters for edge cases, production reliability, permissions, deployment bugs, and deciding whether the software is actually useful. John’s app works because he understands the event operations in detail.