Astro web development: fast websites your team actually owns.
Astro web development from information architecture through to deployment and handover, for new builds and relaunches. You end up owning the site, the repository and the content model.
Static by default
Astro renders on the server and ships prerendered HTML. Client-side JavaScript is added only where interaction needs it.
Content as a data model
Content collections with a Zod schema: validated, typed and queryable through a proper API.
Everything in your accounts
Repository, hosting account, domain and CMS credentials all carry your name.
Our own products, live in the browser.
Screenshots from Mini Marvin, our own progressive web app running in the browser.
Swipe baby names instead of scrolling
Mini Marvin is our progressive web app for finding baby names: swipe through 10,000+ first names right in the browser, no app store needed.


What an Astro website build actually produces.
-
Information architecture before the first pixel
We first settle which page types exist and how the URL structure looks. Those become routes and layouts in Astro.
More on this
Changing that structure later means changing redirects, and the menu entries are the smaller part. In a relaunch the redirect list is therefore written here, line by line, old URL to new.
-
Content collections as the content model
Anything that recurs in a structure becomes a content collection with a Zod schema. Every entry is validated at build time and queried through getCollection().
More on this
A typo in the frontmatter then breaks the build rather than the live site. Whether a headless CMS joins in or Markdown in the repository is enough gets settled before the build. The options are on CMS for Astro.
-
Islands only where interaction is needed
By default Astro removes all client-side JavaScript from components. The configurator gets it back, the paragraph above it does not.
More on this
client:load for anything that has to respond immediately, client:idle for the uncritical parts, client:visible for everything below the first screen. Alongside that we agree a performance budget for images, fonts and third-party scripts.
-
Images that keep the layout still
The built-in image components set alt, loading and decoding and derive the dimensions, so cumulative layout shift never arises.
More on this
Picture produces several formats and sizes with a fallback. Images in the public directory bypass the processing entirely, and remote images have to be allowed in the configuration. We decide what runs through the pipeline.
-
The deployment target belongs in the plan
Static is the default. As soon as a route has to render on demand, for form handling or personalised areas, the target runtime needs an adapter.
More on this
First-party adapters in the @astrojs scope exist for Node, Vercel and Cloudflare. Which one it becomes is decided by your hosting. Forms, search, multiple languages and further integrations are planned in the same step.
Having an Astro website built?
Three sentences will do: new build or relaunch, rough page count, who maintains the content. You get an assessment.
Astro, Webflow or a custom web app?
We build all three. This matrix is the one we use in the first call.
| What you are building | Astro | Webflow | Custom web app |
|---|---|---|---|
| Company site, product and landing pages | First choice, full control over markup and delivery | Good choice when marketing publishes without a deploy | Oversized |
| Blog, magazine or knowledge base | First choice, content collections handle thousands of entries | Possible within the platform limits | Rarely sensible |
| Editors publish daily, several roles | Astro plus a headless CMS | Directly in the platform editor | Only with an editorial backend of its own |
| User logins, roles, personalised areas | Partly, through individual SSR routes and server islands | No | First choice |
| Marketing assembles layouts itself | Within a defined set of components | First choice | No |
How your Astro website development runs.
Goals, page types, URLs
What the site has to achieve, for whom, with which conversion goal. The structure follows.
Content model and CMS question
Which content becomes collections, which fields they need and who maintains them.
Design and components
Layouts, typography and states as pages in the browser, checkable on a phone early.
Build and measurement
Routes, collections, image pipeline, forms. Before sign-off: Lighthouse, metadata and a redirect test on staging.
Launch and handover
Domain, redirects, monitoring, then a check in Search Console and a walkthrough for your team.
Frequently asked questions about Astro web development.
What does Astro web development cost?
The range is set by the number of distinct page types, the depth of the content model including any CMS, and the scope of integrations. After the first call you get an estimate with its assumptions written down. The drivers in detail are on Astro development cost.
How long does Astro website development take?
From kickoff to go-live: four to six weeks for a focused build with three to five page types, eight to twelve weeks with an editorial operation, six to ten weeks for a relaunch that carries existing content across, from twelve with several languages or system integrations.
Do we need a CMS, and can we maintain content without a developer?
Not necessarily. Astro is CMS-agnostic, so content can live as Markdown in the repository, where the Zod schema flags missing fields. A headless CMS pays off when several people publish without developer tooling. You can also edit the site by chat.
Can we build the site with AI ourselves?
For a prototype, yes. For a site that is still maintainable two years later, much depends on information architecture, the content model and the redirect plan. We work with AI assistance ourselves and run every change through review, type checking and a build.
Will we lose rankings in the relaunch?
Not if the move is planned. We pull every indexed URL beforehand, turn it into a complete 301 list, keep the titles and headings of the load-bearing pages stable, and test the redirects before go-live. The routes are described under Astro migration.
When is Astro the wrong choice?
For applications with user logins, roles and heavy client-side state. For those we build a custom web application. And if your marketing team wants to assemble pages freely without ever seeing a repository, Webflow is the better tool.
Around the website project.
Operations, legal groundwork and fundamentals in the Astro cluster:
Ready for a website that ships as HTML?
Tell us briefly what you have in mind. You get an assessment of scope, content model and cost range, usually within 24 hours.
Request an Astro project.
New build or relaunch, rough scope, who maintains the content: three sentences are enough for a first assessment.
We usually reply within 24 hours.
Remote and on site in Germany, Austria and Switzerland. International projects on request.









