A real-world case study, in 13 chapters, of building and launching a live AI-powered SaaS product — AI Engineering Copilot — from picking a niche through Next.js 15 project setup, Supabase auth/database/RLS, a fetch-based Groq AI integration, local testing, GitHub, Vercel deployment, real troubleshooting, and launch marketing. Every fetch call, middleware file, .env variable, and error shown is real.
Ch 1: Defining the SaaS idea and target market (electrical contractors). Ch 2: Choosing the stack — Next.js 15, Supabase, and the Gemini-to-Groq detour. Ch 3: Dev environment setup and collecting Supabase/Groq API keys. Ch 4: Creating the Next.js project — folder structure, .env.local, route groups, and the auth middleware.ts. Ch 5: Supabase database schema and Row Level Security policies. Ch 6: The lib/ai.ts Groq fetch() integration and prompt design. Ch 7: Building the core features — AI proposal generator, NEC load calculator, code assistant. Ch 8: Testing locally with npm run dev and a feature checklist. Ch 9: Pushing to GitHub — .gitignore, git init, and personal access tokens. Ch 10: Deploying to Vercel — environment variables and the build pipeline. Ch 11: A real troubleshooting guide covering dev server, Supabase auth, Groq API, and Vercel deployment errors. Ch 12: Marketing copy, platform choice, and the launch post.
The book documents a genuine pitfall: the original plan was Google Gemini, but every model returned "limit: 0" errors on the free tier because the Gemini API requires Google Cloud billing to be enabled even for free usage — and a paid Gemini chat subscription does NOT include API access, since they are separate products. Groq was the fix: a genuinely free account (14,400 requests/day, no credit card), an OpenAI-compatible endpoint reachable with native fetch(), and the LLaMA 3.3 70B model for technical writing and code Q&A.
The reader includes the actual middleware.ts auth-protection skeleton, the .env.local variable names (NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, GROQ_API_KEY), the lib/ai.ts groqChat() fetch function with its Authorization header, the Supabase RLS policy SQL for the proposals table, the .gitignore contents, the exact git init/remote/push command sequence, the Vercel environment variable table, and the next.config.mjs typescript.ignoreBuildErrors escape hatch used when a Vercel build blocked on a flagged Next.js CVE.
One documented real error: Vercel blocked a deployment with "Vulnerable version of Next.js detected — please update immediately," triggered by CVE-2025-66478, a CVSS 10.0 critical vulnerability in the Next.js App Router. The fix was running npm install next@latest, using Vercel's in-dashboard "Upgrade" button on the failed deployment, and promoting the patched Preview deployment to production — a real-world illustration of why Vercel gates deployments on known-vulnerable framework versions.
The original plan was Google Gemini. After creating API keys and calling several Gemini models (gemini-2.0-flash, gemini-1.5-flash, gemini-2.0-flash-lite), every call returned a 429 "limit: 0" error or a 404 model-not-found error. The root cause: the Gemini API requires a Google Cloud project with billing enabled, even to use the "free" tier — and a paid Google One AI Premium (Gemini chat) subscription does NOT include API access, because the chat product and the developer API are billed separately. Groq was chosen as the replacement because it is completely free with no credit card required, offers 14,400 requests/day, exposes an OpenAI-compatible chat completions endpoint reachable with plain fetch(), and runs LLaMA 3.3 70B at very fast inference speed. Switching required changing only the API URL, model name, and header in lib/ai.ts.
The application uses a middleware.ts file at the project root that runs on every request matching the config.matcher pattern (everything except _next/static, _next/image, and favicon.ico). Inside the middleware, a Supabase server client checks whether the incoming request has a valid session. If the user is not authenticated and requests a page inside the (app) route group, the middleware redirects to /login. If the user is authenticated and requests /login, it redirects to /dashboard. Route groups — folders wrapped in parentheses like (app) and (login) — let the two areas share different layouts (sidebar+topbar vs. a minimal centered layout) without changing the URL structure, since Next.js strips the parenthesized segment from the route path.
All secrets live in .env.local, which is listed in .gitignore before the first git commit so it is never pushed to GitHub. Variables prefixed with NEXT_PUBLIC_ (like the Supabase URL and publishable key) are safe to expose because Supabase's Row Level Security enforces access control server-side regardless of what the client can see. GROQ_API_KEY deliberately has no NEXT_PUBLIC_ prefix, which means Next.js keeps it server-only and never bundles it into client-side JavaScript — this is why every Groq call happens inside a Next.js API route (app/api/ai/proposal/route.ts, app/api/ai/assistant/route.ts) rather than a client component. When deploying, the same three variables are re-entered in the Vercel project settings, since Vercel does not read the local .env.local file.
Three real Vercel-stage errors are documented. First, a TypeScript build error (duplicate JSX attributes) that passed locally but failed the Vercel build, because Vercel always runs full type checking during npm run build — fixed by correcting the source, with typescript: { ignoreBuildErrors: true } in next.config.mjs available as a temporary escape hatch. Second, "Vulnerable version of Next.js detected — please update immediately," triggered by CVE-2025-66478 (a CVSS 10.0 critical vulnerability in the App Router) — fixed with npm install next@latest and promoting Vercel's auto-patched Preview deployment to production. Third, a build that appeared to hang at "Collecting build traces" — resolved by removing an invalid next.config.mjs key (outputFileTracing: false is not valid in Next.js 15) and confirming the step simply takes 10-30 seconds on larger projects.
For the proposals table: ALTER TABLE proposals ENABLE ROW LEVEL SECURITY; turns on RLS, then two policies are created — one for SELECT using auth.uid() = user_id, and one for INSERT with the same WITH CHECK condition. This means every query automatically filters to rows owned by the currently authenticated user (via Supabase's auth.uid() function), even if application-layer code has a bug that would otherwise expose other users' data. The same pattern is repeated for the projects and calculations tables. Without RLS enabled on every table in a multi-user Supabase app, any authenticated user could potentially read or modify other users' data directly through the auto-generated REST API.