The Weekend Build and the Real Product
The Comparison, Part One: The Data
This is the lesson the whole course has been walking towards: the weekend build and the real product, side by side, across fifteen dimensions. Take the first five — the data — and hold both versions of the groomer's app in mind. Where the data lives: wherever the tool happened to put it, versus a database chosen on purpose, with a shape you decided. What happens when data is wrong: a shrug, versus a plan — because a wrong booking now costs a real Saturday. Backups you have actually restored: none, versus a restore you have practised and timed. Accounts and resets: one shared login, versus real accounts with the weekly lockout handled calmly. Who can see what: whoever finds the link, versus the groomer seeing everything and each customer seeing only their own bookings — enforced by the product, not hidden by the screen. Five dimensions, and every one invisible in a demo.
- Where the data lives and what shape it takes: accidental versus decided
- Wrong data: a shrug versus a plan, because wrongness costs real Saturdays
- Backups: a hopeful copy versus a restore you have actually practised
- Accounts, resets and who-sees-what: enforced by the product, not the screen
Part Two: Services and Shipping
Dimensions six to nine cover the services you stand on and how change travels. Email that actually arrives: the weekend build sends email and hopes; the product uses a proper email service and treats a confirmation landing in spam as a broken feature, because from the customer's side it is a lost booking. Taking payment: the weekend build never touches money — an invoice sent by hand, exactly as the not-list decided; the product may still not, and if it ever does, a payment provider carries it, never your own pages. Getting changes to users: editing the live thing, versus two copies — changes made where customers aren't, then shipped deliberately, with the checks running first. Undoing a bad change: panic, versus rollback — the steps for putting back the last good version, known before they were needed. The pattern repeats each time: the demo version merely exists; the product version is decided, practised and owned.
- Email that arrives is a feature — a confirmation in spam is a lost booking
- Payment rides with a payment provider, or stays an invoice sent by hand
- Changes are made where customers aren't, then shipped deliberately
- Rollback: the steps known before they were needed, not discovered during
Part Three: Running It
The last six dimensions are about the years, and they are the ones the weekend build cannot even see. Knowing it broke: silence, versus a heartbeat, an error log, and a weekly number you would notice going to zero. Cost at real usage: a free tier, versus a bill you have estimated and capped. Support — who answers: nobody, versus you, on one channel you actually read, with an honest reply-time promise. Updates and rot: "finished", versus the day a month this module priced. Handover — could anyone else run it: no, versus the one honest page from the last lesson, tested on a friend. And the second year — upkeep versus new features: never considered, versus budgeted, so that improvement is a choice rather than a rescue. Read the fifteen back to back and something stands out. Barely any of them are about code. They are decisions, habits and honesty — which is why they were always yours to do.
- Knowing it broke: silence versus a heartbeat and a number you watch
- Cost, support and upkeep: estimated and owned versus never considered
- Handover: one tested page versus a product trapped in one head
- Barely any of the fifteen are about code — they are decisions and habits
The Ledger, Complete
Now close the ledger, every line filled in. The prototype — the Vibecoding weekend — was 2 days. Exploration, scope and the plan: 3. Building the rest, with checks that run without you: 4. Data done properly, accounts, and the hidden services: 9 — still the biggest line. Shipping, watching and the launch fixes: 5. Total to a real first version: 23 days, of which the demo was 2 — under a tenth. Then the running of it: from roughly £0–15 a month as a prototype to £40–60 a month with 200 customers, and illustratively £120–200 a month at 1,000 users. Support: 2–4 hours a week, indefinitely. In year two, about a day a month of upkeep before any new feature. Sit with that ratio, and hear what it actually means. The point was never to discourage you. Every line on this page was walkable. None needed an engineering degree. Most needed a decision rather than a skill — and you have now watched every one of them being made.
- Demo 2, plan 3, build 4, below-the-screen 9, shipping, watching and fixes 5: 23 days
- Roughly £40–60 a month at 200 customers; illustratively £120–200 at 1,000
- Support 2–4 hours a week; upkeep about a day a month in year two
- Every line was walkable — most needed a decision, not a skill
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.