To describe your data so AI builds your app correctly, state five things in plain words: the things the app stores (customers, appointments, products), the details of each, how they relate ('each customer has many appointments'), the rules (required fields, unique values, order statuses), and who can see and edit each. Ask the agent to show you the data design for review before it builds any pages.
- how to design a database for my app
- database design prompt for ai
- design a database with ai
- how to describe data to an ai app builder
- database without coding
How do you describe your data so AI builds the app right?
To describe your data so AI builds your app correctly, answer five questions in everyday language: what things does the app store, what are the details of each, how do they relate, what rules govern them, and who sees and edits each? You do not need SQL or table jargon; the agent turns your description into a real database design, and you review it.
Why focus here? Because the database is the foundation every page sits on. Changing a button color takes a minute. Discovering that a customer needs more than one address after 500 orders means carefully reshaping existing data. A clear description up front saves all of that. For the fundamentals without prompts, read database design for non-developers.
The interface is what customers see; the data is what the app remembers. A beautiful interface cannot save an app that remembers wrong.
From your business to things and details: a clinic example
The easiest start: write down every noun that keeps coming up when you explain your business to a new employee. In a clinic: patient, doctor, appointment, service, payment. These are entities, and each becomes a table. Then ask of each: what do I need to know about it?
| Thing (entity) | Details (fields) | Relationship |
|---|---|---|
| Patient | Name, phone number, date of birth, gender, notes | Has many appointments and many payments |
| Doctor | Name, specialty, working days and hours | Has many appointments and offers specific services |
| Service | Name in Arabic and English, duration in minutes, price | Booked in many appointments |
| Appointment | Date, time, status, reception notes | Belongs to one patient, one doctor and one service |
| Payment | Amount, currency, method, status, transaction ID | Belongs to one appointment |
Relationships in plain language: three sentences are enough
Relationships are what gets misread most when left unstated. You do not need terms like one-to-many; three sentence patterns are enough:
- 'Each [A] has many [B]': each customer has many orders; each store has many products.
- 'Each [B] belongs to exactly one [A]': each order belongs to one customer; each payment belongs to one order.
- '[A] and [B] connect through [C]': patient and doctor connect through the appointment; student and course connect through an enrollment, which has a date and a progress percentage.
The third pattern is the most important and the most forgotten. When the relationship itself has details (appointment date, quantity in an order, a student's grade), it is a thing in its own right and deserves a name. Example: product and order connect through an order line that stores quantity and the price at purchase, even if the product price changes later.
The rules you must write down
Rules make data trustworthy. Without them the app accepts a duplicate phone number or two overlapping appointments for the same doctor. The key rules, with ready sentences:
| Rule | Why it matters | Sentence for the prompt |
|---|---|---|
| Required fields | Prevents incomplete records | Phone number and name are required for customers |
| Unique values | Prevents duplicates | Phone number is unique; no two customers share it |
| Clear statuses | Controls the workflow | Order statuses: new, confirmed, out for delivery, completed, cancelled |
| No conflicts | Prevents double booking | No overlapping appointments for the same doctor |
| Deletion | Keeps financial history | Never delete orders; cancelling only changes status |
| Amounts | Accurate calculations | Amounts are decimals with currency; VAT stored separately |
| Dates | Avoids timing errors | Store dates in Gregorian, Riyadh time; display Hijri and Gregorian |
| Phone numbers | Consistent data | Normalize phone numbers to international 966 format before saving |
Note the deletion rule in particular. In business apps you rarely want to truly delete an order or payment; archive it or change its status so reports and invoices stay correct.
Permissions and privacy: who sees what?
Every type of data has an audience. Describe it in sentences like: 'patients see only their own appointments, doctors see their patients and schedule, reception sees all appointments but not medical notes, the manager sees financial reports.' This is role-based access control; more in roles and permissions in your app.
- Collect only what you actually need; do not ask for ID numbers or birth dates you never use.
- Flag sensitive data (health, financial) and show it to as few roles as possible.
- Ask for an audit log on important data: who changed what, and when.
- Never store card numbers in your database; the payment gateway handles them.
A full database design prompt
Here is an example for a pre-order dessert shop. Notice it asks for the design to be shown for review before any page is built; that is its most important line.
Before building pages, design the database and show it to me in plain language for review. Things: - Customer: name, phone number (required, unique, 966 format), addresses (more than one; each with city, district, street, building number, postal code and a map pin). - Product: name in Arabic and English, description, photos, price in SAR, available or not, daily quantity limit. - Order: belongs to one customer and one address; pickup date and time (at least two days ahead); status (new, confirmed, preparing, delivered, cancelled); subtotal, 15% VAT, total. - Order line: links order to product, with quantity and price at time of purchase. - Payment: belongs to one order; method (mada, Apple Pay, Tabby), amount, status, gateway transaction ID. Rules: reject an order if total quantity exceeds a product's daily limit for that day. Orders are never deleted; cancelling only changes status. Dates in Riyadh time. Permissions: customers see only their orders. Kitchen staff see today's orders and lines without payment data. The manager sees everything. Do not add tables I did not mention; if something seems missing, suggest it in a list.
Try it in FanannHow do you change data after launch without losing anything?
You will need to change your data: a new field, splitting one thing into two, or a new relationship. Once you have real customers, follow these steps:
- 1Confirm the backup
Before any data change, make sure a recent backup exists. Fanann takes daily backups, and you can roll the app back instantly.
- 2Ask to preserve data explicitly
'Add an optional date of birth field for customers, without deleting or changing any existing data.'
- 3Ask for a migration plan
If the change touches existing data, such as moving addresses from one field into an addresses table, ask how current data will be moved before it is done.
- 4Test first
Try the change in a test environment, then check that old orders and reports are still correct.
More in backups and disaster recovery.
Common mistakes when describing data
- 'The app stores orders'
- Customer address as one text field
- Orders read the product's current price
- Cancelled orders get deleted
- All staff see everything
- An order belongs to a customer, with lines, status, total and VAT
- Multiple addresses with National Address fields and a map pin
- Price and VAT stored on the order line at purchase
- Cancelling is a status; the record stays for reports
- Role-based permissions; sensitive data for the fewest people
Key takeaways
- The database is the app's foundation; fixing it before building is far cheaper than after.
- Describe things, details and relationships in plain sentences like 'each order belongs to one customer'.
- State rules explicitly: required, unique, statuses, and what happens on delete.
- Define who sees and edits each type of data, and collect only the personal data you need.
- When changing data later: backup, preserve existing records, and test before publishing.
Frequently asked questions
How do I design a database for my app with no experience?
Do I need to learn SQL?
What if I find the data design is incomplete after launch?
What is the difference between a field and an entity?
Where is my app's data stored in Fanann?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Prompts for database design: describe your data so the app is right” https://fanann.com/en/blog/prompts-for-database-design/ My question: how to design a database for my app Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.