# No-Code Database Schema Planner

Designs a clean, scalable database schema in plain language for a non-technical builder to hand directly to an AI app builder or Supabase, avoiding common structural mistakes.

## Prompt

You are a database architect who explains schema design in plain language for non-technical builders using tools like Lovable, Supabase, or Bolt.

App description: {{app_description}}
Key things the app needs to track: {{things_to_track}}
How users interact with the data (who creates/views/edits what): {{user_data_interactions}}

Do the following:
1. Identify the core entities (tables) needed, named clearly and simply.
2. For each entity, list its key fields with a plain-language description of what each field stores and its likely data type (text, number, date, true/false, etc.).
3. Define the relationships between entities (e.g., one user has many orders, one order belongs to one user), explained in plain language, not database jargon.
4. Flag any common structural mistakes this schema could fall into (e.g., storing a list of items as one text field instead of a separate related table) and explain briefly why it matters.
5. Write the final schema as a ready-to-paste prompt formatted for an AI app builder to implement directly.

## Best for

Non-technical founders and builders using Lovable, Bolt, or Supabase who need a clean, well-structured database design before building, to avoid costly restructuring later as the app grows.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Describe your app and list the key things it needs to track, even in plain everyday language.
- Explain how different users interact with the data (who creates, views, or edits what).
- Review the flagged structural mistakes before building, since fixing schema issues later is often more costly than getting it right upfront.
- Paste the final ready-to-paste schema prompt into your AI app builder or database tool.

## Customization tips

- If you're using a specific tool (Supabase, Firebase, Airtable), mention it so field types and relationship syntax match that platform's conventions.
- For apps with complex permissions (e.g., admins vs regular users), describe the roles explicitly so access-related fields are included.
- If you expect to add more features later, mention your roadmap briefly so the schema leaves room to expand without a full restructure.

## Example input

App description: A marketplace where sellers list handmade products and buyers place orders. Things to track: Products, sellers, buyers, orders, and product reviews. User interactions: Sellers create and edit their own products; buyers browse products and place orders; buyers can leave one review per purchased product.

## Example output

Core entities including Users (with a role field distinguishing buyer/seller), Products (linked to a seller), Orders (linked to a buyer and one or more products), and Reviews (linked to a specific product and the buyer who purchased it), plain-language relationship definitions like 'one seller has many products' and 'one order can include many products,' a flagged mistake warning against storing order items as a single text list rather than a separate order-items table, and a final ready-to-paste schema prompt for Supabase.