Where the Data Lives
The Record Two People Plan Around
Up to now, a booking has been something on a screen. The moment the page becomes the way the business takes bookings, it becomes something else: a record two people plan their Saturday around. The groomer sets up the table for it. The owner drives across town for it. That record has to live somewhere, and the somewhere is a database — which sounds technical but has a plain model: a filing system the app trusts completely. Whatever the filing system says, the app repeats, without doubt or embarrassment. It will show a free slot that is not free, or an appointment for a dog that does not exist, with total confidence. The screen is only ever a window onto those files. This module is about the files themselves — what goes into them, what happens when they are wrong, and who is allowed to open the drawer.
- A real booking is a promise two people plan around, not a row on a screen
- A database, plainly: a filing system the app trusts completely
- The app repeats whatever the files say, with total confidence
- The screen is only a window — this module is about the files behind it
Wrong Data Is Worse Than No Data
Here is a distinction worth carrying for the rest of this course. If a booking goes missing, someone notices quickly. The customer emails, the page looks empty, the gap announces itself. If a booking is wrong, nothing announces anything. The groomer preps for a large dog and a small one arrives. A customer turns up on Tuesday for an appointment the system quietly moved to Thursday. Both sides did exactly what the record told them, and the record lied. Wrongness is quiet, and that is what makes it expensive: it spends trust the business took years to earn, one confused doorstep at a time. Absence announces itself; wrongness does not. That one sentence explains most of what this module asks of you — the care about what is recorded, the copies, the checks — because you cannot fix an error you never hear about.
- Missing data announces itself; wrong data stays quiet
- The groomer preps for a dog that isn't coming — both sides trusted the record
- Wrong data spends the business's trust one confused doorstep at a time
- You cannot fix an error you never hear about
Decide What Gets Recorded, on Purpose
Your prototype already records things. What it records was decided during the Vibecoding weekend, mostly by the AI, mostly by accident, and nobody looked. Now is the moment to look. Three questions do the work. What is recorded — a name, an email, a slot, a dog? What is required — can a booking exist without an owner's email, and should it? And the surprisingly deep one: what is 'one booking', exactly? The customer with two dogs on the same morning — is that one booking or two? The groomer needs double the time either way, but the record has to say so somewhere. If the answer is fuzzy, the records will be fuzzy, and the truth arrives on a busy Saturday. None of this needs technical skill. It needs decisions, written in plain words, that you hand to the AI as the rules of the filing system.
- The prototype decided what to record by accident, and nobody looked
- Ask what is recorded, what is required, and what 'one booking' even means
- Two dogs on one morning: one booking or two? Fuzzy answers make fuzzy records
- These are decisions in plain words, not technical work
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.