astro development

Astro sites your team changes by asking.

I build marketing sites in Astro with Sanity for the editors. After launch, a change starts as a request and ends as a preview you approve. The same person designs it, builds it and ships the hundredth edit.

What a change looks like after launch.

A sample site with invented data. Pick a request: a fix, a new section, or a new page. On a real site each one arrives as a preview, and nothing goes live until someone approves it.

The same kind of request from your side, in a chat channel. This conversation is a sample too.

#website Everbase agent

You 10:02

Can you add a pricing FAQ our editors can change in Sanity?

Everbase agent 10:02

5 steps done
  • Read the content model and the pricing page
  • Added an FAQ type to the Sanity schema
  • Built the section from existing components
  • Ran the build, link and accessibility checks
  • Opened a pull request with a preview

Ready for your review: a pricing FAQ with its Sanity schema. The preview is up.

Pricing FAQ /pricing · Preview
  1. Review
  2. Merged
  3. Live

Message #website

How a build runs.

Five stages, in this order. Each one ends with something you can open and check, so you know where the project stands without asking.

  1. Inventory and scope

    Every page, form, integration and person who edits the site, written down before anything is designed. The stack is Astro, with Sanity, on Cloudflare or Vercel.

    • URL and template list
    • Who edits what
    • Integration list
    • Fixed scope

    4 in hand so far

  2. Content model

    The pages become document types and fields in Sanity: what repeats, what references what, and which fields search engines read.

    • Sanity schema
    • Studio on your domain
    • SEO fields per page

    7 in hand so far

  3. Design system in code

    Color, type and spacing as tokens, then the sections built from them. New pages are assembled from these parts, so they match the old ones without anyone checking.

    • Tokens
    • Section components
    • A page listing every part

    10 in hand so far

  4. Pages, forms and preview

    Templates wired to Sanity, forms posting to wherever leads actually live, analytics behind consent, and a preview of every draft before it publishes.

    • Page templates
    • Working forms
    • Draft preview
    • Rebuild on publish

    14 in hand so far

  5. Launch and handover

    Redirects, sitemap and a speed check, then the domain moves early in the week so problems surface while I am watching.

    • Redirect file
    • Sitemap
    • Handover doc
    • Repository in your account

    18 things handed over, all yours

The same build on a calendar: what you do, what I do, and when.

Kickoff to launch Sample plan, 4–6 weeks
Week 1Week 2Week 3Week 4Week 5
You What I need from you
Plan Audit and content model
Build Astro or Next.js, with Sanity
Launch Content, QA and cutover
  1. You

    • Week 1 Kickoff One call to agree the scope, the dates and who signs off.
    • Week 1 Access Your current site, your domain and the accounts your new site will live in.
    • Week 1 Plan approved You approve the page plan and the redirect policy before any build starts.
    • Week 4 Preview review You read the real pages on a private preview and send your notes.
    • Week 5 Launch The site goes live in accounts your company owns.
  2. Plan

    • Week 1 Audit I list every URL, form, script and CMS field on your current site.
    • Week 1 Content model Your pages become structured Sanity types your editors can use.
  3. Build

    • Weeks 2 to 4 Pages and components I rebuild each template and compare it with the live page, side by side.
  4. Launch

    • Weeks 3 to 4 Content and redirects Your content moves to Sanity, and every old URL gets its redirect.
    • Weeks 4 to 5 QA and launch Speed, links, forms and analytics get checked before the domain moves.
Point at or tap any item to see what happens then.

What you end up with.

  • Sanity for the people who write

    Marketing edits pages and posts in Sanity Studio, served from your own domain. Layout stays in code, so a busy week of publishing cannot break the design.

  • HTML first

    Pages are rendered ahead of time. JavaScript loads only for the parts that move or respond, like a calculator or a demo, not for every heading and paragraph.

  • Search and AI readers built in

    Titles, canonicals, the sitemap, structured data and an llms.txt are generated from the content, so a new page cannot ship without them.

  • A repository you own

    The site is plain files in your GitHub account, hosted in your Cloudflare or Vercel account. If you stop working with me, nothing has to be exported.

  • Changes by asking

    After launch a request arrives through the Console or the channel agreed at kickoff, and comes back as a preview. Nothing goes live until you approve it.

  • Parts that agents can use

    Documented components and tokens mean a coding agent builds a new page from the same parts I would, and the change still arrives for review.

Is Astro the right call?

Better to hear it before the build than after it.

A fit when

  • Most pages are the same for every visitor: product pages, pricing, posts, guides.
  • Marketing publishes every week and should not wait on a developer to do it.
  • Search traffic and page speed matter to how the business finds leads.
  • You want the code in your own repository, not inside a builder.

Not a fit when

  • Screens behind a login, dashboards, or components shared with a React product. That is a job for Next.js. Next.js development
  • A store, memberships or bookings at the core of the site. The platform already running them is usually the right place to stay. Stay or move
  • Brand identity. I build from a brand you have; I do not create one.
  • A team that lays out new pages visually every week. A visual builder suits that better. Stay or move

The stack.

  1. Changes

    Where your team asks for something

    • The Console
    • Claude
    • Slack
  2. Site

    What visitors load

    • Astro
    • TypeScript
    • Tailwind
  3. Content

    Where editors write and publish

    • Sanity
  4. Hosting

    Where it runs, in your accounts

    • Cloudflare
    • Vercel
    • GitHub

Questions about building in Astro.

Why Astro for a marketing site?

Most marketing pages are the same for every visitor, so they can be built once and served as HTML. Astro does that by default and adds JavaScript only to the components that need it, which keeps pages light without anyone having to fight the framework.

Should my site be Astro or Next.js?

Astro if every visitor sees the same pages. Next.js if the site has logins, reads live product data or shares React components with your app. I build both on one price list, and the first call usually settles which.

Can marketing edit it without a developer?

Yes, in Sanity. Editors change copy, images, posts and page sections there, and publishing rebuilds the site. What they cannot do is invent a new layout, which is the point: the design system holds.

How long until a published change is live?

On a static build, publishing in Sanity triggers a rebuild, which usually takes a minute or two. Pages that genuinely need to change instantly can be rendered on request instead; that gets decided page by page during scoping.

What does it cost?

A move from another platform is fixed price from $5,000, quoted once after the inventory. A new build is scoped the same way. Ongoing work afterwards is $3,500 a month with no minimum term. The cost page breaks the bands down.

Who does the work?

I do, all of it: scope, content model, design system, build, launch and the changes after. There is no handoff to a junior and no second team. The trade is capacity: there is no second team to absorb a rush, so scope and cost are agreed in writing before work starts. More on that.

Where is it hosted and what does that cost?

On Cloudflare or Vercel, in your account. On Cloudflare, a mostly static marketing site often fits in the free tier. Sanity has its own plans, which depend on your team size and usage, and I check them against your editors during scoping.

What if we outgrow Astro?

Then the content is already structured in Sanity and the site is a normal repository, so a new front end can read the same content. Nothing is locked inside a builder.

Next step

Have a site that should be Astro?

Send your site

I can scope a migration. Send a brief and I will reply by email with next steps.