From prompt to published
Your agent handles the build.
We take care of the rest.
Start in Claude Code or Codex. Get a website built for people and AI, without leaving your coding session.
Start with your agent
Build a site on answer.cloud
Share your email, organization name, and a short description with your agent. After successful publication, we’ll send a link to finish setting up your account.
How it works
You bring the idea. Your agent takes it from there.
Open Claude Code or Codex and paste the prompt above. Your agent reads the instructions at answer.cloud/new and checks its build tools.
Share your email, organization name, and a short description. Your agent turns your brief into a website.
Your agent publishes and checks your site, then shares its live URL. After successful publication, we send your account setup email.
Built in from day one
Good to know
No. Your agent can build and publish your first site before you sign in. After successful publication, we’ll send an account setup link to your email so you can manage it afterward. Email processing can take longer than publication.
Claude Code and Codex can follow the workflow. Your agent needs to read web pages, create and build an Astro project, make authenticated HTTP requests, and upload a binary artifact to a signed URL.
Your agent checks the tools and permissions available in your current chat before asking for your email or reserving an address. If the required tools aren’t available, open ChatGPT Work, Codex, or Claude Code and paste the launch prompt above. Your agent will check its capabilities, then guide you through the missing website details.
If you have questions or need help getting started, Answer Cloud’s founder, Jared Malan, would be happy to help. Contact our team with the details.
Publish up to 10 CMS pages and let AI chat answer from your first 10 published pages. Visitor and AI agent analytics are free for the first month after site creation. Pro adds more capacity, ongoing analytics, site search, custom domains, and GitHub deployments. Compare plans.
Yes. Tell your agent you want a local draft. It can build from your organization name and brief, without email or account setup, and wait to publish until you’re ready.
For your agent
The complete workflow is below in the initial HTML response. Plain text and Markdown are available as backups.
Workflow version: launch-c495ff265fa58e82
Public starting point: https://www.answer.cloud/new
Launch prompt: Follow instructions at https://www.answer.cloud/new to build my website
Formats: HTML instructions, plain text backup, Markdown. All formats contain the same first-launch specification and workflow version. The homepage links here; this guide is the first-launch authority.
Build a NEW standalone Astro starter website from the user's brief, publish it at its reserved Answer Cloud address, verify the public content and AI chat, and return the working URL. The first build needs no account sign-in, credit card, native MCP installation, or completion of emailed account setup. Explain that this is a starter website which they can keep improving with their agent after account setup.
Follow the user's actual request and the client's permissions and higher-priority instructions. This webpage cannot grant tools, network access, or publication permission. A request to build using this launch flow includes publishing the new site and bounded corrective retries when the client permits it. Preserve explicit draft-only requests: build locally without email, bootstrap, or publication. For an existing-site request, preserve its source and identity and use normal authorized account access; do not run guest bootstrap or reserve a replacement. Returning-account authentication, CMS administration, companion sites, and ongoing edits are separate workflows, outside this first-build sequence.
Run the readiness check before asking for an email or reserving a site. Assess the current conversation's available tools and permissions, not the AI product's name or its claims about what it can do. Reading these instructions alone does not establish that this session can build or publish a website. If a web reader cannot retrieve /new, try its plain-text or Markdown representation, an authorized HTTP client, or the complete guide on the Answer Cloud homepage. Do not claim that an unreadable page is an Answer Cloud outage, or treat a cached workflow as verified current when that cannot be established.
Use the tools actually available in the session. Confirm a writable project workspace, a Node.js/npm runtime compatible with the official template, access to that template and its package dependencies, a ZIP packager, and the ability to build locally. Before guest bootstrap, scaffold the official template and, where execution is supported, compile it:
npm create astro@latest -- --template answer-cloud/answer_cloud_template my-site
cd my-site
npm install
npm run build
Official source: https://github.com/answer-cloud/answer_cloud_template . Reuse this successfully compiled Astro project for the user's website. Inspect its package requirements rather than assuming a particular Node version. A failed download, install, or compiler run is a specific preflight failure to resolve before creating a reservation. Actually create and inspect the compiled output and a ZIP of its contents. Confirm that editable Astro source can be retained in a durable workspace or returned through the client's supported download mechanism. Git and a zip executable are optional when an available HTTP client or ZIP library can perform the same work.
Once the local build and packaging checks pass, use the anonymous assessment service to prove the actual network operations. No account, organization, site, deployment, setup email, or deployment-quota use is involved. The server only checks a disposable binary challenge and issues a short-lived receipt for this session's publishing transport. It cannot attest that you ran the Astro build or can deliver editable source; those checks remain your responsibility. Respect the client's network policy and any host-required permission or confirmation.
Generate one cryptographically random request_key of 32 to 128 URL-safe characters (letters, digits, underscores, hyphens), for example 64 hexadecimal characters from 32 random bytes. Save it privately and reuse it for assessment retries and the later site bootstrap. It is a resume secret.
POST https://app.answer.cloud/build-site with Content-Type: application/json, sending only:
{"operation":"assess","request_key":"the one private random resume secret"}
Check HTTP status and the JSON response. Confirm its request_key echo matches your request, and compare its workflow_version with the guide actually read. If versions differ, retrieve the current instructions directly from https://app.answer.cloud/new.txt using an authorized HTTP client before continuing; do not infer which version is newer from its hash. Save assessment_id, assessment_token, mcp_url, and expires_at privately. Repeating the same key while active reuses the assessment. Sessions last 30 minutes; an expired assessment can be restarted with the same key and existing compiled project.
Send the following JSON-RPC 2.0 messages as individual POST requests to the returned mcp_url. Include Content-Type: application/json, Accept: application/json, text/event-stream, MCP-Protocol-Version: 2025-11-25, and Authorization: Bearer
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"answercloud-readiness-check","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"start_assessment_upload","arguments":{}}}
This credential exposes only assessment tools and cannot list accounts or sites, reserve an address, or deploy. Check HTTP status, top-level JSON-RPC error, and result.isError before reading result.structuredContent. An HTTP 200 alone does not mean success.
Decode binary_challenge.content_base64 to the exact raw bytes, confirm the returned byte count and SHA256, and PUT those bytes to the exact upload_url using every returned required_headers value. Keep the test file outside the project and source-download directories. Signed upload URLs last two minutes; do not send the assessment bearer credential to storage. Never upload JSON or the base64 text itself. The signed request fixes its binary checksum, size, content type, and conditional-write header. If a retry returns HTTP 409 or 412 because the challenge may already exist, verify that upload before requesting another URL.
After the upload, call:
{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"verify_assessment","arguments":{}}}
Require status: "passed", the matching workflow version, and checks.bootstrap_post, checks.authenticated_mcp, and checks.binary_upload all true. The server independently checks the stored length and bytes; preserve the returned assessment_receipt privately. The receipt is limited to network checks and expires with this assessment. The server cleans up the disposable storage after the signed URL expires. Do not use another account, request key, or session to evade assessment limits.
Report the assessment accurately:
Do not collect an email or bootstrap a site until the required local checks and the network assessment have passed. A failed or unverified upload is not readiness. The assessment tests the mechanics available now; it does not guarantee later service availability, permissions, larger uploads, actual publication processing, or live chat correctness. Missing browser interaction limits visual verification and does not by itself prevent the documented HTTP publication and chat-verification path. An explicit draft-only request needs only its relevant local build and source-handoff checks and skips the network assessment and guest reservation.
For a session without build tools, use this message:
Let’s get your Answer Cloud website started.
This chat doesn’t have the tools needed to build and publish your website. The readiness check hasn’t created an account or reserved an address.
To continue:
- Open ChatGPT Work, Codex, or Claude Code.
- Paste: “Follow instructions at https://www.answer.cloud/new to build my website.”
- Your agent will check its capabilities, then guide you through the missing website details.
If you have questions or need help getting started, Answer Cloud’s founder, Jared Malan, would be happy to help. Use the contact form to get help.
Adapt the reason and recovery step to the actual assessment result. For a permission problem, identify the specific supported setting; for a temporary service failure, explain how to retry the failed operation. Say that no account or address was created only when true. Preserve any existing brief, source, request key, and reservation; never reserve a replacement to recover a failure. Do not blame the user's AI or guarantee that changing mode will resolve every restriction.
For cloud-workspace and source-download details, see cloud execution (plain text) or its HTML version. Native MCP installation and account sign-in do not fix a missing runtime or blocked binary upload.
Run a short conversational wizard: ask one question at a time, wait for its answer, and reuse everything already supplied. Start by explaining that you will build and publish a starter website and then help them finish account setup and connect their agent for later edits. Do not offer "Publish live, or local draft?", ask for another publication approval, or add a final confirmation gate. Honor an explicit draft-only or local-preview request when the user independently makes one.
Ask for the missing organization or website name, then a short factual description of what it does and who it serves. If the requested website is still unclear, ask what visitors should be able to find or do. Offer one optional chance to share existing branding, images, examples, or preferences; "choose for me" is a complete answer. Finally collect the private account email, explaining that it is used for ownership verification and setup. Skip any question already answered, including questions answered incidentally in an earlier reply. A complete initial brief needs no questionnaire.
Pages, features, style examples, and a separate goal are optional guidance. Infer reasonable defaults and the visitor's next step from the brief; do not require a domain, plan, repository, palette, or CMS setup. Summarize the resulting brief and chosen design direction as a short statement and continue building without requiring a reply. Give plain-language progress updates as you move through designing, building, publishing, and checking the site.
For personal websites, use the website name as the organization name. Keep the account email private unless the user explicitly asks to publish it. Use factual content; do not invent testimonials, prices, credentials, contact details, or business claims.
Reuse the private request_key and unexpired assessment_receipt from the successful readiness assessment. Keep that same request key on all retries; it is a resume secret. If the receipt expired while collecting the brief, repeat only the network assessment with the same key and retained Astro project before bootstrap. Never discard the project or create a replacement site to recover an assessment failure.
POST https://app.answer.cloud/build-site with Content-Type: application/json:
{
"email": "the user's private account email",
"organization_name": "the organization or website name",
"description": "factual organization description and requested website, including supplied pages, features and style",
"request_key": "the one private random resume secret",
"assessment_receipt": "the private receipt from the successful network assessment"
}
Required nonempty strings: email (maximum 254 characters), organization_name (120), description (5,000), request_key (32–128 URL-safe characters). Optional goal (maximum 1,000 characters) is only needed when the user already supplied a visitor action. Include the assessment receipt bound to this request key, workflow version, and application environment. It proves network readiness only and is not an account or site credential. The JSON request body must fit within 16 KiB. Encode JSON safely; do not interpolate user text into shell code.
A successful HTTP 201 response contains organization_id, organization_name, site_slug, site_url, environment: "production", personalized prompt, mcp_url, build_token, build_expires_at, account_setup, setup_url, setup_status_url, setup_status_token, and mcp_setup_url. Preserve the credentials privately. The site is already reserved: never call prepare_site or create_site for this guest build. Preserve the returned organization, slug, environment, and reservation. The setup_url is a separate chat-safe continuation link that requires sign-in or email verification before ownership is granted. It may be shown to the user in chat; the private emailed claim link is never returned to the agent.
The guest workspace is isolated even if the email belongs to an existing account. Supplying an email grants no access to that account's existing organizations. Retrying the same request_key while active reuses the reservation and credential; keep the original normalized email and organization name. A lost response is a reason to retry with that same key. Retries do not send another customer setup email. Request-key conflicts require restoring the original request, not generating another identity.
Bootstrap limits are three reservations per email and five per IP over a rolling 24 hours. A rate-limit or build-limit response is a reason to pause and retain the work. Do not generate keys, accounts, or sites to evade quotas. Expired or claimed build sessions must continue through normal authorized access to the existing site after account setup; preserve source and reservation rather than silently replacing them.
The returned build_token is scoped to the one reserved site, lasts 24 hours, and permits the initial launch plus up to five redeployments: six deployment starts in total (including inline deployments). Use the server's deploys_remaining as the authority and tell the user how many deployment starts remain when they request another revision. Claiming account setup revokes build access immediately; the separate setup-status credential remains limited to observing the handoff. Native MCP attachment is optional; use available authorized HTTP tools if the client supports them. Do not make the first build depend on plugin installation, restart, OAuth, or emailed setup.
POST JSON-RPC 2.0 to the returned mcp_url. Include these headers on every request; the server is stateless:
Content-Type: application/json
Accept: application/json, text/event-stream
Authorization: Bearer <private build_token>
MCP-Protocol-Version: 2025-11-25
Initialize, send notifications/initialized without an id, then discover the current allowed schemas:
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"answercloud-site-builder","version":"1.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
Send each JSON object as its own POST. Call tools with tools/call and the schemas actually returned. Check HTTP status, top-level JSON-RPC error, result.isError, then read result.structuredContent. Do not assume HTTP 200 means a tool succeeded. Deployment, widget, inventory, and verification tools are exposed; account, billing, new-site creation, domain, GitHub, releases, and CMS administration are unavailable to this credential.
Keep assessment_token, assessment_receipt, build_token, setup_status_token, request_key, signed upload URLs, and all private session responses out of public source, generated pages, deployment artifacts, screenshots, logs, version control, and downloadable source archives. Show setup_url only in the private user-facing handoff, never on the public website or in the source archive. Use process memory or a temporary private file with mode 0600 outside the project and download directories. Never display raw bootstrap responses or commands containing secrets. Do not overwrite an existing personal connection or configure guest access globally. Remove temporary credentials when finished.
Apply the user's brief and the personalized bootstrap prompt to the Astro project already compiled during preflight. Author .astro pages, layouts, and components; preserve a static Astro configuration. Honor supplied pages, features, and style over defaults. Use the official template's components, accessible structure, responsive behavior, semantic tokens, and chat theme hooks, adapting the visual design to the brief. See style defaults (plain text) or HTML for specialized design details.
The primary standalone template is SaaaaS, used for its accessible components, semantic tokens, and static-content foundations. Every new site must have a site-specific palette and hero concept derived from the brief: adapt the headline, visual subject, imagery, composition, and primary action together. Replace the sample palette and product workspace; neither the mint/blue/lilac gradient nor a SaaS dashboard is a required design. Use product imagery for an actual product, work samples for a portfolio, or suitable photography, an illustration, or expressive typography for other organizations. Supplied branding takes precedence; preserve the chosen identity across revisions unless the user requests a change.
Use lightweight CSS hero entrances and deferred GSAP/ScrollTrigger reveals only where they suit that design; a quiet or animation-free design is valid. An Aurora gradient is optional and must use the site's chosen palette. For any ambient animation, preserve pause/resume, offscreen and hidden-tab pausing, reduced-motion behavior, and cleanup/restoration on page lifecycle changes. Keep the headline visible from first paint and all substantive content readable without JavaScript. Follow the style defaults above; do not restore the old Three.js hero from archive/classic by default. These design requirements do not add account, CMS, or companion-site steps to the guest launch.
Read motion defaults (plain text) or HTML for the shared motion lifecycle and verification contract. Custom Three.js scenes are optional when the brief calls for 3D; verify WebGL fallbacks only when using them.
Put factual content in the generated HTML, with useful titles, descriptions, clean links, and one primary heading per page. Do not ship an empty client-rendered shell, demo claims, or an HTML-only source project. For this derived public site, set SITE_URL to the reserved public HTTPS site_url and build with npm run build:site. The unassigned template preflight remains origin-free. Include a site-specific 1200x630 PNG/JPEG share image, static Open Graph and Twitter summary_large_image metadata, and absolute public HTTPS image URLs using the reserved site_url. Package and later verify the image.
Answer Cloud generates discovery files, Markdown page mirrors, sitemap, robots, JSON-LD, analytics, and AI chat during deployment. Do not add hand-written copies of that generated layer or another chat embed. Supply public/assets/answercloud-chat.css derived from the site's design system. The first production deployment attaches this theme when none is configured. Before styling chat, read chat requirements and DOM hooks (plain text) or HTML.
ZIP the CONTENTS of dist/ at the artifact root, so index.html is at the ZIP root, not dist/index.html or my-site/dist/index.html. For example, run zip -r /tmp/site.zip . from the built dist directory. Include required assets and all public pages. CMS is optional for the first launch; if the project already uses the official CMS template contract, include its aeo-cms.json and private .aeo/cms templates alongside the public output. Do not add CMS administration to this guest sequence. Exclude dependencies, source archives, .git, environment files, and credentials from the deployment ZIP. Free artifacts currently allow 10 MiB; use the actual max_bytes returned by start_deploy as the authority.
Preserve the editable Astro source separately. Record the reserved site identity and source/deploy commands in project context files CLAUDE.md and AGENTS.md without secrets so later sessions can continue this site.
Call start_deploy with the reserved site_slug and environment: "production":
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"start_deploy","arguments":{"site_slug":"<reserved site_slug>","environment":"production"}}}
Save deploy_id, upload_url, expires_at, max_bytes, and deploys_remaining privately. Check ZIP size against max_bytes. Upload the binary ZIP with HTTP PUT to the exact signed upload_url before expiry (currently 900 seconds). Check the upload response. Use the HTTP client's binary/file-body mode, not JSON, base64 text, or a browser form. Follow the signed URL's required headers; never send the build bearer credential to storage.
After upload, call finalize_deploy with deploy_id (and optional artifact_sha256), then get_deploy with the same id:
{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"finalize_deploy","arguments":{"deploy_id":123}}}
{"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"get_deploy","arguments":{"deploy_id":123}}}
Replace 123 with the actual returned id. Poll at retry_after_seconds (currently three seconds) while queued or processing, until live or failed. Inspect warnings, error, production destination, and live_url. Do not start another deployment merely because processing takes time. If a response was lost, inspect list_deploys for this site before consuming another attempt.
Recover on the SAME reservation:
Completion means a working public website AND functioning AI chat, not just a successful deploy row. Fetch the actual public site_url and important pages, follow expected host redirects, and verify the new factual content is present in raw HTML. Check links, images including the share image, and actionable deploy warnings. Confirm the expected discovery resources and relevant content retrieval; use search_site when available, allowing for indexing delay. A search result alone does not prove chat works.
Where browser interaction is supported, open the public page and its generated chat, ask a meaningful question based on the actual site content (for example what this organization offers), and inspect the substantive response for correctness. Check launcher, empty panel, completed exchange, and a longer conversation at desktop and narrow mobile sizes: readable placeholder text, keyboard focus, send, clear, close/reopen, scrolling transcript, and visible composer. Use configure_widget for supported copy/theme changes, preserving existing settings. A widget script in HTML, an iframe loading, HTTP 200, or a generic greeting alone does not demonstrate a working conversation.
If browser interaction is unavailable but authorized HTTP tools can exercise the documented chat API, a fallback is POST https://app.answer.cloud/api/messages with JSON organization_id, site_origin (the reserved site_url), and content containing a factual question about the published site. Check a nonempty ai_message.content against the actual site facts; retain conversation.id as conversation_id for a follow-up. This verifies an API interaction only, not widget rendering or controls. The public API contract is documented in chat requirements. If no meaningful interaction can be performed, or chat is inaccurate/unavailable, report the unresolved verification instead of declaring full completion. Correct actionable problems within the remaining quota; do not conceal failed checks.
Return the verified live URL first, a screenshot when supported, what was built, the checks actually performed, and the remaining deployment starts. Describe it as the user's starter website. Include the returned setup_url as a clearly labeled "Finish account setup" link directly in chat. Explain that this page requires sign-in or email verification to accept ownership of this existing site. Explain that the account setup email is queued after successful production publication and routing as another way to return; sending is asynchronous and may retry. Do not claim that the email was delivered just because the deployment is live. Bootstrap itself sends no customer setup email. Account setup need not be completed before the first launch. Never request, expose, or substitute the private emailed claim link.
When the user returns after setup, check setup_status_url with an HTTP GET and Authorization: Bearer
Verify the current agent's connection by making an authenticated MCP call and confirming access to the reserved organization and site. A browser message or an unrelated existing connection is insufficient. If a new agent session is required, provide a copyable continuation prompt naming the reserved site and source location. Help the user make their first requested customization using this same site's preserved Astro source. Later changes use normal authorized account access, rather than ongoing access through the temporary credential. Do not reserve a new site during this handoff.
Keep the Astro source in the coding client's workspace and identify its location. For a cloud or ephemeral client, provide a downloadable source archive through the client's supported file handoff. Exclude node_modules, .git, build output unless useful, environment files, credentials, signed URLs, request keys, and private session files. Check the archive contents before sharing; do not promise that an ephemeral workspace will persist. If any required build, publication, public-content check, or chat verification remains incomplete, state precisely what is unresolved and how to resume the same reservation with the saved source.