Vibe coding
Build and test a small product with AI coding tools, from a clear brief to a maintainable release.
26 lessons in 7 modules
What you'll practise
- Turn one user problem into a buildable brief and working first screen.
- Review changes, test important flows and recover with version control.
- Plan authentication, payments and a release you can maintain.
Before you start
Bring a laptop, a small product idea and time to inspect what the tools produce. Start with the setup module; coding experience is not required to begin.
Course syllabus
Module and lesson summaries follow the club curriculum. Open any module to read its outline.
A stack you can actually maintain
Picking four services you can still read in a year
You lay out the four jobs every product has to do: show pages, store data, know who is signed in, and take money. For each job you pick one service and write down why. Cirka runs on a front end, Supabase and Stripe, and this platform runs on the same three. Nothing else gets added until a real user asks for it. The mistake this lesson protects you from is adding a service per feature until the app has nine dashboards and one person who understands it. You leave with a one-page stack decision, saved in the repo, that you read again before adding anything.
Cursor, Claude Code and a repo running in 20 minutes
Download and unzip the starter practice pack, read its README and run the supplied local exercise. Change one sample value, inspect the result and save a local checkpoint. A fixture is not a fully wired framework app; later app lessons require a separately scaffolded project using current official setup instructions. Record the actual output and files. Do not assume a server URL, Supabase client or Stripe integration exists in the pack.
Writing the rules file before the first prompt
You write the rules file the model reads on every request: folder layout, naming, which library handles data, and the line that matters most, ask before deleting anything. You start from the file used on this platform and cut it down to what your app needs. Without this file the model picks a new convention each session and the codebase drifts within a week; with it, a prompt written on day 30 still lands in the right folder. You commit the rules file and test it by asking for one small component and checking where it lands.
Git habits so an agent can never lose your work
You learn the three Git moves that matter when a model edits your code: commit after every working step, a branch for each feature, and revert when the last change made things worse. You practise each one on the starter, including a deliberate revert. The reason is concrete: an agent will one day delete a file it thinks is unused. If your last commit was this morning, that is a one-line fix; if it was last week, it is an afternoon. You leave with a printed checklist and a habit of committing every 20 minutes.
Idea to clickable prototype in one day
Writing a brief the model can build from
You write a one-page brief: who the user is, the one thing they come to do, the screens in order, and what is out of scope. You use the landing prompt from the library as the shape and fill it with your own product, in under 200 words. A vague brief produces a generic app; a short precise one produces a first draft you can react to. You test yours by pasting it into a fresh chat and reading what comes back without editing. You end with a brief saved in the repo as docs/brief.md, the file every later prompt refers to.
Lovable, Bolt or Cursor: choosing for this prototype
Run the same brief through available development tools within a time allowance you choose. Compare usable output, code access, change review, portability and maintenance effort. Check current product capabilities and plan limits before paying. Save what each actually produced and explain your choice; no historical founder migration or universal speed ranking is claimed.
Generating the first screen and cutting half of it
You generate the first screen from the brief and then delete: the hero image, the testimonial row, the four features nobody asked for. What stays is the one action the user came for, above the fold, with the result visible on the same screen. The common mistake is accepting the model's twelve-section page because it looks finished. Finished is not the same as useful. You finish with one screen that does one thing, and a note of what you cut so you can bring parts back when a user asks for them.
Wiring three screens into one clickable flow
You add two more screens, a form and a result, and connect them with routes so a person can move from the first screen to a done state without a dead end. Data can be fake for now; the point is that every button leads somewhere. You handle the three states each screen needs, empty, loading and error, because the model only builds the happy path unless you ask. You end with a prototype you can click through start to finish in under a minute, running on the starter from module one.
Publishing the prototype and collecting five reactions
Prepare a preview of your prototype and a short task for people who match the brief. Arrange feedback with their agreement, record where they get stuck and use those observations to revise the brief. Five sessions is a suggested exercise target, not a guarantee of weeks saved. A preview and feedback plan can be finished before volunteers are available; keep any pending sessions labelled pending.
Data, sign-in and payments without the fear
One table, one screen: Supabase basics
Create one disposable synthetic table with five columns, enable Row Level Security immediately and keep anonymous access closed. Inspect administrator-inserted fixtures separately from the browser: SQL Editor visibility does not prove client access. Prepare the result-screen query and its denied/empty states using a dashboard-verified public key. Authenticated owned-row reads wait for sign-in in lesson 3.2 and scoped policies in 3.3. Capture a reviewed migration baseline and test reconstruction in a second empty database without replacing an existing schema. Pack-only work is marked as a local fixture exercise, with live checks pending.
Adding magic-link sign-in with Supabase Auth
You add sign-in with an email link, so there are no passwords to store. You wire the session into the app, build one page that only signed-in people can open, and handle the case where the link is opened on a different device. The lesson uses the same kind of flow this platform uses to let members in. The mistake to avoid is checking the session in the browser only; the server has to check too, or a bookmark walks past the door. You finish with a working sign-in, a sign-out button and a protected page tested in a private window.
Row Level Security so people only see their own rows
Keep the Row Level Security boundary established in lesson 3.1 and add two authenticated policies: read your own rows and insert rows owned by you. Preserve existing records and verify fixture ownership before requiring an owner. Test anonymous denial and two real authenticated client sessions, including cross-owner read and insert attempts. Administrator queries are not evidence of browser isolation. Record actual outcomes and pending checks in a repeatable test procedure before deploying the reviewed migration.
Taking a test payment with Stripe Checkout and a webhook
You create one product and one price in Stripe test mode, open a Checkout session from a button, and write the webhook that marks the row active when the payment lands. You test it with a Stripe test card and watch the row change. The part people skip is the webhook: without it the payment succeeds and the app never hears about it. On this platform the seat claim happens only on the server for the same reason. You finish with the full loop, click, pay, row flips, and a note on which events to listen for and which to ignore.
Debugging with an AI pair
Reading the error before you paste it anywhere
You take a real error from the prototype and read it the way a developer does: the first line says what, the first line with your folder in it says where, and the last commit says what changed. You write those three lines down before opening a chat. Pasting 400 lines of log with the word fix on top is the most common way to waste an hour. A three-line report gets a fix on the first try more often than not. You end with a template for reporting a bug to a model, and one bug from your own app written up with it.
The reproduce, isolate, fix loop with Claude Code
You take the bug from the last lesson through one loop: reproduce it on demand, isolate it to the smallest piece of code that still fails, then ask Claude Code for one hypothesis and one change at a time. After each change you rerun the reproduction, not the whole app. Asking for one change at a time feels slow and is faster, because you always know which edit fixed or broke things. You finish with the bug fixed, the fix in its own commit, and a short note in the repo about the cause so the next model session does not reintroduce it.
When the model goes in circles: stop, reset, narrow
Recognise repeated edits without new evidence, stop the agent and inspect staged, unstaged and untracked work. Verify a backup, preserve unrelated edits and reverse only the identified unwanted change. Use a disposable repository to practise recovery. A fictional currency-conversion trace teaches one input, one expected result and one hypothesis; it is not a Cirka incident or an instruction to reset the working tree.
Console, network tab and Supabase logs for non-coders
You open the three places errors hide: the browser console for front-end faults, the network tab for a request that came back with a 401 or 500, and the Supabase log explorer for what the database actually rejected. You trace one failing request through all three. Half of the bugs blamed on the model are a wrong key, a missing policy or a request going to the wrong URL, and all three show up in these tools within a minute. You finish with a short map of which error type lives where, pinned next to the rules file.
Launch, pricing page, first 100 users
A pricing page with one plan and one live button
You build the pricing page with one plan, one price and one button that opens the Checkout from module three. Copy comes from the brief: who it is for, what they get, the price, and the one question people ask before they pay. Three tiers before the first customer is the classic mistake; you cannot price a ladder you have not climbed. This platform shows three seat tiers but only the current one has a live button, which is the same idea. You end with a pricing page that takes a test payment end to end.
Going live: domain, production keys and a smoke test
You move from localhost to a domain: environment variables set in production, Stripe switched to live keys, the webhook endpoint updated, and the Supabase redirect URL changed so the sign-in link comes back to the right place. Then you run the smoke test: sign up, sign in, pay one real amount, refund it, and confirm the row flipped and the email arrived. Most launch-day breakages are one of those five, and a test key left in production is the usual one. You finish with the app live on its own domain and a checklist you reuse on every deploy.
Finding the first 100 users without an ad budget
List places where the intended audience already talks and choose a small relevant sample. Prepare an original output, an honest maker disclosure and a message appropriate to each place. Build a fourteen-day outreach plan with permission and community rules checked before posting. Record actual replies and signups without inventing founder acquisition results or promising the first hundred users.
Three numbers to check every week, set up in an hour
Choose a few clearly defined measures: visits, signups and completion of the main action within a stated window. Record the sources, cohort and timezone, then prepare a repeatable weekly review. Check instrumentation before interpreting a change. An illustrative activation metric is not a claim about Cirka's first-year results; incomplete data should lead to a measurement repair.
Funnel rebuild exercise inspired by Cirka
Mapping a funnel and choosing a hypothesis to test
You work through an illustrative funnel inspired by Cirka's URL-to-creative journey. Its numbers are fictional teaching data, not Cirka analytics. Counts and rates show where behaviour changes, but cannot establish why or make the largest drop the best intervention. Map your own journey with consistent visitor identities, cohort dates and follow-up windows. Separate retention from required funnel steps, then compare plausible impact, effort and evidence to choose a test. If tracking is incomplete, label the snapshot and choose a measurement repair before interpreting a rebuild.
Rebuilding the front door: value before sign-up
You follow a written rebuild exercise: move a fictional tool’s sample result before sign-up, then ask for sign-up only to save it. Work through the staged prompts on your own preview and record the changed step. Preserve the original version and unrelated work. Check navigation and state before comparing outcomes; no recording or measured Cirka rebuild is claimed.
Measuring the rebuild and writing the one-page result
You define the primary outcome, meaningful improvement, follow-up window and decision plan before comparing versions. A randomised split can estimate the rebuild's effect with uncertainty; a before-and-after comparison leaves timing and traffic mix as alternative explanations. A week or a fixed visitor count does not guarantee a verdict. The numerical example is illustrative, not a Cirka result. You report comparable cohort rates, evidence limits and a decision to adopt, revert or remain inconclusive. Finish with a one-page write-up in Community under Wins; a documented inconclusive result is a valid completed exercise.
MCP contracts and reusable skills
Understand MCP through a read-only tool contract
Separate host, client and server responsibilities, then run a local tool-handler exercise with valid, invalid and hostile inputs. The exercise is explicitly not a deployed MCP server.
Build a tested skill and a scheduled code job
Author a complete small skill, test it against counterexamples, and package a deterministic report for manual and scheduled execution. Includes a deployment recipe without accounts, keys or external sends in the exercise.
Keep learning in the club
Course outlines and these guides are free to read without an account. Full lesson bodies and member features require a paid membership. The preview uses sample data; external tools may charge separately.