After years in sales leadership, I had a vision for something I believed could genuinely help students and churches. So I spent my nights and weekends — one prompt at a time — and built it into a real, live product. This is that story.
✓ No coding background · ✓ No technical co-founder · ✓ Built on nights and weekends
I'd spent years in Christian education — growing a school from 200 to 1,500 students, leading sales teams, watching families search for something that would keep their kids spiritually engaged. I knew what was missing. I just didn't know how to build it.
So I started spending my evenings and weekends at my kitchen table, prompting. Not coding — just talking through ideas, describing what I saw in my head, and watching something real take shape on the screen. Feature by feature. Night by night.
878 prompts later, Flourishing Students was live — a full AI-powered learning platform for Christian students, with its own domain, Stripe subscriptions, a 3D animated AI tutor, Bible trivia, scripture memory tools, a pastor devotional system, gamification, school admin dashboards, and a pilot school already signed. Two products. Zero developers. Zero lines of code I wrote myself.
"Will you be able to help me get this market ready with everything needed without me needing to hire a programmer? That would be so wonderful!"
— My actual words, message #44 in the development transcript
I asked that question not knowing if it was possible. The answer turned out to be yes — and what followed was 90 days of late evenings, early mornings, and the slow, steady realization that the gap between having a vision and having a product had permanently changed.
Here's the scope of what took shape — one conversation at a time — while I still had a day job.
A complete faith-based student learning platform with AI tutoring, Bible trivia, scripture memorization, daily devotionals written by a real pastor, prayer journal, gamification (XP, streaks, badges), parent dashboard, and a full PWA for mobile.
A full visitor-to-member CRM for churches with engagement scoring, staff management, journey-based tracking, event management with email automation, bulletin creator, and an AI commentary tool for pastors.
Stripe subscription integration with multiple pricing tiers (Classroom, Campus, School, Annual), 14-day free trials, subscription management portal, and webhook handling — all production-ready.
Two completely separate auth systems — Supabase for students/admins, cookie-based for the pastor portal — with role-based routing, IP rate limiting, content moderation, and RLS policies.
Benny — a 3D animated AI tutor mascot with voice, animations, and personality. Claude-powered trivia, commentary, devotionals, and file uploads (PDFs, images, Word docs) all processed server-side.
Two completely separate products on two separate domains, running on a single Vercel deployment, with domain-based middleware routing, multi-tenant design, and school-level admin portals.
Looking back through 878 prompts, the build had a clear shape. Not a plan I followed — a pattern I discovered by doing it. Here's what it looked like from the inside.
It started with one sentence typed in the middle of something else entirely. Within a single evening, the product had a name, a mascot, a positioning statement, and a clear differentiator. I didn't need a product spec — I needed to describe what I already knew was missing and let the conversation sharpen it.
One evening No technical knowledge Named product at the endI had never opened a terminal. The first week was the hardest. But every command was copy-paste. Every error got pasted back in. The AI never made me feel behind — it just kept going. By the end of the first weekend, the app was live on Vercel, connected to a real database, with real user accounts. That feeling didn't get old.
Supabase Vercel GitHub Next.jsThis became the rhythm of my evenings. Describe a feature. Watch it get built. Click around, tell the AI what I saw, fix what was off. Then: "Can you give me the code to push?" — and it was live. I didn't have to understand the code. I had to understand the product. That part I already knew.
Plain English descriptions Error paste → instant fix Visual feedback loopsGetting something working and getting something ready to sell are two different things. Security, SEO, Stripe payments, legal disclaimers, mobile responsiveness — I asked about all of it, one question at a time, the same way I'd asked about every feature. By launch day, there was nothing I'd knowingly left exposed.
SEO Rate limiting Payment flows Legal disclaimersBefore the product launched publicly, a real school had agreed to pilot it. The outreach email, the flyer, the partnership proposal, the Arizona ESA marketplace integration — all of it came out of the same workflow as the code. I didn't need a marketing team. I needed to keep showing up at the keyboard.
Pilot school secured ESA marketplace integration First paying customerI didn't set out to develop a system. But after 90 days of nightly sessions, certain patterns showed up again and again. Here are the seven that made the biggest difference.
Don't wait until you have a full business plan. State the outcome you want — even vaguely — and let the AI help you sharpen it. The best ideas surface through dialogue, not solo brainstorming.
When something breaks, don't try to diagnose it yourself. Copy the exact error message and paste it. This single habit saved hundreds of hours of frustration and fixed problems that would have stopped any non-technical founder cold.
Used dozens of times when AI sessions hit context limits. Instead of re-explaining everything, this simple phrase restored momentum instantly. The AI would summarize the state and keep building. Continuity is a skill, not a given.
Describe what you SEE, not what you think is broken in the code. Non-technical founders have a massive advantage here: their descriptions are user-focused, which gives the AI exactly what it needs to fix the right thing.
Celebrate wins before adding the next request. "This is amazing!" isn't just excitement — it signals to the AI that the previous work is complete and accepted. Then immediately pivot to the next feature while the context is warm.
Knowing when to abandon a technical approach and step back is as important as pushing forward. Non-technical founders don't have ego attached to technical decisions. That makes them better at cutting losses and finding alternative paths.
Always bring the business perspective into technical conversations. Questions about cost, scalability, pricing, and market fit — asked WHILE building — produce better architectural decisions than retrofitting them later.
There were nights I genuinely didn't know if I could keep going. Here's what those moments looked like — and what happened next.
The first database migration required opening a .sql file — a file type Chris had never seen. Instead of stopping, he described the problem. The AI explained and provided an alternative path. Lesson: your confusion is valid input.
HTTP vs HTTPS mixed content errors, misconfigured environment variables, cookie auth failures — these are invisible to non-technical founders. But they're also fixable by pasting the browser console error. Every time. Lesson: the error message is the solution.
Long AI sessions hit their context window limits, mid-build. Each time, the next session started with a summary and "Continue from where you left off." The build never lost more than 10 minutes of momentum. Lesson: context loss is a feature, not a bug — it forces clean summaries.
The AI tutor feature broke because the API billing lapsed. Lesson: all SaaS products have operational costs — build your pricing to cover them from day one. We added a per-user token cap to keep the business sustainable.
I typed that at 11pm after a long day. The real fuel behind every late night wasn't ambition — it was conviction. A belief that this product could genuinely serve students and families, and a desire to build something that was truly mine. That "why" never wavered, even when the code did.
A real accounting of everything that's live, deployed, and operational — built by one person with a vision and a lot of late evenings.
I documented the entire process — every phase, every prompting pattern, every obstacle — so that anyone with a vision and no technical background can follow the same path.
6 modules · 60+ pages · Includes real prompt scripts
How to use AI to validate your idea, identify your differentiator, and name your product before you build anything.
Setting up Supabase, Vercel, GitHub, and your domain — step by step, no technical knowledge assumed.
The exact rhythm of describing, reviewing, and shipping one feature at a time without losing momentum.
Annotated real prompts from 878 development messages — what worked, what didn't, and why.
Security, SEO, payments, onboarding, legal disclaimers, and marketing materials — all inside the AI workflow.
Building pilot programs, email outreach, marketplace integrations, and your pricing model while you're still building.
You don't need a technical co-founder. You don't need investment. You don't need to understand code. You need a clear vision, the right approach, and the willingness to show up night after night until it's real.
Landing Page + Complete Workbook · Instant digital download
Get Prompt to Launch →