The Anatomy of a Vibe-Coded Project
Most build-in-public content shows you the polished end result. What it doesn’t show you is the afternoon you spent debugging a Supabase RLS policy that silently returned empty arrays instead of errors. This series documents every layer of the build process: what was decided, why it was decided, what worked, what broke, and what we’d do differently.
■ THE SCHOLAR SUITE PROJECT BREAKDOWN FORMAT
Section Why It Matters
Problem & Context Grounds every decision in a real need, not a technology preference
Stack Choices Lets you replicate or adapt the approach for a similar project
Build Timeline Shows real sequencing — what to build first and why
Key Decisions The most transferable section — decision patterns repeat across every project
Verdict Where most build-in-public content stops. Where the real learning starts.
Reusable Patterns The practical takeaway — specific things you can use in your own build today
Case Study: EventFlow OS
Dimension Detail Notes
Project EventFlow OS Event Registration & Attendee Management Platform
Market Nigerian & West African Event Organisers Conferences, weddings, corporate events
Stack Next.js • Supabase • Vercel • Paystack Full vibe coding pipeline
Build Method AI Studio + ChatGPT pipeline Zero traditional coding approach
Timeline 14 days to first production deploy On-schedule delivery
Status MVP Deployed • Iterating Real users, real feedback
EventFlow OS began with a specific frustration: Nigerian event organisers were managing guest lists in WhatsApp chats and Google Sheets, tracking payments via bank transfer screenshots, and sending reminders through personal phone numbers. Tools that existed for this problem were built for Western markets with no Paystack integration.
The core product brief: a Nigerian-first event platform that handles registration, payment via Paystack, WhatsApp-driven guest communication, and real-time attendee management — deployable in under two weeks using the vibe coding pipeline.
“We didn’t set out to build the world’s best event platform. We set out to build the right tool for one specific market — and let that specificity be the competitive advantage.”
■ EVENTFLOW OS BUILD TIMELINE — 5 PHASES
Phase Activity Tools & Notes
Phase 1 • Days 1–2 Product Definition & Architecture ChatGPT stress-tested the idea. AI Studio generated full database schema and 40+ API route map.
Phase 2 • Days 3–5 Authentication & Core Data Layer Supabase Auth with 3 roles. RLS configuration took 3 hours debugging silent permission failures.
Phase 3 • Days 6–8 Event Creation & Registration Flow Stitch generated UI components. Paystack integration added in under 2 hours.
Phase 4 • Days 9–11 WhatsApp Communication Layer WhatsApp Business API integration. Template approval required unexpected 48-hour wait.
Phase 5 • Days 12–14 QR Check-in, Dashboard & Deploy QR ticket generation. Mobile responsiveness pass. Vercel deployed in 14 minutes.
Key Technical Decisions and Why We Made Them
Every project has a handful of architectural forks — moments where two reasonable paths diverged and a choice had to be made. Documenting these matters because the same forks appear in almost every project, and the reasoning transfers.
■ KEY ARCHITECTURAL DECISIONS, DOCUMENTED
Decision Point What We Chose Why — and What We Ruled Out
Payment provider Paystack Nigerian bank account settlement. Ruled out Stripe (no direct NGN settlement) and Flutterwave (Paystack has cleaner webhook reliability at our scale).
Database hosting Supabase Built-in auth, storage, and REST API. Ruled out Neon (no built-in auth) and PlanetScale (MySQL vs Postgres preference).
Frontend framework Next.js 14 App Router Server components reduce client bundle. Vercel deploys seamlessly. AI training corpus is largest for Next.js.
Guest communication WhatsApp Business API Nigerian users’ primary communication channel. Open rates far above email in this market.
Multi-tenancy model Row-level tenancy (shared DB) Simpler to build at MVP scale. Database-per-tenant over-engineered for current user numbers.
QR code generation Server-side via qrcode npm Generated at ticket creation, stored in Supabase. Client-side adds JS bundle weight and security surface.
THE DECISION-DOCUMENTING HABIT
Every time you make a meaningful architectural choice, write one line: what you chose, and what you ruled out. This takes 60 seconds and pays for itself the first time a collaborator asks “why did we do it this way?” — or when you return to the project after two months away.
What Went Right and What Went Sideways — Honestly
EventFlow OS hit its 14-day deployment target but arrived with known limitations and a debugging scar from the RLS phase. Most post-mortems are written after everything has gone well. This one isn’t.
What Went Right ✓ What Went Sideways ✗
Paystack integration was genuinely easy — the API docs are excellent and AI generated working integration code on the second prompt attempt. Supabase RLS policies silently blocked data access without errors for three hours. The fix was a single missing policy line.
Stitch-generated UI components were high quality and required minimal adjustment — saved at least two days of front-end work. WhatsApp template approval took 48 hours, not the advertised 24. Build two buffer days into any project with external API approvals.
Database schema generated by AI Studio was mostly correct on the first pass — only two tables needed restructuring. The organiser dashboard was over-engineered — AI generated charts and analytics beyond MVP scope. We removed 40% before launch.
Vercel deployment was seamless — 14 minutes from first GitHub push to live URL, including environment variable configuration. Mobile responsiveness was inconsistent throughout. Required a dedicated half-day pass to fix across all pages.
The vibe coding pipeline forced a well-structured project because AI works better with well-defined inputs. No staging environment meant every fix was deployed directly to production. Set up a Vercel preview branch from day one on the next project.
“The RLS bug cost three hours. The lesson — always paste your full configuration when asking AI to debug policies — has saved more than three hours on every project since.”
Time and Cost Analysis
■ BUILD METRICS — EVENTFLOW OS
Metric Value
Days to first production deploy 14 days
Active build hours ~68 hours across 14 days
Infrastructure cost at MVP stage $0 (all free tiers)
Domain + WhatsApp test costs ~₦12,000
■ TIME DISTRIBUTION BY PHASE
Phase Hours Biggest Time Sink
Definition & Architecture 8 hrs Iterating on data model — 3 rounds before committing to final schema
Auth & Data Layer 14 hrs RLS debugging (3 hrs) + role-based access control logic (4 hrs)
Registration & Payments 16 hrs Paystack webhook handling and idempotency logic
WhatsApp Integration 18 hrs Template approval wait (48 hrs) + webhook reliability testing
QR, Dashboard & Deploy 12 hrs Mobile responsiveness pass (4 hrs) + environment variable config
Reusable Patterns, Templates, and Starter Decisions
The most valuable output of every project breakdown isn’t the story — it’s the transferable patterns. These are the prompt templates and architectural decisions from EventFlow OS that apply directly to the next project.
Pattern Description & Reuse
P1 • Architecture Kickoff Prompt Package A two-prompt sequence that generates a full project scaffold. Prompt 1 produces the DB schema and API route map. Prompt 2 identifies the three most likely failure points. Takes 40 minutes and saves days of mid-build rework. Reuse on: any web app project with a database and API layer.
P2 • Supabase RLS Template A standard RLS policy structure for three-role applications (admin, staff, user) that prevents the silent-failure debugging trap. Paste into your system prompt when generating any Supabase schema. Reuse on: any Supabase project with multiple user roles.
P3 • Paystack Integration Starter A four-file starter kit: the Paystack initialisation function, webhook handler with idempotency checking, payment verification utility, and database update on successful payment. Reuse on: any Next.js project collecting payments in Nigeria.
P4 • Mobile-First Prompt Override Add to every UI prompt: “Build this mobile-first for a 375px viewport. Use a stacked single-column layout on mobile. Desktop should be a natural expansion of mobile, not the reverse.” Eliminates the entire mobile responsiveness pass. Reuse on: every project — all Nigerian users are on mobile.
P5 • WhatsApp Buffer Protocol Submit WhatsApp message templates for approval on Day 1, not when you need them. Include a 72-hour approval buffer. Test with sandbox while awaiting approval. Never make WhatsApp a blocking dependency. Reuse on: any project using WhatsApp Business API.
“Every project teaches you something. The goal is to write it down while it’s fresh — and turn the lesson into a template before the next project begins.”