If an agency has proposed an Astro website, most of the risk sits in the parts of the proposal nobody reads twice: who edits it, who hosts it, who fixes it. These twelve questions cover that ground. Tick each one when you’ve had a straight answer, and take any unticked question into the scoping call.
The questions apply to any Astro build. We build ours on Lumos for Astro, which settles the design-system questions early, but the editing, hosting and support questions are the same whatever framework the agency uses.
Most of these belong before the contract, and the last three before the launch date
- ProposalQuestions 1, 2, 5, 10Editing model, sections, framework version, hosting owner and cost.
- Scoping callQuestions 3, 4, 7, 11Preview, rollback, custom parts, who updates what.
- BuildQuestion 6A section shown with short and long copy, on a phone.
- LaunchQuestions 8, 9, 12Forms tested, redirects checked, tracking live.
- Month 12Every answer, re-readThe site should still be easy to run without the agency in the room.
Editing
- Who publishes the next article, and can they do it without a developer?Astro sites can run on Markdown files in version control or connect to a CMS. If the answer involves a developer for every post, your blog stops the first month they’re busy. Good answer: a named editor and a live demonstration of them publishing a post from start to finish.
- Can the marketing team build a campaign page from existing sections?Landing pages are the most frequent request after launch. Good answer: a library of sections the team can add, reorder and remove, shown working before the build is signed off, with the limits stated. “Anything is possible” is not an answer.
- How do we preview a change before it goes live?Without a preview step, every edit is a production edit. Good answer: a preview link for each change, on its own URL, and a named approver. On an Astro site this is usually automatic with the hosting, so an agency that can’t show it hasn’t set it up.
- How do we undo a bad release?Something will go wrong at 5pm on a Friday. Good answer: rollback to the previous release in under five minutes, by someone on your side as well as theirs. Ask them to do it in front of you.
Design system
- What framework version does the build start from, and who reviews updates?Lumos for Astro is at version 0.0.3 and its components change between releases. Good answer: the starting version written into the scope, and framework updates reviewed as a diff before they’re applied to your site, never pulled in automatically.
- Can I see one section with short copy and one with long copy?A section that looks right with the demo headline and breaks with a real one is the most common design-system failure. Good answer: the same section shown both ways, on a phone, with a headline twice as long as the one in the design.
- Which parts are custom, and which come from the framework?Custom components cost more to build and more to maintain, and they’re the parts a future developer has to learn. Good answer: a list, with each custom component justified by a business need such as a pricing calculator or a CRM-connected form.
Connections
- Where does each form send its enquiries, and has a test one arrived?A form that posts to nowhere loses leads silently for months, and a static site has no server catching them by default. Good answer: every form named with its destination, and a test submission you received yourself, in your own inbox or CRM.
- If we’re replacing a site, what happens to the old URLs?Every old page that returns a 404 is a lost ranking and a broken link somewhere you don’t control. Good answer: a redirect map covering every indexed URL, checked against Search Console after launch, with the count of redirects in the handover.
Hosting and support
- Who owns the hosting account, and what does it cost per month?The account should be in your name with the agency given access, so the site survives a change of agency. Good answer: your account, their access, and the monthly figure in the proposal. For most static Astro sites on Cloudflare Pages that figure is zero, so a large hosting line deserves a question.
- Who applies security updates, and how often?An Astro site has dependencies that need updating, and a site nobody touches for a year is a site with known vulnerabilities in it. Good answer: a named person and a cadence, monthly or quarterly, written into the support agreement.
- What gets measured after launch?A site with no conversion tracking cannot tell you whether it works, and “traffic is up” is not a result. Good answer: the two or three actions that count as a lead, each tracked and reported monthly, with the first report date agreed before launch.
The accounts that should be in your name, whoever built the site
Set up the AI building workflow
If you are coming from Webflow, start by giving Claude Code or Codex the same information a new builder would need: the style guide, approved sections and publishing instructions.
Work through this setup with the person maintaining the site:
- Open the correct project. Keep the website in a business-owned code repository, such as GitHub. This stores the files and their change history.
- Add project instructions. Use
CLAUDE.mdfor Claude Code andAGENTS.mdfor Codex. Point both to the same guide for this website. - Provide the Lumos context. Include
LUMOS.md, the installed component files, brand tokens and one approved page. Name the section wrapper, spacing options and buttons to reuse. - Prepare the relevant skills. Write a section-building skill, a Cloudflare deployment skill and a maintenance skill. Each should state what to read, the steps to follow and how to check the result.
- Connect current documentation. Astro’s documentation MCP helps the agent look up framework details. Check any additional connection serves a specific job.
- Build one section through to a preview. Use real copy and images. Check it on desktop and mobile before using it as the example for later pages.
A skill is a repeatable procedure stored in a SKILL.md file. For example, the section-building skill can say: “Read LUMOS.md and an approved section. Reuse the existing components and spacing options. Build the section and show desktop and mobile previews.”
Official setup references: Claude project instructions, Claude skills, Codex instructions and skills, Lumos build guide, Astro AI setup.
Cloudflare setup checklist
This sequence is for a static Astro site on Cloudflare Pages. Pages builds the project into files and serves them on the web. A site generating pages for each visitor needs a compatible server setup; check the current Astro adapter guidance before choosing that route.
- Use business-owned accounts. Record who owns the domain, code repository and Cloudflare account, and who can publish.
- Connect the repository to Pages. Choose the production branch. Set the build command to
npm run buildand output folder todist, then confirm those match the project. - Save the environment settings. Use the Node version required by the installed project. Put any CMS or form secrets in the hosting settings and document their names and purpose.
- Check the preview. Open the generated URL and test navigation, images, mobile layouts and an actual form submission. Keep preview access appropriate for any unpublished material.
- Connect the domain and release. Follow the saved domain settings, check HTTPS and redirects, then verify the live pages and enquiry destination.
- Practise recovery. Restore a previous deployment and document the steps. CMS content and other stored data may need their own backups.
Give the deployment skill the project name, build settings, preview steps and recovery instructions. Save credentials outside the skill. Sources: Cloudflare’s Astro guide, preview deployments, custom domains and rollbacks.
Keeping changes manageable
Try a normal request: change the shared primary button label. Have the agent read the component guide, find the affected pages and prepare a preview. Check the label and link on a phone, publish through the agreed process and leave a short change note.
Agree who handles routine content, code updates and broken integrations. The next person should be able to run the site from its files and instructions. The article’s context and skills guide shows what to include.
Hosting choices
Astro is a framework. A project still needs a hosting service, and the choice depends on which pages are static and which need a server at request time. Deployment options, server rendering.
| Setup | Where it runs | What the team must own |
|---|---|---|
| Static marketing pages | A static hosting service such as Cloudflare Pages, Netlify or Vercel. | Domain and DNS, build access, publishing triggers, previews and recovery. |
| Dynamic routes | A compatible server or edge runtime, using the appropriate Astro adapter. | Runtime compatibility, secrets, logs, request limits, caching and access control. |
| CMS or commerce services | Connected services with their own accounts and data stores. | Content and product ownership, backups, service permissions, integration failures and recurring charges. |
For a small business site, agree who makes occasional edits and receives enquiries. For ecommerce, identify the system responsible for stock, checkout, tax and fulfilment. For an enterprise marketing site, document editor permissions, approval stages, localisation and the required support and data locations across services. Astro commerce options.
Request a complete cost list covering hosting, CMS seats, forms, AI tools, search, media and ongoing technical support. Our Astro and Webflow cost comparison includes current public plan prices and the other costs to budget. Keep the domain and production accounts in the business’s name. Record usage limits and who receives billing or service alerts.
A rehearsal for teams building their own site
Before relying on an AI-built site, have the people who will run it complete these tasks:
- Publish a real article using their normal account, including its image and search description.
- Assemble a campaign page from existing sections with short and long copy. Check desktop, mobile and keyboard use.
- Submit a form and confirm it arrives in the intended inbox or CRM, with tracking checked.
- Make a shared-component change in a preview, review the affected pages and restore the previous release.
- Give another maintainer the repository and written instructions. Have them build and preview it without the original chat history.
The open items show where the team needs an editing tool, clearer instructions or technical support. Keep those decisions with the original 12 answers.
What to do with the unticked ones
Keep the ticked list with the proposal. The unticked questions are the scope conversation, and an agency that answers them well in writing will usually run the project the same way. An agency that gets vague on hosting ownership or rollback is telling you how the support period will feel.
Two of the twelve are worth a hard line. If the editing demonstration (question 1) or the hosting ownership (question 10) can’t be settled before signing, don’t sign. Everything else can be worked out during the build.
Read about building Astro websites with Lumos, what Source by Webflow may change for this kind of site, and how we run website delivery.
