Design the Data Model First

Working out the data model — the core entities, their fields, and how they relate — with Claude before building features on top. You settle the shape of the data first, because everything else (APIs, UI, business logic) is built against it, and getting it wrong later is expensive.

The data model is the most load-bearing early decision in a SaaS: it's referenced by every layer and the hardest thing to change once there's code and real data sitting on it. A wrong relationship or a missing entity that's cheap to fix on a whiteboard becomes a painful migration after three features depend on it. Designing it first — and using Claude to pressure-test it against the flows you'll need — surfaces those problems while they're still just edits to a schema. It also makes feature-building faster: with a settled model, each feature is 'read and write these known entities' instead of inventing structure as you go.

Right after the spec, before building features, on any app with non-trivial state: relationships between users, resources, and actions; anything with billing, ownership, or history. The more the flows touch shared data, the more front-loading the model pays off.

Truly stateless or single-entity tools where the 'data model' is one table — designing it formally is overkill. And don't gold-plate for imagined future features; model what the v1 spec actually needs, not everything you might someday want.

Before we build features, design the data model for this app: <the app + its v1 spec>. Give me the core entities, their key fields, and the relationships between them (one-to-many, many-to-many). Then pressure-test it: walk through each main user flow from the spec and confirm the model supports it — flag any flow that would need a schema change. Once it holds, generate the schema and migrations.

For the invoicing tool, modelling first reveals that an invoice needs line items as their own entity (not a text blob) and that 'client' must be separate from 'user' so one account can bill many clients. Caught on the whiteboard, these are two lines in a schema. Caught after building the invoice UI, they'd have been a migration plus a rewrite of everything that read an invoice.

Have Claude derive the data model directly from the spec's user flows, then generate not just the schema but the migrations and a few seed records — so you can immediately build and test a vertical slice against real-shaped data. Keep the model in your project's source of truth so later feature prompts inherit it and don't reinvent structure that already exists.

• Letting the schema emerge feature-by-feature, so each new feature bolts on structure that contradicts the last.
• Modelling for hypothetical future features instead of the flows the v1 spec actually requires — premature generality.
• Skipping the flow walk-through, then discovering mid-build that a core user story the model can't support.