ChatGPT Sites Tutorial: Use Cases, Backend & Prompts

Since July 9, 2026, paid ChatGPT users can build and host real web apps without leaving ChatGPT. You describe the app, ChatGPT writes the frontend and the backend, hosts both, and hands you a live URL. This guide focuses on what to build, how the backend works, and exactly how to talk to ChatGPT to get a usable tool - using nothing but the Sites feature and the ChatGPT desktop app.

The parts you get

Every Site has up to three layers, and you choose which ones your app needs:

• Frontend - the pages people see and click.
• Backend with a database (D1) - a real relational database that stores records permanently. This is what makes forms, trackers, and dashboards possible: data survives refreshes and is shared between all visitors.
• File storage (R2) - for uploads like images or documents.
• Sign in with ChatGPT - visitors identify with their ChatGPT account, so your app can know who submitted what, limit actions to one per person, or show each user only their own data.

You never configure any of this yourself. You ask for it in plain language, and ChatGPT generates the code for all layers. The one thing you must do is say clearly what needs to be stored - if you don't mention persistence, you may get a page that forgets everything on refresh.

The magic sentence that triggers backend code generation is some version of:

"Data must persist across refreshes and be shared between all visitors. Use a database."

What's genuinely worth building

Think "small internal tools that remove friction from your week":

• A personal or team dashboard - one page that shows your projects, statuses, due dates, and overdue items in red.
• An email-triage board - paste emails in, and the app files each one as reply today / delegate / read later / archive, with a persistent list per bucket. (Sites cannot connect to your inbox - the pasting is the input.)
• A submission form - collect requests, feedback, sign-ups, or bug reports from others at a URL.
• A tracker - habits, expenses to reimburse, job applications, anything with rows and statuses.
• An internal portal - links, how-tos, and FAQs for a small team, editable by you only.
• A voting or ranking tool - one vote per signed-in person, results stored centrally. An early tester shipped exactly this, with the backend included, in about 23 minutes.

Not possible, so don't start there: payments and e-commerce, connecting to external databases or private APIs, background jobs, anything with health or card data.

How to talk to ChatGPT before building - the interview prompt

The biggest quality lever is not the build prompt - it's making ChatGPT interview you first. Open the desktop app, mention @Sites, and start with:

Prompt 1 - the interview: "I want to build a small web app: [one sentence - e.g. 'a place where my family submits dinner ideas and votes on them']. Before you build anything, interview me. Ask me one question at a time about: who will use it, what actions each person can take, what data must be stored, who may see the data, and what the main screen should show. When you have enough, show me the plan - pages, data fields, and permissions - and wait for my approval."

This turns vague ideas into a concrete spec, and the spec becomes the build order:

Prompt 2 - the build: "Build it as planned. Private backend: store all records in a database, shared across visitors, persistent across refreshes. Require Sign in with ChatGPT for submitting. Generate a reviewable version first - do not publish anything yet."

Tutorial: a submission form with a private backend

This is the pattern almost every useful Site reduces to - a public form in front, a private data view behind it.

Prompt: "Build a submission form for [feature requests]. Fields: name (auto-filled from ChatGPT sign-in), title, description, priority (low/normal/urgent). On submit, save the record to the database with a timestamp and show a thank-you message. Add a separate /admin page that lists all submissions in a table, newest first, with filters by priority - and make the admin page visible only to me, not to other visitors. Reviewable version first, don't publish."

Where does the submission data live, and where do you find it? It's stored in the Site's built-in database (D1). You read it in two ways, both inside the product:

1. The private admin page you just asked for - this is the standard pattern. The form is public; the table of results is restricted to you. Ask for CSV export on that page if you want the data out.
2. Ask in the chat - in the same Sites conversation you can simply ask, "Show me the submissions received so far," and iterate on how they're displayed.

The dashboard and the email triage, in one prompt each

Dashboard: "Build a personal dashboard. Sections: Projects (name, status, due date), Today (tasks due today), and Waiting On (things I'm waiting for from others, with the person's name and days elapsed). All data stored in the database, editable inline by me only. Overdue items in red. Access: private, just me."

Email triage: "Build an email triage board. I paste an email's sender, subject, and text into an intake box. Each email becomes a card I can drag between four columns: Reply Today, Delegate, Read Later, Done. Cards persist in the database. Show a counter per column and let me archive a whole column at once. Access: private."

Refine in plain numbered requests - "1) sort Reply Today by oldest first, 2) add a search box, 3) let me edit a card after saving" - and keep everything else untouched.

How it goes live online

Publishing is a deliberate two-step, and it matters because there is no staging - every deployed URL is production:

1. Save a version. This creates a snapshot you can review without exposing anything.
2. Deploy, then pick the audience: private (you), selected people, your workspace, or public - public means anyone on the internet with the link, no ChatGPT account needed to view.

Your app is instantly live at yourname.openai.chatgpt.site, with a custom domain available where supported. Built-in analytics show unique visitors and page views. Visitors can use the site - submit, vote, browse - but never edit it; editing happens only in your chat.

Start with the narrowest audience, click through every flow yourself, then widen. Hosting is included with your paid plan (Free and Go excluded; EEA, Switzerland, and UK not yet supported) - usage counts against your plan's allowance the way Codex does.

The habit that makes this work

One sentence to remember: interview first, build second, publish last. Let ChatGPT ask the questions, insist on a database whenever data must survive, put a private admin page behind every public form - and you'll go from idea to a live, useful tool in a single sitting.