Why you need to model your data before you vibe code it, and how to do it without a database background
You need a data model because the shape of what your app stores is far more expensive to change than the code around it. Once real users have created records, reorganizing how that data is structured means touching everything they already made, not just editing a function. Sketching your entities, their key fields, and how they connect, in plain English, before you write a prompt lets you catch structural mistakes on paper instead of in a live database. You do not need a database background to do this: a short list of nouns, their fields, and the phrases "has many" and "belongs to" get you there.
I'm Mahmoud Zalt, an independent senior AI systems architect. I've shipped production software since 2010, that's 16 years, and I founded Sista AI (sistava.com), where I run a workforce of autonomous AI agents in production, not demos. Every system I've built started with this exact step: a plain sketch of what the app remembers, done before any code existed. This article adapts that same lesson from The Vibecoder's Handbook into a quick, standalone read.
What "data modeling" actually means, in plain English
Strip away the jargon and a data model is just an answer to one question: what does your app need to remember, and how do those memories relate to each other? Nothing more mysterious than that. If your app is a habit tracker, it remembers people and the habits they check off. If it's a booking tool, it remembers customers, time slots, and the appointments that link the two. You already know these things intuitively, you're just not used to writing them down before you start building.
The technical word for this plan is a schema. A schema is the shape of what you store, separate from where you store it. Whether that ends up in Postgres, SQLite, or a spreadsheet-like tool is a later decision, and a much smaller one than most people think. Right now you're only drawing the plan, not picking the storage, and that separation matters: you can change your storage choice fairly easily later, but you cannot easily change the shape of data that real users have already filled in.
That plan has exactly two parts:
- The things you keep, called entities.
- The links between those things, called relationships.
Get both of those right on paper, in your own words, and the actual build becomes mostly transcription for the AI agent. Get them wrong, or skip them, and you're asking the agent to invent structure on the fly, which it will do, just not the way your product actually needs. Most people who skip this step aren't being careless, they simply don't know this is a step at all. It rarely gets mentioned before someone hits the consequences of skipping it.
Step one: list your entities and their key fields
An entity is one kind of thing your app stores, like a User or an Order. A field is one piece of information that entity holds, like a user's email or an order's total.
Name every entity as a singular noun, never a plural, and never a verb. Then list only the fields the app genuinely needs for what you're building right now, not every detail you can imagine adding someday. Write it as a plain table, nothing more elaborate.
| Entity | Key fields |
|---|---|
User | name, email, password |
Order | total, status, createdAt |
Product | name, price |
Quick test: if you can't name an entity as a single noun, it's usually two entities hiding inside one. "UserOrders" is not an entity, it's a User and an Order that you haven't separated yet.
Keep the field list short on purpose. It's tempting to add every field you might eventually want, a middle name, a loyalty tier, a referral code, but each one you add now is a promise you have to keep true for every record forever after. If a field doesn't serve a feature you're actually building this week, leave it out and add it later when the feature is real. Trimming the list is not laziness, it's the entire point of sketching before building.
Step two: draw the relationships between them
A relationship is how two entities connect. Most connections you'll write are one-to-many: one entity owns many of another, and each of those belongs to exactly one owner.
A User has many Orders, and each Order belongs to exactly one User. That's one-to-many, and it covers most of what you'll model. When both sides can have many of each other, say a Post has many Tags and a Tag covers many Posts, that's many-to-many, and you just note it as such.
State every relationship in that plain "has many" and "belongs to" form. A small shop's model, sketched this way, nests naturally:
User
has many: Order
has many: LineItem
references: ProductEach level of indentation is a "belongs to": a LineItem sits under one Order, which sits under one User. It reads unambiguously to you and to whatever AI agent builds from it, and it needs no diagramming tool, no arrows, no software.
What happens when you skip this and go straight to prompting
Here's the part most people learn the expensive way. If you skip the model and just describe features to an AI agent one prompt at a time, the agent doesn't refuse to build a database, it builds one anyway. It just builds one by guessing, one prompt at a time, with no memory of the decisions it made three prompts ago.
The result is predictable: a users table in one prompt and a Users table in another, an order that stores a copy of the customer's email instead of a link to their account, a "tags" field that's a single text string in one screen and a proper list somewhere else. None of these mistakes show up while you're testing with three fake records. They show up after real users have filled the database, when fixing them means writing migration code and hoping you don't corrupt anyone's data along the way.
It compounds too. Each new feature prompt has to reconcile with whatever the agent guessed before, and when it can't tell what already exists, it either duplicates a field under a slightly different name or quietly reinterprets one that's already in use. A few dozen prompts in, you end up with a database that technically works but that nobody, including the agent, can fully explain anymore. Debugging it means reading through migration history like an archaeologist instead of just checking a plan.
A data model prevents this because it gives the agent one fixed structure to build against instead of a blank page every time. This is the whole reason The Vibecoder's Handbook puts data modeling before any building step: the ten minutes it takes to sketch entities and relationships buys you weeks you'd otherwise spend untangling a schema that grew by accident.
Common mistakes when people first try this
- Adding fields for features you haven't scoped yet. Every field you write down is one more thing that has to stay true later. If a feature isn't real yet, its fields don't belong in the model yet either.
- Naming entities as plurals or vague nouns. "Users" instead of
User, or "Data" instead of a real entity name, both signal you haven't actually decided what the thing is. - Jumping straight to SQL or picking a database product. That's a storage decision, and it comes later. Doing it now just adds technical noise to a plan that's supposed to stay readable in plain English.
- Forgetting a relationship exists at all. If two entities interact anywhere in your app, they need a stated relationship. An unstated one is exactly what an AI agent will guess wrong.
- Treating the sketch as permanent. It's a thinking tool, not a contract. You'll refine it as you learn more, that's expected and fine.
Do this now: a five-minute version
You don't need a diagramming app or a database course to start. Open a blank doc and do this:
- List every entity in your app as a singular noun. If you can't name it in one word, split it into two entities.
- Under each entity, write its key fields in a simple table, only the ones your current features actually need.
- For every pair of entities that interact, write one line stating the relationship as "has many" or "belongs to."
- Read it back as if you were a stranger. If someone else could tell what your app remembers just from this sketch, you're done.
That's the entire exercise. Hand this sketch to your AI agent alongside your feature prompts, and it now has one consistent structure to build against instead of one it invents fresh every time.
Frequently Asked Questions
Do I need to know SQL or databases to model my data?
No. Data modeling at this stage is plain English: nouns for entities, a short list of fields for each, and "has many" or "belongs to" for relationships. SQL, table types, and specific database products come later, and by then most of the hard thinking is already done.
How detailed should my data model be before I start vibe coding?
Detailed enough that a stranger could read it and know what your app remembers, no more. List only the fields your current features genuinely need. Fields for features you haven't built yet just add things you'll have to keep true later for no benefit today.
What's the difference between an entity and a field?
An entity is a kind of thing your app stores, like a User or an Order, always named as a singular noun. A field is one piece of information that entity holds, like a user's email or an order's total. Entities are the nouns, fields are their details.
What if my data model turns out to be wrong later?
That's normal and expected. The sketch is a thinking tool, not a permanent contract. You'll adjust it as you learn more about your own product. The point isn't to get it perfect on the first try, it's to have a stated structure instead of no structure at all.
Can I skip this step if I'm building something small?
You can, but even a small app usually has at least two or three entities that relate to each other, and that's exactly where an AI agent starts guessing if you haven't told it otherwise. Five minutes of sketching is cheap insurance even for a small build.
The short version
Model your data before you prompt, not after. It costs you a few minutes on paper and saves you from untangling a guessed-together database once real users are relying on it. This article covers the short version. The full chapter in The Vibecoder's Handbook walks through modeling the data for your own project, step by step, with more worked examples.
