What you'll build (and how building works now)

By the end of this course you will have built and deployed a real web application: it will live at a URL, store data in a real database, and include an AI feature you designed. Not a tutorial artifact — an app you own, whose every line you caused to exist, running on the public internet. The app is Replyable: a small customer-feedback inbox where messages arrive, get organized, and — the AI feature — get summarized and answered with drafted replies you approve. It's deliberately the kind of app a thousand small businesses would pay for, because 'useful and small' is exactly the target a first shipper should hit.

How building works in 2026 (the honest version)

• The AI writes most of the code. Modern AI assistants generate working web code from plain-English descriptions, fix errors when shown them, and explain anything you ask. This is not a gimmick layered on the course — it is the method, the same one professionals increasingly use.
• You are the editor-in-chief, and that's the skill being taught. Deciding what to build, describing it precisely, reading what comes back well enough to steer, testing what matters, and refusing to ship what you don't understand — those are the durable skills. Code comes and goes; judgment compounds.
• 'No prior coding required' means no prior coding — not no reading. You will learn to read code the way you read a contract: not writing it from scratch, but knowing what you're agreeing to. Every module builds that literacy a notch. Learners who skip the reading ship apps they can't fix; learners who do the reading end the course genuinely dangerous (in the good way).

The three rules that prevent the classic failures

• Small steps, always working. One change at a time, test, commit. The failure mode of AI-assisted building is asking for five features at once and receiving a haunted house. The unit of progress is 'the app still runs and now does one more thing.'
• Read the diff. Before accepting any generated change, read what changed and ask the assistant to explain anything opaque. Concretely: after applying a change, run git diff in the terminal and read the lines marked + (added) and - (removed) — that's 'the diff'. Thirty seconds per change; it's where all the learning happens.
• When stuck, paste the error. Error messages are the assistant's native food. The debugging loop — run, read the error, paste it with context, apply the fix, re-run — will carry you through 90% of everything that goes wrong all course.