AI Product Engineering: From Concept to Launch

• What AI actually is: a statistical prediction model, not a knowledge system — Data → Patterns → Probability

• Deterministic software vs. probabilistic AI — “regular software breaks, AI is wrong with confidence”

• Alan Turing and the Turing Test, the coining of “artificial intelligence,” ELIZA

• How AI was trained, and who trained it: reCAPTCHA as unpaid labelling, annotation labour and “ghost work”

• The invisible AI we already use: Siri, Netflix, Spotify, TikTok, Google Translate

• The AI effect: why AI stops looking like AI the moment it works

• The OpenAI story: Sam Altman, Y Combinator, DeepMind’s acquisition, the founding of OpenAI, Musk’s exit, non-profit → capped-profit → public benefit corporation

• “The Blip” — November 2023 and what it revealed about AI governance

• The diaspora: Anthropic, SSI, Thinking Machines, xAI

• The current model landscape: US frontier labs and Chinese open-weight labs; closed vs. open weights as competing business models

• The AI bubble debate

• The three assistants, compared  not feature lists, but where each one is actually stronger: reasoning style, long documents, code, image and video, search, speed, price

• Where each one sits in a build workflow, and why most professionals end up using two rather than one

• The three ways AI reaches your data  

• Plugins / GPTs / Gems  capability bolted onto the assistant’s own interface

• Connectors a ready-made link to a service someone else already built (Gmail, Drive, Slack)

• MCP  an open standard that lets any AI client talk to any system, including one you build yourself

• Why MCP became the standard and what it changed: an integration written once works in every client that speaks it

• Context, memory and projects - what each assistant actually retains, and what it quietly forgets

• Cost and limits: what you are paying for, and what runs out

• Choosing the stack for this course, and why: Claude Code for building, Figma Make + Claude Design for design, Replit for the first deploy, Supabase for data, Vercel for production

• From a paragraph to a design: prompting a design tool for a result you can actually use

• Iteration as the real skill: describe → look → refine. Where AI design output still needs a human eye

• The intake form — the piece that matters. Fields, validation, what happens after submit

• Taking a design out of Figma Make and into a working page in Replit

• Responsive behaviour: it has to work on a phone, because that’s where it will be opened

• Publishing: the first live URL

• Where the form data goes for now — a deliberately temporary answer, replaced in lecture 4. Building something you know you’ll rip out is normal, and saying so removes the fear of it

• Spec → plan → build. Give Claude Code the spec, make it produce a plan, correct the plan, then let it build. Most vibe coding disasters are planning failures that happened quickly

• Working in a real repository - and Git as an undo button: commits, branches, and how to get back after a confident լbad edit destroys something. Taught here, deliberately early, because this is the failure that ends people’s projects

• Supabase: tables, relationships, and what a database is actually doing. The request table, the notes table, the staff table

• Authentication - a login screen, real accounts, who is allowed in

• The two screens that matter: the queue (all requests, filterable) and the detail view (one request, with notes and status)

• Rewiring the landing page form to write into the real database. The two surfaces become one product

• Reading a diff you didn’t write: what to check, what to always question

• What it means to call AI from inside your own product rather than from a chat window — the same model, a completely different relationship to it. AI writes the integration; participants understand the shape of it

• Auto-triage: a new request arrives → the AI assigns a category, sets urgency, writes a two-line summary. The queue becomes sorted by something meaningful

• Draft reply: the AI writes a response, a human edits and approves. The approval step is the lesson — the AI never sends anything by itself

• Ask across everything: a question box that answers from all the requests in the database. “What are people complaining about most this month?”

• Prompts as part of the product — living in the codebase, versioned, editable, not retyped into a chat each time

• When it’s wrong in production: fallbacks, sensible defaults, error states, and the rule that a failed AI call must never block the human from working

• A 15-case sanity check: run real submissions through the triage, count how many it got right, fix the prompt, count again

• Cost per request - measured, not guessed. What this platform costs at 100 requests a month, and at 5,000

• MCP: connecting Claude directly to the platform’s own data, so the business can be run from a chat window as well as from the screens

• Moving from Replit to Vercel: what a production host gives you, and why the thing you built in class isn’t yet the thing you can hand to a client

• Consolidating the two surfaces. Until now the landing page has lived in Replit and the platform in a GitHub repo. Here they move onto one host, one domain — the public page at the root, the platform behind a login. This is the moment the two halves become one deployed product

• Custom domain and DNS — buying it, pointing it, HTTPS. Fifteen minutes of genuinely fiddly work, done together

• Environment variables and secrets: why an API key must never reach the browser, and how to check that yours hasn’t. Demonstrated live, including what a leaked key looks like on a bill

• Supabase Row Level Security — the one that actually matters. Without it, a public application’s database is readable by anyone who looks. Every participant enables and tests it before leaving the room

• Who can see what: staff vs. admin, and the one-line mistake that shows every clinic’s requests to every other clinic

• Cost caps and rate limits — protecting yourself from a loop, a bot, or a bad month

• Logs and monitoring: knowing something broke before the client tells you

• Backups, and the uncomfortable question of what happens if you disappear

• Putting it in front of three real people and watching them use it without helping. The most uncomfortable and most valuable twenty minutes of the course

• The gap between what you thought would break and what broke

• Visual polish: fixing hierarchy, spacing, empty states, loading states, error messages — the difference between “a student project” and “a product”

• Copy that works: what the buttons say, what an empty queue says, what the user sees when something fails

• Speed: why it feels slow, and what to do about it

• The iteration loop at production speed: feedback → spec change → Claude Code → review → deploy, several times in one session

• Handover documentation — a short README so someone who isn’t you can run it. Written by AI, checked by the participant

• What maintaining a live product actually involves once the course ends

Each participant presents the live product, not slides:

• Open the public domain — a real URL, in front of everyone

• Submit a request from the landing page

• Log into the platform, show it arrive, show the AI triage it

• Draft and approve a reply

• Show one thing that broke during the course and how it was fixed

• State the monthly running cost