Most people only write about things that have already happened. Here's the thing I haven't done yet.
In August, thirty MBA students at NSBT, MGM University in Aurangabad — most of whom have never opened a terminal — will walk into a room for Session 0 of the GT Program. Three courses. Eighteen sprints. One year. And I'll be standing at the front as their Professor of Practice, watching the auth flow and praying it holds.
The platform is built. The sprint briefs are written. The content pipeline syncs markdown to the database with a single script. The design system spans eleven sections. The CLAUDE.md knows more about this project than I do. Everything is ready.
Nothing has been tested.
What We Built
The program is three courses, deliberately ordered against every intuition: GenAI first, then Marketing, then GTM Engineering. The logic is simple — you can't teach modern marketing to someone who's still scared of the terminal. Let them build an n8n workflow and push to GitHub before asking them to plan a content calendar.
The platform is a Next.js app on Supabase with three user types (Students, GT, NSBT) sharing one system. The content lives in docs/sprints/ as markdown — a single script generates both the static course pages and the database seed migration. Non-technical stakeholders can edit a sprint brief without touching SQL. Every change is a git commit. The CLAUDE.md enforces one rule: never hand-edit generated files.
We built the LMS with the same stack we teach. Next.js 14. Supabase. n8n. Tailwind. Shadcn. When something breaks during a live demo — and it will — that's not a failure. That's teaching material.
The Known Unknowns
Here's what keeps me up.
The auth flow works for one student. Will it work for thirty simultaneously? The Supabase auth setup — three clients, RLS policies, getUser() not getSession() — was built and tested in isolation. I logged in as a test student. I logged in as GT. I logged in as NSBT admin. One at a time. Never thirty. Auth doesn't degrade gracefully — it either works or you've got thirty students staring at a blank screen while you SSH into a VPS.
The submission pipeline works in isolation. Students submit sprint deliverables through the platform. Files upload. Metadata saves. The review UI populates. I tested it by submitting a fake deliverable from my own laptop. Fifteen groups uploading simultaneously? Different story. The file size limits, the concurrent write behavior, the error state when one upload fails mid-batch — none of this has been tested with real load.
What happens to between-visit momentum? The program runs on studio visits — concentrated in-person sessions with deliverables between them. The LLM Q&A feature, designed to keep students engaged between visits, isn't built yet. It's in the roadmap as Sprint 6. But Sprint 6 hasn't started. If students lose momentum between Visit 1 and Visit 2, no amount of sprint brief quality will bring them back.
The NSBT admin dashboard exists but has never been used by an actual NSBT admin. I built the views. I tested the queries. I never handed it to the person who needs to use it. They'll find the confusing UI decisions on Day 1, while I'm in front of the students, unable to fix it.
The live demo failure rate. Every builder knows this: the thing that worked perfectly at 2 AM breaks when there are thirty people watching. The Supabase migration. The n8n webhook. The Next.js build. One of them will decide to fail at exactly the wrong moment. The question isn't whether — it's which one, and whether I can turn the failure into a lesson instead of a disaster.
The Mistake We Already Made
Mid-build, Next.js released version 16. The platform was on 14.
New App Router conventions. Middleware became Proxy. Breaking changes in layout behavior. We had to migrate the platform while finalizing the curriculum — and then teach the newer version in class. The alternative (keeping the platform on 14 while teaching 16) would have been a visible contradiction. Students would notice. "Professor, why does the course say to use Proxy but the LMS uses Middleware?"
The migration took a week. Some bugs only surfaced after the deploy. The Supabase auth fix — switching from getSession() to getUser() — came from reading Supabase source code and GitHub issues, not the docs. That's the version of "eat your own cooking" nobody talks about: the platform can't fall behind the curriculum, and the curriculum can't fall behind the industry. Both move at the same time. You're rebuilding the plane while flying it — before the first passenger has even boarded.
What Success Looks Like
Not "students learned AI." Not "the cohort achieved X satisfaction score."
Success is: every student who started Session 0 comes back for Visit 2.
That's it. One metric. Retention. If thirty students who've never seen a terminal willingly return for a second session, the platform worked. The sprint briefs worked. The first live demo failure — however it happened — didn't scare them off.
Everything after that is optimization.
What Happens Next
I'm publishing this before Session 0. Not after.
Most people wait until the program succeeds, then write the retrospective that conveniently omits the parts they were terrified about. I'm doing the opposite. Here are the known unknowns. Here's what I'm worried about. Here's the one metric that matters.
In thirty days, thirty students walk into the room. In sixty days, I'll write the post-mortem — and we'll find out which of these things actually broke.
If you're reading this and the follow-up post doesn't exist yet, hold me to it. That's the point.