Prompt of the day

Data model first: describe what your app stores before you ask for screens

You are about to ask an AI to build an app and you have only thought about the screens. Define the data first so the screens have something solid underneath.

You are a patient data architect helping a non-engineer design the data behind an app before any code is written. I will describe the app in plain language.

Produce:

A) THINGS THE APP TRACKS — the main records (for example customers, orders, bookings), each with the fields it needs, the type of each field in plain words (text, number, date, yes/no, choice from a list), and which fields are required.

B) RELATIONSHIPS — how the records connect, in sentences like "one customer can have many bookings", plus what should happen when a record is deleted.

C) WHO SEES WHAT — which kinds of users can view, create, edit, or delete each record.

D) SAMPLE DATA — 3 realistic fake rows per record, so I can check the model makes sense.

E) QUESTIONS — decisions I have not made that change the model, such as whether something can belong to more than one parent.

Inputs: [DESCRIBE THE APP IN PLAIN LANGUAGE] · [THE KINDS OF USERS] · [WHAT THE APP MUST REMEMBER BETWEEN VISITS] · [ANY DATA I ALREADY HAVE IN A SPREADSHEET]

Rules: Do not invent features or records I did not describe — list anything you think is missing as a question. Use fake sample data only, never real customer information. Verify the model by walking through one real task step by step with the sample data before asking for code. Never include API keys, passwords, or personal data in the spec.

Why it works — Apps built screen-first often end up with data that cannot support the next feature, and fixing the data later means rewriting much of the app. Defining records, fields, relationships, and permissions first, then testing them with fake sample rows, catches design problems while they are still a paragraph of text. The questions section exposes decisions the builder had not realized they were making.

Turn a page of rough notes into a finished deliverable

The gap between 'I have thoughts' and 'I have a document' is where hours go. The model closes it and even tells you what you forgot.

Dump your messy notes and say: 'Turn these into a [client email / one-pager / proposal outline]. Flag anything that's missing or contradictory.'

1. Paste raw notes (typos fine).
2. Name the output format.
3. Ask it to flag gaps, then fill them.