How to Plan Your Data Model Before Building With AI

Planning your data model before you build an app with AI means writing down the entities your app manages, how they relate to each other, and which fields must be unique or required, before you write a single prompt to an AI builder. This is not the same as choosing a database. Picking Postgres or SQLite is a technology decision that comes later. Entity planning is a design decision: what are the real world things this app tracks, and how do they connect. Skip it and an AI app builder will still produce something that runs. It works fine for the demo. It falls apart the moment you add a second real feature, because the AI guessed at relationships nobody wrote down.

Data modeling is a different decision than picking a database

These get conflated because both happen at the start of a project and both involve the word schema. Choosing a database is about the engine: some AI builders hand you a managed Postgres database by default, while others expect you to connect your own before anything persists. That's a real decision, and if you haven't made it yet, choosing a database for an app you're building with AI is worth a look on its own. Data modeling comes first and doesn't depend on the engine. Whether you land on Postgres, SQLite, or a hosted backend, a Customer is still a Customer, a Rental still needs a start date and an end date, and an equipment serial number still needs to be unique. Get the entities right and the database choice gets easier, because you actually know what you're asking the engine to do.

A worked example: a rental tracker for a landscaping company

Say the app is a tool for a landscaping company to track which equipment is checked out to which job site, and log when it comes back for maintenance. Before opening an AI builder, the entity list looks like this:

• Customers, the people or job sites renting equipment

• Equipment, individual tools and machines, each with a serial number

• Locations, where a piece of equipment currently lives, yard or a customer's site

• Rentals, a record connecting one customer to one piece of equipment for a date range

• MaintenanceLogs, service history tied to a piece of equipment

The relationships matter more than the entity names. A customer has many rentals. A piece of equipment also has many rentals, but at any moment it should only be active on one. A rental is really the join between customer and equipment, carrying its own data, start date, end date, return condition, that doesn't belong on either side. Equipment has many maintenance logs, and those logs need to keep accumulating even after equipment is retired.

customers        (id, name, email UNIQUE, phone)
locations        (id, name)
equipment        (id, name, serial_number UNIQUE, location_id -> locations.id, status)
rentals          (id, customer_id -> customers.id, equipment_id -> equipment.id,
                  start_date, end_date, returned_at)
maintenance_logs (id, equipment_id -> equipment.id, note, performed_at)

Five entities, four relationships, two unique constraints. Written down before any prompting.

Three questions to answer before you open the AI builder

What's the source of truth for each fact?

Every piece of data should have exactly one place it's stored, computed everywhere else from there. In the rental tracker, “is this equipment currently available” is not a fact you store, it's derived by checking whether an open rental, one with no return date, exists for that equipment. Let the AI builder store a status field on equipment and also infer availability from rentals, and the two will disagree the first time someone forgets to check something back in.

What needs a unique constraint?

Serial numbers, customer emails, anything a user or a report will look up by value instead of internal ID needs a unique constraint at the database level, not just a check in the app's form. AI builders default to auto incrementing IDs and skip constraints unless you ask, because demo data never has duplicates.

What will need to scale or evolve independently?

Maintenance logs and rentals grow forever. Customers and equipment grow slowly. That's a hint they belong in separate tables with foreign keys, not nested inside a JSON blob on the equipment record, even though nesting looks simpler in a first prompt. The same question applies to anything you expect to report on later: total hours a piece of equipment was rented last quarter needs to come from queryable rows, not a running counter that overwrites itself.

The real failure mode: fine for the demo, breaks on feature two

Ask an AI builder for a rental tracker for landscaping equipment with no entity list and it produces something reasonable looking. It'll probably store a status column on equipment, available, rented, maintenance, and skip a separate rentals table entirely, because that's enough to make the first screen work: a list of tools with a status badge. It passes the demo.

The second real feature is usually something like show me the rental history for this piece of equipment, or let two people reserve the same tool for different weeks. Neither is possible with a status column. There's no rentals table to query for history, and no way to represent that a tool is booked for next week but free today. Fixing it means a migration, rewriting the screens that assumed one status per tool, and reconciling whatever data already got entered. None of that is unusual. It's the standard cost of letting an AI builder invent the schema instead of handing it one.

Turning the entity list into a prompt

The entity list above is most of what a technical spec needs. Feed it to the builder directly, or turn it into a fuller technical spec document first if the app has more than a handful of entities or you're handing it to a team. Either way, the prompt should state entities, relationships, and constraints as facts, not suggestions:

Build a rental tracking app with these entities and relationships:
- customers: name, email (unique), phone
- equipment: name, serial_number (unique), current location,
  status derived from rentals (not stored)
- locations: name
- rentals: links one customer to one equipment for a date range
  (start_date, end_date, returned_at nullable)
- maintenance_logs: linked to equipment, one row per service event, never deleted

Enforce unique constraints on customers.email and equipment.serial_number.
A piece of equipment is "available" only if it has no rental row
with returned_at = null.

That's a different prompt than build me a rental tracker, and it produces a different, sturdier schema. The same approach carries over to any app you build with AI. If you're starting from a blank prompt, the general process for building an app with AI covers where entity planning fits alongside the rest of the setup. If the app is closer to tracking stock than tracking rentals, building an inventory app with AI works through a similar entity list for that specific case.

Frequently asked questions

Do I need to know SQL to plan a data model before using an AI app builder?

No. Entity planning is a list of nouns, Customer, Equipment, Rental, their fields, and which fields link to which other entity. Writing “a rental belongs to one customer and one piece of equipment” doesn't require SQL. The AI builder translates that into tables. Your job is making sure the relationships and constraints are explicit before it guesses.

What's the difference between an entity and a database table?

An entity is a real world thing your app needs to track, independent of how it's stored. A table is one way to store it. Most entities become one table each, but not always. A many to many relationship, like customers renting multiple pieces of equipment over overlapping periods, often needs its own table, rentals, even though rental wasn't an obvious noun when you started describing the app.

How many entities should a first version of an app have?

Small is fine. Three to six entities covers most first versions. The rental tracker above has five. If you're listing more than eight or nine before you've built anything, the app is probably trying to do too much at once, not that you need a bigger schema.

Should I let the AI builder choose the database, or decide on entities first?

Decide the entities and relationships first regardless. The database choice, Postgres versus SQLite versus a hosted backend, is a separate step and doesn't change what a customer or a rental is. It's worth comparing database options once you know your entities, since some databases handle certain relationship patterns better than others.

What actually breaks if I skip this and let the AI improvise?

Not the demo. The AI builder produces a schema that satisfies whatever you described, and if you described one screen, it'll build a schema that supports one screen. The failure shows up on the second feature that needs a relationship or a history the first schema didn't anticipate, at which point fixing it means a migration instead of a prompt.