{
  "slug": "builder",
  "name": "Your AI builder's own backend",
  "summary": "Use the database and sign-in built into the tool you're already in: Lovable Cloud, Bolt's database, Replit's database and auth, or v0 with a Vercel-connected database.",
  "audience": [
    "builders"
  ],
  "bestFor": "People building in Lovable, Bolt, Replit or v0 who don't want another account.",
  "cost": "Included in the builder's plan, usually with a small monthly allowance.",
  "rank": 1,
  "covers": "full",
  "docs": [
    {
      "label": "Lovable Cloud",
      "href": "https://docs.lovable.dev/features/cloud"
    },
    {
      "label": "Lovable + Supabase",
      "href": "https://docs.lovable.dev/integrations/supabase"
    }
  ],
  "body": "## How to use this recipe\n\nPaste it into your AI builder after adding the back-office screens. Builders can create tables and sign-in for you, but they don't always lock the data down unless asked — so ask explicitly, and check.\n\n1. **Turn on the built-in backend.**\n   - **Lovable:** enable Lovable Cloud (it runs on Supabase, so ask Lovable to use the SQL and policies from the Supabase recipe — `get_recipe` with slug `supabase` if your editor has the CopyPasteUI MCP).\n   - **Bolt:** use Bolt's built-in database and authentication (or connect Supabase).\n   - **Replit:** use Replit's built-in database and Replit Auth.\n   - **v0:** connect a database from the Vercel Marketplace (Supabase or Neon) and follow that recipe.\n2. **Create the tables** in the data model above, with exactly those names and fields.\n3. **Lock the data down** with the access table above. Say it in these words:\n   > Turn on row-level security (or the platform's equivalent) for every table. Public visitors may only read the menu, opening hours, closures and settings, and may only create bookings, orders and enquiries — never read them. Signed-in staff read bookings and orders and may change only their status. Managers and owners manage everything else; only the owner changes settings and staff.\n4. **Protect /admin.** Ask for every `/admin` page to check the signed-in user on the server and redirect to `/admin/sign-in` when signed out, and for `/admin` to be left out of the menu and sitemap.\n5. **Make the first owner.** Sign up once, then ask the builder to mark that account as `owner` in the staff table.\n\n## Check it before you publish\n\n- Open the site in a private window, go to `/admin` — you should land on the sign-in page.\n- Submit the contact form while signed out, then try to read enquiries without signing in (ask the builder \"can a signed-out visitor read the enquiries table?\"). The answer must be no.\n- Sign in as a staff account and check you can't open Settings or Staff.\n\n## Leaving later\n\nBuilders' built-in backends can be hard to move away from (Lovable Cloud, for example, can't change region once enabled and needs a manual export to leave). Export your data now and then, and keep a copy of the table definitions.",
  "url": "https://copypasteui.dev/r/recipes/builder.json",
  "prompt": "# Back office with Your AI builder's own backend\n\nSet up the back office for this site with this backend, following every step. The back-office screens are the CopyPasteUI \"admin\" components (admin-sign-in, admin-overview, admin-bookings …); each takes its data and save actions as props. Best for: People building in Lovable, Bolt, Replit or v0 who don't want another account. Cost: Included in the builder's plan, usually with a small monthly allowance.\n\n## The back-office data model\n\nEvery recipe stores the same data with the same names, so the back-office screens (category \"admin\") work with any backend. Money is stored in pence/cents as whole numbers. Times are stored in UTC.\n\n| Table | Fields | Used by |\n| --- | --- | --- |\n| `staff_members` | user_id (the auth user), email, name, role (`owner` \\| `manager` \\| `staff`), status (`active` \\| `invited`) | admin-staff, every access check |\n| `settings` | one row: name, phone, email, address, instagram, booking_link, notify_bookings, notify_enquiries, notify_reviews, daily_summary | admin-settings, the public header/footer/contact |\n| `bookings` | id, starts_at, name, party, phone, email, table_label, note, status (`confirmed` \\| `arrived` \\| `no-show` \\| `cancelled`), created_at | admin-bookings, admin-overview |\n| `orders` | id, number, customer_name, placed_at, pickup_at, items (list of {name, qty}), total_pence, paid, stage (`new` \\| `preparing` \\| `ready` \\| `collected`) | admin-orders |\n| `enquiries` | id, name, email, phone, subject, message, received_at, status (`new` \\| `replied` \\| `archived`) | admin-enquiries |\n| `menu_sections` | id, name, position | admin-menu-editor, the public menu |\n| `menu_items` | id, section_id, name, description, price_pence, tags (list), available, position | admin-menu-editor, the public menu |\n| `customers` | id, name, email, phone, visits, last_visit, spend_pence, notes, marketing_opt_in | admin-customers |\n| `reviews` | id, source, author, rating (1–5), text, posted_at, reply | admin-reviews |\n| `opening_hours` | day (0 = Monday … 6 = Sunday), open, opens, closes | admin-hours, the public footer/contact |\n| `closures` | id, starts_on, ends_on, note | admin-hours, the closed-notice banner |\n\n## Who may do what\n\nThis is the security contract. Implement it in the database's own rules, not only in the interface — hiding a button doesn't stop anyone.\n\n| Data | Public visitors | Staff | Manager | Owner |\n| --- | --- | --- | --- | --- |\n| menu_sections, menu_items, opening_hours, closures | read | read | read, write | read, write |\n| settings | read (public fields only) | read | read | read, write |\n| bookings | create only (from the booking form), never read | read, change status | read, write | read, write |\n| orders | create only (from checkout), never read | read, change stage | read, write | read, write |\n| enquiries | create only (from the contact form), never read | — | read, write | read, write |\n| customers, reviews | — | — | read, write | read, write |\n| staff_members | — | read own row | read | read, write |\n\nRules that apply to every backend:\n- Every `/admin` page checks the session **on the server** and sends signed-out people to `/admin/sign-in`.\n- Secret keys (service-role keys, admin SDK credentials, API secrets) live only in server code and environment variables, never in the browser bundle.\n- Public forms may only insert, with fields limited to what the form sends; they can never read other people's rows.\n- `/admin` is left out of the navigation and the sitemap, and disallowed in robots.txt.\n- The first owner account is created by hand once (instructions in each recipe); everyone else is invited from admin-staff.\n\n# Your AI builder's own backend: steps\n\n## How to use this recipe\n\nPaste it into your AI builder after adding the back-office screens. Builders can create tables and sign-in for you, but they don't always lock the data down unless asked — so ask explicitly, and check.\n\n1. **Turn on the built-in backend.**\n   - **Lovable:** enable Lovable Cloud (it runs on Supabase, so ask Lovable to use the SQL and policies from the Supabase recipe — `get_recipe` with slug `supabase` if your editor has the CopyPasteUI MCP).\n   - **Bolt:** use Bolt's built-in database and authentication (or connect Supabase).\n   - **Replit:** use Replit's built-in database and Replit Auth.\n   - **v0:** connect a database from the Vercel Marketplace (Supabase or Neon) and follow that recipe.\n2. **Create the tables** in the data model above, with exactly those names and fields.\n3. **Lock the data down** with the access table above. Say it in these words:\n   > Turn on row-level security (or the platform's equivalent) for every table. Public visitors may only read the menu, opening hours, closures and settings, and may only create bookings, orders and enquiries — never read them. Signed-in staff read bookings and orders and may change only their status. Managers and owners manage everything else; only the owner changes settings and staff.\n4. **Protect /admin.** Ask for every `/admin` page to check the signed-in user on the server and redirect to `/admin/sign-in` when signed out, and for `/admin` to be left out of the menu and sitemap.\n5. **Make the first owner.** Sign up once, then ask the builder to mark that account as `owner` in the staff table.\n\n## Check it before you publish\n\n- Open the site in a private window, go to `/admin` — you should land on the sign-in page.\n- Submit the contact form while signed out, then try to read enquiries without signing in (ask the builder \"can a signed-out visitor read the enquiries table?\"). The answer must be no.\n- Sign in as a staff account and check you can't open Settings or Staff.\n\n## Leaving later\n\nBuilders' built-in backends can be hard to move away from (Lovable Cloud, for example, can't change region once enabled and needs a manual export to leave). Export your data now and then, and keep a copy of the table definitions.\n\nDocs to check before you start, since providers change their APIs: Lovable Cloud (https://docs.lovable.dev/features/cloud); Lovable + Supabase (https://docs.lovable.dev/integrations/supabase).\n"
}