ChatGPT Sites Hits HN's Front Page: Prompt-to-Website — Toy or Productivity?

On October 3, 2026, Hacker News pushed "Sites in ChatGPT" near the top of the front page — roughly 209 points and 218 comments. This wasn't a launch: ChatGPT Sites had already been in public beta for months. What HN really did was force the question product pages never answer: is this a toy, a prototype host, or a productivity tool?

For vibe coders, that question matters more than any feature announcement. Because Sites represents an emerging delivery shape: prompt straight to a shareable URL. Understanding its boundaries means understanding the publishing options for your next batch of vibe projects.

What Sites is: align on product facts first

Per OpenAI's developer docs, Sites lets ChatGPT create, host, refine, and share websites, web apps, and games without a separate deployment workflow. Mention website or @Sites in a prompt, or start from a compatible local project — review the preview, iterate, set the audience, share the link. Entry points: More → Sites in the ChatGPT web app, or chatgpt.com/sites.

Publishing has two stages, and the docs insist on them: first Save a version (a deployable candidate), then Deploy a version (publish it). The key detail: every deployed URL is a production deployment — the product gives you no separate staging hostname. Want review-before-ship? The discipline lives in the save step. That's the official answer to half the HN confusion.

Storage comes in two flavors: D1 (relational, 10 GB per site) for records, scores, and progress; R2 (object storage, no fixed limit) for uploaded images, audio, and documents. Local projects record the linkage in .openai/hosting.json. Public sites can offer optional "Sign in with ChatGPT," which forwards the user's email to your backend via request headers — but OpenAI is blunt: authorization decisions must live in server-side code, and compliance liability is yours. The platform doesn't absorb it for you.

Debate 1: hour-scale prototypes are the sweet spot

The top comments were remarkably aligned: Sites' underrated scenario is "playable today" hour-scale apps — a 3D maze game spun up after a concert, a music-festival schedule built because the official site was terrible, a campus food guide for an event. What these share isn't "being good" but that the friction from idea to shareable link dropped below the friction of not building at all.

That's vibe coding's main victory this year: the win was never "replacing agencies" but making the cost of a shareable link lower than the cost of silence. Sites just pushes that curve one step further.

Debate 2: prototype vs. production — the real fork

The fiercest argument was "can Sites go to production?" Both sides were right, because they were arguing different questions. On URL semantics, deployed means live; but fit is a different matter: unsupported frameworks, no raw TCP, beta usage limits (hitting a plan cap can block new sites or throttle high-traffic public ones), no data residency — all of which say: when the blast radius of downtime or data-locality requirements is unacceptable, don't use Sites.

A practical mental model:

• Use Sites when: you need a shareable URL today; collaborators iterate with you inside ChatGPT/Codex; D1/R2 plus sign-in covers the app; the audience is invited, workspace-based, or low-stakes public.
• Don't use Sites when: you need data residency or regulated data; you need unsupported runtimes or raw TCP; you process payments or PHI; you can't accept a .chatgpt.site domain or OpenAI hosting risk.

Debate 3: export vs. custom domain — two different exits

One commenter stared at *.chatgpt.site and asked: will these die someday, and can I export to my own domain? The thread produced two answers, both true in different ways: custom domain (documented: point your own DNS at the hosted site; visitors stop seeing the chatgpt.site suffix, but the runtime stays OpenAI's) and export/self-host (user-reported: some builders download the project and hand it to another agent or host it themselves — but that's not the same as the custom-domain setting, and OpenAI hasn't promised "one-click portable export" as a first-class product commitment).

The practical lesson: plan your exit before you accumulate users. Want branding? Use a custom domain (note: not available for Enterprise workspaces at launch). Playing the long game? Treat Sites as the mockup stage and move the code when it graduates. Don't assume "DNS pointed over" equals "source portable."

Debate 4: the official showcase gets roasted — "hosted polish isn't automatic"

HN spared nothing, including OpenAI's own showcase. The showcase site Tidal House was called out for unreadable text on images; Below the Surface was recognized as AI slop "on first contact." Even prompts written by OpenAI staff need a human pass over contrast, copy, and typography.

But that's precisely the most useful conclusion: hosted polish isn't automatic. The counter-example is the music-album site explainx.ai covered earlier — one concrete real need plus repeated iteration beats a "cinematic landing page" prompt nobody edits. Vibe coders have known this all along: prompts set the floor; human iteration sets the ceiling.

Sites vs. Claude Artifacts: one sentence to tell them apart

The thread kept asking whether Sites is "Artifacts with a URL." By product shape: Sites is persistent hosted output — a site list, save/deploy, analytics, D1/R2, sign-in, custom domains — aimed at "an app coworkers can open tomorrow"; Artifacts is the temporary canvas inside a conversation — great for explaining and iterating, weak at "a durable shared app with storage and audience controls."

If the deliverable is "a link someone opens tomorrow," Sites is the closer match. If it's "a one-off interactive explanation inside a thread," Artifacts still wins on friction. Neither replaces a full production frontend when you need CI, multi-region, or compliance controls you own.

My verdict for vibe coders: Sites is a "publish button," not a new category

Zoom out and Sites belongs to a bigger picture: it's the same loop as the Codex workflow — local repo, review pane, save-then-deploy — with Sites as the "publish button" on that loop, not a different product category. Once you see that, the choice is clear.

My three verdicts. First, treat Sites as the "first publish slot" for vibe projects. During idea validation, the lowest-friction publish is the best publish; talk about migrating when users and data arrive. Second, attach a custom domain on day one (if you own one). chatgpt.site links are fine for throwaway shares, not for printing anywhere. Third, don't put anything you can't afford to lose on it: payments, health data, under-13 user data — OpenAI's Help Center has an explicit ban list, and "I didn't know" won't save you.

Those 218 HN comments are essentially the first wave of serious users paying tuition for everyone: in an era when a prompt can publish, what's scarce is no longer "building it" but "knowing what belongs up there and what doesn't." Sites reduced publishing friction to zero — and judgment is the only moat left once friction disappears.

Hands-on: four copy-paste prompt patterns

Principles aren't enough; the thread distilled a few doc-backed patterns you can use directly:

• Internal tool + identity: "Build a project request dashboard for my ops team. People can submit requests, assign owners, update status, and filter the list. Require workspace sign-in and keep request data between visits. Use @Sites."
• Public site + optional sign-in: "Add Sign in with ChatGPT to this public site. Keep it usable signed out. Show Sign in / Sign out actions; after sign-in greet with full name or email. Keep authorization decisions in server-side code."
• Storage: "Add player scores and avatar uploads. Persist scores in D1 and avatars in R2 between visits."
• Deploy discipline: "Save a version of this site without deploying. Show me the saved version details, then wait for my approval before deploying." — the official answer to "no staging": put the discipline in the save step.

Note the restraint in the second pattern: public sites stay "usable signed out," with sign-in as added value (saved progress, personalization). Vibe sites that force login upfront die fastest.

The honest limitations list (don't learn these in prod)

• Beta limits: hitting a plan cap can block new sites, added storage, or keeping a high-usage site public; editing existing sites usually still works.
• Runtime shape: HTTP/HTTPS/WebSockets yes, raw TCP no; many frameworks and background patterns unsupported. Check the docs' runtime notes before building.
• No residency: site code, D1/R2 data, artifacts, logs — neither data nor inference residency is supported at launch. This is a hard red line, not a "coming later."
• Versions and collaboration: the two-stage save/deploy, URL renames, co-editing, and plugin capabilities are all expanding fast — this is "an experiment that hasn't been killed," not "a lifetime contract." Design important projects as "movable at any time."

Put this list next to the mental model above and Sites' position is complete: it's the shortest bridge between "it runs" and "someone uses it" for vibe projects. The bridge has a load limit — don't drive a truck over it; but for validating ideas, it's the fastest road in town.

Finally: publishing is becoming part of the prompt

What deserves attention about Sites isn't the feature list but a trend: publishing is becoming part of the prompt. The old workflow was "write code → build → deploy → share" — four stages, four tools. Sites compresses it into "one sentence → link." Vercel made deploying a git push; Sites wants to make it a sentence.

For the vibe ecosystem this means: project lifecycles get shorter and more numerous, and "building it" stops being the moat. The moat moves to two things: judgment — what's worth building and what belongs up there; and operations — once people use it, how you iterate and retain. Sites solves the first kilometer; the remaining ninety-nine are still yours to walk.

So back to HN's question: toy or productivity? The answer is — it's the productivity of toys, and the toy of productivity. Those who use it to validate ideas get productivity; those who bet the farm on it get a toy. The people who learned to tell the difference already paid their tuition in the HN thread of October 2026 — you can just copy their homework.