Step 5: Sketch the Data Model
Most apps are really about data: what you store and how the pieces relate. A quick data model sketch saves you from confused, inconsistent code later. You don't need a diagram — a list of fields is enough.
For the book tracker, there's one main thing — a Book:
Book
- id: unique string
- title: string
- author: string
- status: "to_read" | "reading" | "finished"
- rating: number 1–5 (only if finished)
- addedAt: date
Even this tiny sketch makes decisions explicit: ratings only exist for finished books, status is one of three fixed values, and every book has an id. When you hand this to the AI, it stops guessing field names and builds consistently.
The reason to nail this down early is that field names leak everywhere. Once the AI writes code that reads book.rating, that name shows up in the form, the list view, the storage layer, and any later feature you add. If you let it drift — rating in one place, stars in another, score in a third — you get bugs that are tedious to chase. A six-line data model is the cheapest insurance against that.
A short, copy-pasteable spec block tends to work better than prose for the AI. Here's the same model written as a you'd actually send:
Use this exact data shape for a book. Don't add fields I didn't list,
and don't rename these:
Book {
id — unique string, generated on creation
title — string, required
author — string, required
status — one of: "to_read" | "reading" | "finished"
rating — integer 1–5, present ONLY when status is "finished"
addedAt — ISO date string, set when the book is added
}
If you think a field is missing, ask me before adding it.
That last line — ask me before adding it — is doing real work. It turns the AI from a guesser into a collaborator and keeps the data model yours.