Bonus: what else you can build

Lessons

1. 10.1

   Choosing and scoping your next project

   45 min + 25 home

   A one-page plan for the student's own next project, small enough to start this week.

   What the lesson covers

   Prerequisites

   Lesson 1.3 (brief, then plan, then build); no checkpoint is needed and nothing is built. Having finished the course project helps, because the lesson uses it as the example.

   Covers

   • From idea to brief to plan in one sitting: the same method as sections 1 and 2, on a new idea.
   • What Claude Code builds well (pages, forms, a database, admin screens, connections to well-documented services) and where it needs more care (money, personal data, sign-in for the public, anything that must never be wrong or never be down).
   • Cutting scope to a first version: one user, one job, one screen, and a written "not in version one" list.
   • Build or use an existing service: a short set of questions, and how to check the answer instead of guessing.

   Do along

   In a new empty folder, take one idea of your own through the method with Claude in plan mode: a four-part brief, a build-or-buy check, a cut-down first version and a plan of five to eight steps, each with its own check.

   Done when

   The plan fits on one page and names the user, the one job, what "done" looks like, the "not in version one" list, the build-or-buy decision with its reason, the first step and the riskiest part.

   Homework

   Run the build-or-buy check on a second idea, show the plan to one person who would use the result and record what they did not understand, and book the first working session in the calendar.

   Open lesson 10.1 →

2. 10.2

   Taking payments with Stripe (test mode)

   60 min + 30 home

   The site sells one product, deposit or service package through Stripe's hosted checkout page in a test environment, and each payment appears in the CRM against the lead.

   What the lesson covers

   Prerequisites

   Checkpoint lesson-8.6 (lesson-5.7 is enough: lead capture, notifications and the CRM); a Stripe account, which is free to open and needs no business verification for testing.

   Covers

   • How hosted checkout works: the server creates a Checkout Session, the customer pays on Stripe's page, Stripe sends them back, and Stripe tells the server separately.
   • Stripe sandboxes and test keys, test card numbers, and why card details never touch the site.
   • Webhooks: why the success page alone is not proof of payment, signature verification, duplicate and late deliveries.
   • Recording the payment: a payments table, matching to a lead, the owner notification, the unmatched list.
   • Going live, described but not done: what changes, and the legal and tax questions the lesson does not answer (not legal advice).

   Do along

   Have Claude add a /pay page, the checkout and webhook endpoints and a payments view in the CRM; pay with a test card locally and on the live domain; watch a declined card and a forged webhook change nothing.

   Done when

   A test-card payment on the live domain appears once in /admin/payments and on the matching lead's card, the owner is notified, a declined card records no payment, and a request to the webhook address without a valid signature is rejected.

   Homework

   Replace the demo product with your own real product, name and price, still in the test environment; write the list of questions to settle before taking real money; and run the refund of a test payment in the Stripe Dashboard to see what your CRM does and does not show.

   Open lesson 10.2 →

3. 10.3

   Online booking

   60 min + 30 home

   A customer picks a free time slot on the site, and the booking is confirmed, notified and visible in the CRM, with no slot ever booked twice.

   What the lesson covers

   Prerequisites

   Checkpoint lesson-8.6 (lesson-5.7 is enough: lead endpoint, spam protection, notifications and the CRM with its business time zone).

   Covers

   • Availability as rules, not a list: working days and hours, slot length, minimum notice, how far ahead, days off.
   • Time zones: storing one moment, showing it in the business time zone.
   • No double booking: why checking first is not enough, and letting the database refuse the second booking.
   • Reusing what exists: the lead endpoint's validation and spam check, the email and Telegram notifications, the lead card.
   • What a first version leaves out: customer self-service changes, reminders, calendar sync, payment. Booking data is personal data (mechanics only, not legal advice).

   Do along

   Have Claude build /book, the availability settings and the bookings list in the CRM; make a booking as a customer; run a test that sends two bookings for the same slot at the same moment.

   Done when

   A booking made on the live domain shows the right local time in the confirmation email, in the Telegram message and in /admin/bookings; the slot disappears from /book; and of two simultaneous requests for one slot exactly one succeeds.

   Homework

   Set your real availability rules and days off, rewrite the confirmation email in your own words and read it on a phone, and write the cancellation and change procedure you will follow by hand.

   Open lesson 10.3 →

4. 10.4

   A site assistant

   55 min + 30 home

   A chat on the site answers visitors' questions from the business's own content only, says when it does not know, and hands the visitor over to the lead form.

   What the lesson covers

   Prerequisites

   Checkpoint lesson-8.6 (lesson-8.3 is enough); the Claude API key and monthly spend limit from 8.3.

   Covers

   • Grounding: the assistant answers from docs/content.md and the FAQ, and nothing else; "I don't know" as a correct answer.
   • Writing the rules: what it may answer, what it must never state (prices, dates, guarantees not in the content), and the handover to the form.
   • Visitor text is untrusted: instructions hidden in a question, and why the assistant can do nothing except reply.
   • Spending limits at three levels: per message, per conversation, per day, on top of the Console limit; an off switch.
   • Honesty and privacy: labelled as AI, conversations not stored, no contact details asked for in the chat, a line in the privacy page (mechanics, not legal advice).

   Do along

   Write the assistant's rules and a test set of questions, have Claude build the chat with the current Claude API documentation open, then run the test set: answerable questions, unanswerable ones, and attempts to make it break its rules.

   Done when

   On the live site the assistant answers a question covered by the content, declines one that is not and offers the form, refuses an instruction to ignore its rules, shows its AI label, and stops with a polite message once the daily limit is reached.

   Homework

   Add ten real customer questions to the test set and fix the content where the assistant could not answer, work out the cost of a typical conversation from the logged token counts, and ask one outsider to try to make the assistant say something untrue.

   Open lesson 10.4 →

5. 10.5

   Automations: work that happens without you

   55 min + 30 home

   Two jobs run without the owner: a weekly report arrives every Monday, and the Telegram bot answers "leads today" for the owner only.

   What the lesson covers

   Prerequisites

   Checkpoint lesson-8.6 (needs the scheduled job from 5.5, the Telegram bot from 4.5, the ad spend data from 7.8 and the Claude API key from 8.3).

   Covers

   • What is worth automating: repeated, rule-based, checkable; and what stays manual from the 8.1 report.
   • The weekly report on a schedule: numbers counted by code from the database, findings written by Claude from those numbers, the 5.5 scheduled job pattern, safe to run twice.
   • Receiving messages from Telegram: a webhook instead of polling, the secret header, and answering only the owner's chat.
   • Failure and silence: a report with numbers but no findings when the API fails, and how to tell a quiet week from a broken job.

   Do along

   Have Claude build the scheduled report endpoint and the reports page, trigger it by hand and compare three numbers with the CRM; then connect the bot's webhook, send /today from your own account and from a second account.

   Done when

   Triggering the weekly job on production stores one report in /admin/reports and sends it by email, a second trigger for the same week creates no duplicate, /today in the owner's chat returns the same count as the CRM, and the same command from another account gets no data.

   Homework

   Check the first report that arrives by itself against a manual count, add one more bot command for a number you look up every day, and write a one-page list of your automations with how you would notice each one failing.

   Open lesson 10.5 →

6. 10.6

   An internal tool from a spreadsheet

   50 min + 25 home

   A spreadsheet the business keeps by hand becomes a small private page in /admin with add, edit and one summary view.

   What the lesson covers

   Prerequisites

   Checkpoint lesson-8.6 (lesson-5.7 is enough: the admin area, login and CSV import); a spreadsheet the business already keeps, or the sample rota supplied with the lesson.

   Covers

   • Choosing the spreadsheet: one that is edited every week, by few people, and causes mistakes.
   • Reading it with Claude before building: what each column means, what is inconsistent, what the sheet is really used to decide.
   • From sheet to tables: one row per thing, lists instead of free text, what to leave behind.
   • The one summary view that answers the question the sheet was opened for.
   • Importing the old rows once, and proving the totals match.

   Do along

   Export the sheet as CSV, have Claude describe it and propose the tables, build /admin/rota (for Brightside: the cleaners' weekly rota) with add and edit and an hours-per-cleaner summary, import the rows and compare totals with the spreadsheet.

   Done when

   The page is reachable only when signed in, a shift can be added and edited and survives a reload, the imported row count equals the spreadsheet's, and the weekly hours per cleaner match a hand count for one week.

   Homework

   Use the tool instead of the spreadsheet for one real week and note what you missed, add one validation rule that would have prevented a past mistake, and decide what happens to the old spreadsheet.

   Open lesson 10.6 →

7. 10.7

   Beyond code: Claude for the rest of the business

   45 min + 30 home

   Three real work products for the student's business, each checked before it is relied on.

   What the lesson covers

   Prerequisites

   Lesson 1.4 (checking Claude's work); a CSV export from the business (the CRM export from 5.7 works) with contact columns removed. No checkpoint is needed and nothing is built in the repository.

   Covers

   • The same brief habit for non-coding work: purpose, context, what done looks like, constraints.
   • Analysing an exported CSV: asking for the method and the rows behind each number, and recounting one by hand.
   • Drafting a proposal or a policy document from your own facts, with marked gaps instead of invented ones.
   • Research with sources: every claim carries a link, and you open the links.
   • A slide outline: one message per slide, from a document you already trust.
   • What to verify before relying on the output, and what never to paste in.

   Do along

   In a folder outside the website project, produce an analysis of one CSV with three findings, one draft document, and one sourced research note or slide outline, running the verification step on each.

   Done when

   Three files exist for the student's own business; in each, one number, one fact or one source has been checked by hand and the check is noted at the end of the file.

   Homework

   Produce the fourth kind of work product you skipped in the lesson, write a personal checklist of what you verify for each kind, and reuse one of the prompts on next month's data to confirm it works a second time.

   Open lesson 10.7 →