Astro · Development & Migration

Astro development agency for content sites that ship lean.

Astro is an open-source web framework for content-driven websites: it renders on the server, sends finished HTML to the browser, and ships client-side JavaScript only where a component actually asks for it. As an Astro development agency we use it for marketing sites, content and documentation portals, blogs and landing page systems – built new, or migrated from WordPress, Webflow, Framer and Next.js. We come from software engineering rather than site builders, so the content model, the integrations and the deployment are part of the plan. And we tell you upfront when Astro is the wrong answer for what you are building.

Start an Astro project See our services

Static HTML by default

Astro prerenders your site and serves static HTML. On-demand rendering gets switched on per route, only where a page genuinely has to be dynamic.

Islands, not a single-page app

Interactive components hydrate individually – immediately, when the browser goes idle, or once they scroll into view. The rest of the page stays plain HTML.

Honest scoping

Astro is a framework for content sites. If what you are building is a logged-in application, you hear that in the first call – not after the invoice.

01 — In short

Astro development agency: the short version.

In short

What Astro is: an open-source JavaScript web framework for fast, content-driven websites, released under the MIT license. Currently on the Astro 7 line.
How it works: server-first. By default the entire site is prerendered and shipped as static HTML; interactivity is added component by component – the islands architecture Astro coined.
What we build with it: marketing websites, content and documentation portals, blogs and landing page systems – built from scratch or migrated from WordPress, Webflow, Framer or Next.js.
Where the content lives: in Markdown and content collections inside your repository, or in a headless CMS. Astro is CMS-agnostic and stays the presentation layer.
What it costs: the range depends on page types, content model depth and integrations. We publish the cost drivers instead of throwing a number at you.
When Astro is wrong: for logged-in products carrying heavy client-side state. Then we build you a custom web application instead of an Astro site.

Astro 7Content CollectionsHeadless CMSIslands ArchitectureCore Web VitalsTypeScriptSEO by defaultGDPR-awareMarkdown & MDXServer-firstView TransitionsStatic HTML

02 — Why Astro

Why Astro – and when not.

Most websites are not applications. They present content, yet they ship an entire JavaScript framework to the browser so that a navigation menu can open. Astro reverses that order: HTML first, JavaScript only when something needs it. For you that means:

Server-first instead of client-first – Astro renders on the server and sends lightweight HTML to the browser. By default every page is prerendered; individual routes opt into on-demand rendering explicitly. That is not an optimisation bolted on at the end – it is the default state of the project.
Islands architecture – An island is an interactive component on an otherwise static HTML page: a search field, a configurator, a map, a booking form. The client:load, client:idle and client:visible directives let us decide per component whether it hydrates immediately, when the browser is idle, or only once it becomes visible. Server islands render dynamic parts on the server separately, so the shell of the page can stay aggressively cached.
Structured content instead of copy-paste – Content collections define a schema per content type, validated with Zod and typed automatically in TypeScript. If a required field is missing or a date is malformed, the build breaks. Not the live site.
Your CMS stays your decision – Astro is CMS-agnostic. Markdown in the repository, Storyblok, Sanity, Contentful, Strapi, Payload, Directus or WordPress running headless: there is a documented path for each. We pick based on how your editors actually work, not on our favourite tool.
Images, types and transitions included – Built-in image handling sets loading behaviour and dimensions itself, which keeps layout shift out of the page; TypeScript is built in and verifiable via astro check; client-side view transitions ship with the framework and are enabled deliberately rather than retrofitted.
Honest limits – Astro is a framework for content-driven websites. For a product with logins, roles, real-time data and heavy client-side state, another stack is the better foundation – then we build you a custom web application, and we say so before the project starts.

Framework

Astro – open source under the MIT license, currently on the Astro 7 line. Its own principles: server-first, content-driven, customizable.

Our stack

Astro sits in our stack alongside Webflow, Flutter, React Native and SwiftUI. We recommend the tool that fits the project – even when that tool is not Astro.

When it grows up

Websites sometimes turn into products. Web applications and custom software come from the same team that built the site.

03 — Services

Astro development services.

Six areas we work in with Astro – bookable individually or as one project from content model to ongoing operation.

Astro web development

New site or relaunch on Astro: information architecture, page types, component library, build and launch. Conversion-focused and built for search visibility from the first commit.

Web development

Migration to Astro

Moving off WordPress, Webflow, Framer or Next.js – content transfer, redirect map, and measurement before and after the switch. Including the honest question of whether the move pays off for you at all.

See migrations

Astro CMS & content collections

A content model inside the repository: collections with Zod schemas, type-safe queries, Markdown or MDX for editors. The cheapest route when content is structured but rarely edited.

Content setup

Headless CMS integration

When an editorial team works daily: selecting, modelling and wiring a headless CMS – from Storyblok and Sanity through to WordPress running headless.

Headless CMS

Performance optimization

An existing Astro site slower than it should be: we measure Core Web Vitals in the field, find needless hydration, image and font weight, and clear it out.

Performance check

Support & maintenance

Day-to-day operation: keeping dependencies current, planning major upgrades, adding page types, monitoring. Also for Astro projects somebody else built – after an audit.

Request maintenance

Got an Astro project in mind?

Describe it in three sentences. You get an honest assessment: whether Astro fits, what the realistic scope is – and which alternative we would recommend if Astro is not the right answer.

Request a first assessment

04 — Process

How an Astro project runs with us.

No standard package, but a standard sequence. After step one you know where you stand.

First assessment

You describe the project, the content and how your editors work. We say whether Astro is the right foundation, where the risks sit and what effort is realistic. That assessment is free and not conditional on us winning the work.

Content model & architecture

Which page types exist, which fields belong to them, what lives in the repository and what belongs in a CMS? This is also where we decide which routes are prerendered and which need on-demand rendering – that choice drives hosting and running costs later.

Design & components

Layout, typography and components in your brand style. We build a manageable component library instead of a hundred one-off pages, so new pages later take hours rather than weeks.

Build

Page types, collections, images, forms and integrations. Interactive islands get a loading priority assigned deliberately instead of everything hydrating at once. Type checks and builds run in continuous integration, not on one person's laptop.

Launch with an SEO net

Redirect map, metadata and schema setup, sitemap, analytics. We measure the site before and after go-live inside your own project – field data from your real users rather than somebody else's benchmark numbers.

Handover or ongoing care

The repository is yours, the code is documented inside it, your editors get a walkthrough. Then you choose: continue on your own, pull us in occasionally, or hand over ongoing maintenance.

05 — Decision

Astro is not always the answer.

We do not sell Astro against your project. These two columns are the honest filter we apply in the first call – and the right-hand column wins more often than an agency page should admit.

Astro fits when …

Content is the core of the product, and speed plus discoverability are commercially critical.

Your site mainly delivers content: service pages, blog, documentation, case studies, landing pages.
You want to generate many similar pages from structured data – locations, products, authors, categories.
Load time and search visibility matter measurably, and you are willing to make architectural decisions for them rather than install plugins.
You want control over the code: your own repository, your own deployment, no platform lock-in.
Your content comes from a headless CMS or several sources and needs to converge in a cleanly typed model.
You are replacing an existing site that is suffocating under plugins, themes or build times – see migration to Astro.

Another stack fits better when …

Then we recommend the other route – and build it ourselves if you want, rather than talking Astro into the brief.

What you are building is a logged-in application: roles, dashboards, real-time data, heavy client-side state. That is what custom software is for.
Your marketing team wants to build pages visually, without developers and without deployments. Then our Webflow agency work is the more honest proposal.
You depend on a plugin ecosystem – shop, membership area, booking system – and nobody in-house wants to touch code.
Most of your product is interactive on the client. Where nearly everything would be an island, an app framework is the better base: Astro vs. Next.js.
You need a campaign page tomorrow and have no setup budget. A landing page in a visual tool is faster and cheaper in that situation.
Nobody on your team wants to work with Git and deployments, and no maintenance is budgeted. Tools nobody operates turn into risk.

06 — Timeline

How long does an Astro project take?

Prices are not on this page. Timelines are. The ranges below are our honest estimate for the way of working described above – counted from kickoff to go-live, not from the first email.

Three shapes cover almost every enquiry that reaches us:

Focused marketing site, three to five page types, copy already written: four to six weeks. One set of page types, one language, no CMS, forms and analytics wired up. It only gets shorter when design and copy are already signed off.
Company website with a working editorial team: eight to twelve weeks. Six to twelve page types, a blog or knowledge section, a headless CMS with modelled content types, preview and roles, plus one or two integrations. The largest single item is rarely the code – it is the content model.
Relaunch with a migration, several languages or a large archive: fourteen to twenty weeks. An inventory of every indexed URL, a redirect map, content transfer, and sign-off in several rounds. The migration section describes that sequence in detail.

Two windows sit behind go-live, and we name them in advance so expectations match reality. A performance audit on an existing Astro site produces findings within one to two weeks; whether the improvement lands in the field only shows after four to six weeks, because field data is measured in a rolling 28-day window. After a migration we watch indexation and positions for several weeks as well: movement in the first weeks is normal, a permanent loss is a planning failure rather than a side effect.

These ranges are our own experience with our own way of working, not a number borrowed from somewhere. Which point inside the range applies to you is something we say after the first call – together with the assumptions it rests on.

What pulls the range down

Few genuine page types. Content carried over rather than rewritten. One language. A CMS whose model already exists – or no CMS at all. And one person on your side who is allowed to decide.

What pushes it up

Every additional page type – not every additional page. Content written from scratch instead of migrated. Every further language. A content model that has to be invented first. Integrations with systems we do not control: CRM, ERP, booking, payments. And approvals that travel through several committees.

The usual reason for delay

Not the technology: content and sign-off. When copy, images and access are ready and feedback returns within a few working days, the plan holds. When it does not, the date moves – and we say so early instead of waiting quietly. Where coordination spans several departments, we can take on project management as well.

06b — Measured

Measured, not claimed.

We do not quote borrowed benchmarks. This is the Lighthouse run for this very website – desktop measurement, verifiable yourself via PageSpeed Insights at any time.

0 Performance Lighthouse · this site

0 SEO Lighthouse · this site

0 Accessibility Lighthouse · this site

0 Best Practices Lighthouse · this site

07 — At a glance

Astro as a decision – at a glance.

Eight dimensions that genuinely come up in vendor selection: answered short, each with its caveat beside it. The last row is our opinion, not a summary.

Criterion	How it looks on Astro	The caveat
What it suits	Content-driven websites: marketing sites, blogs, documentation, portals with many structured pages, landing page systems. Astro describes itself as a framework for exactly this category.	Not a foundation for logged-in products with roles, real-time data and heavy client-side state. For those we build custom software.
Delivery model	By default the entire site is prerendered and served as static HTML. Client-side JavaScript is added only where a component asks for it through a client:* directive.	Speed is not automatic because of that. Hydrate one heavy island immediately on every page and the advantage is gone again – architecture does not replace discipline.
Editing	Three routes, combinable: Markdown with content collections, a headless CMS with an interface and permissions, or editing by chat through an agent writing into the same validated model.	No visual page builder. If your team wants to assemble layouts freely by drag and drop, Webflow is the more honest answer – and we build that too.
Hosting & operations	The static build runs on any CDN or static host, including a provider inside the EU. On-demand rendering is switched on per route through an adapter for the target runtime.	As soon as routes render at request time you need a runtime: running cost, one more part in monitoring, and a component that can fail.
Control & lock-in	Open source under the MIT license. Repository, hosting accounts and domain sit in your name. No platform subscription decides whether you can keep operating your site.	Control means responsibility. Without an in-house team or a maintenance agreement, a self-hosted stack ages faster than a managed platform.
Hiring & handover	Astro components are HTML, CSS and TypeScript. Interactive islands can be written in React, Preact, Svelte, Vue, SolidJS or Alpine.js – you hire from the general JavaScript market.	Fewer CVs carry "Astro" than carry "WordPress". Budget for onboarding time, even though it is short.
Timeline	Four to six weeks for a focused site, eight to twelve with an editorial operation, fourteen to twenty for a relaunch with migration or several languages – each measured from kickoff to go-live.	The range moves with page types, content volume, languages, integrations and your approval cycles. The bottleneck is rarely the technology.
Cost	No license fee for the framework. Effort comes from page types, content model and integrations; the drivers are itemised on Astro development cost.	A number published without knowing your project would be a guess. You get the estimate after the first call, with its assumptions written out.
Our take	For websites whose business depends on content and discoverability, Astro is currently our default recommendation. Not because it is new, but because the most expensive mistake in this category – an application framework carrying a brochure site – simply cannot happen here architecturally.	We advise against it when nobody on your side wants to touch Git and no maintenance is budgeted. Then we propose Webflow instead – we build that as well – and you avoid paying for a stack nobody ends up operating.

08 — FAQ

Astro development agency: frequently asked questions.

How much does an Astro website cost?

Three things set the range: the number of real page types (not pages), the depth of the content model, and the integrations – CMS, forms, CRM, commerce. A focused marketing site sits well below a relaunch with an editorial system, multiple languages and data migration. After the first call you receive a transparent estimate with its assumptions stated. The drivers are broken down on Astro development cost.

When is Astro the right choice – and when is it not?

Astro is built for content-driven websites: marketing sites, blogs, documentation, portals with lots of structured content. That is where it pays off, because the browser mostly receives HTML. For products with logins, roles and heavy client-side state it is the wrong foundation – then we recommend a custom web application, or Webflow if the priority is purely visual editing.

Can we edit content ourselves without touching code?

Yes, if we set it up that way. Two routes: content lives as Markdown in the repository and is read through type-safe content collections – good for technical teams and infrequent edits. Or you get a headless CMS with an editing interface, preview and permissions. Which one fits is decided by your editorial routine, not by technical preference.

We are on WordPress. Will a migration cost us our rankings?

Not if the migration is planned. We either keep the URL structure or produce a complete redirect map, migrate content including metadata and structured data, and measure visibility and load times before and after the switch inside your own project. The process, the risks and the cases where a move is not worth it are covered on WordPress to Astro.

Astro or Next.js – which should we pick?

Rule of thumb: the more your project is an application, the more it points to Next.js. The more it is a website, the more it points to Astro. Astro is a multi-page architecture with server rendering that removes client-side JavaScript unless a component requests it. Next.js brings the app model you need for dashboards and logged-in areas anyway. The full comparison lives on Astro vs. Next.js.

Does an Astro site need a server?

Not necessarily. By default the whole site is prerendered and static HTML pages are sent to the browser – that runs on any static host or CDN. As soon as individual routes should render at request time, for personalised content or form handling, an adapter for the target runtime is added; first-party adapters are maintained for Node, Vercel and Cloudflare among others. We decide that per route, not for the whole project.

How does maintenance work, and what happens at a major upgrade?

Astro follows semantic versioning, and exactly one previous major line still receives security fixes. Since two major versions shipped inside a single year, we treat upgrades as a small recurring task rather than a big project: dependencies updated regularly, build changes made visible, upgrades tested in a branch first. That is part of our support and maintenance work.

Do you work remotely, and which markets do you cover?

Project work runs remotely, in English and German. On-site workshops are practical across the German-speaking region – Dresden, Leipzig, Chemnitz, Berlin and beyond – and we work with clients outside Europe as well. Which markets, time zones and languages we cover is listed on markets.

Our marketing team wants to publish without waiting for the next sprint. What does that look like?

Three routes, combinable. A headless CMS with an interface, preview and permissions for daily editing. Markdown in the repository through content collections when content is structured but rare. Or editing by chat: an agent writes into the same schema-validated model, produces a traceable commit and sends a preview back – change a sentence, add a post, swap an image as a message rather than a CMS session. Chat agents are day-to-day work here; our own WhatsApp AI agent is the evidence. What chat does not replace: approval workflows in large editorial teams, and structural layout changes.

We have 4,000 blog posts. Will there be downtime during the switch?

No, because nothing is switched until the new site stands. The new site is built in parallel on its own environment, content is transferred by script rather than copied by hand, and the redirects are tested there before anyone touches the domain. The switch itself is a deployment and DNS change; the old environment stays reachable for the first days so a way back exists. What we do not promise is a zero-second guarantee – DNS propagation is not ours to control.

How long does a project with you take?

From kickoff to go-live: four to six weeks for a focused marketing site with three to five page types and existing content. Eight to twelve weeks for a company website with an editorial operation, a modelled CMS and one or two integrations. Fourteen to twenty weeks for a relaunch involving migration, several languages or a large archive. The range is moved by the number of real page types, content volume, whether content is migrated or rewritten, languages, integrations – and your approval cycles.

What do you need from us so the schedule holds?

Four things, none of them technical. One person allowed to decide, rather than a committee that reopens every round. Content in the state it should be published in – or a clear instruction that we write it. Access to domain, hosting, analytics and the legacy system at the start, not in week six. And feedback within a few working days. Where coordination runs across several departments, we can take on project management as well.

Does a niche framework make developers harder to hire?

Partly yes, and we say so openly: fewer CVs carry "Astro" than carry WordPress or React. The effort is still smaller than it sounds. Astro components are HTML, CSS and TypeScript; interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js. You therefore hire from the general JavaScript market, not from an Astro market. Onboarding is documentation plus the repository, not half a year of framework school. With a bespoke in-house architecture that risk would be considerably larger.

What happens if you disappear, or if we part ways?

You keep everything that makes up the project. The repository is yours from the first week, hosting and CMS accounts sit in your name, the domain does anyway. There is no license, no building block and no editor tied to us – Astro is open source under the MIT license. The repository contains a README explaining build, deployment and content model. Any team working with JavaScript and Git can take over. Switching agencies stays unpleasant, but it is not a rebuild.

Who is liable if something breaks after launch?

We are. Whatever we built that does not work as agreed, we repair under statutory warranty without a new invoice. That is separate from a change request: a new feature or a new page type is an order, not a defect – and which of the two a report falls under is something we say before we start, not afterwards. Fixed response and recovery times are agreed in writing when your procurement needs them; they belong in the maintenance agreement.

Our security reviewer is asking about the attack surface. What do we tell them?

That the classic attack surface of a content website largely disappears. A prerendered Astro site has no database, no admin login and no plugin ecosystem in the delivery path, so the usual route through a vulnerable extension does not exist. What remains and deserves review: repository and build-pipeline permissions, the provenance of npm dependencies, form and API endpoints, a headless CMS as a separate system with its own authentication, and domain and hosting accounts. We work with mandatory two-factor authentication, least privilege and regular dependency updates, and document where secrets live.

What about GDPR, hosting location and data processing agreements?

Astro is a framework and processes no personal data itself – the question is decided by hosting, forms, analytics and CMS. A static build can run with a provider inside the EU or in Germany. We self-host fonts instead of pulling them from third-party servers, analytics comes in variants without cookies, and the form endpoint is chosen deliberately rather than shipped by default. We name every service provider so your data protection officer can put the processing agreements in place. We do not give legal advice; sign-off stays with you.

We have accessibility obligations. Does an Astro project cover them?

No framework makes a website accessible. That comes from markup, contrast, focus order, forms and keyboard operation. Astro helps structurally in one place: it serves server-rendered HTML that is readable without executing JavaScript, and the built-in image component sets the alt attribute, loading behaviour and dimensions with it. Everything else we treat as a project requirement rather than rework: semantic structure, full keyboard operation, screen reader testing. We do not issue a legally binding conformance statement – we deliver the state your own assessment can evaluate.

Do you use AI tooling in development? What does that mean for our code and our data?

Yes, and we would rather say it than hide it. AI-assisted tooling speeds up routine work; a human stays accountable. Every change passes review, type checking and a build in continuous integration before it lands anywhere. Credentials, personal customer data and confidential documents do not go into such tools – that is a rule here, not a judgement call. If your policy restricts or forbids the practice, we follow it and put that in the contract.

Can we take development in-house afterwards?

Yes, if someone on the team works with HTML, CSS, JavaScript and Git. What you get for it: the repository with its full history, documented build and deployment steps, a manageable component library instead of a hundred one-off pages, and a walkthrough for both editors and developers. On request we pair for the first weeks and then step back. If, on the other hand, nobody in-house wants to touch deployments, the honest proposal is different: either Webflow or a maintenance agreement that leaves responsibility clearly with us.

You have no public Astro case study. Why should we trust you with this?

Because we would rather say that than invent one. We do not yet have a publicly showable Astro client project. What we do have: a Webflow reference we built and still look after, our own products that we developed and shipped ourselves, and years of software engineering with repositories, continuous integration and operations. The framework is the smaller part of that work. Testing us is cheap: the first assessment costs nothing, the repository is yours from day one, and measurement before and after launch happens inside your own project.

Is Astro free?

Yes. Astro is open-source software under the MIT license; there is no license fee for the framework itself. Cost comes from design, build, content, hosting and operations – and, if you use one, from the headless CMS.

Who is behind Astro?

An open-source project developed in public on GitHub. The MIT license lists the 2021 copyright as Fred K. Schott. Astro is maintained and advanced by a core team together with a community of contributors, currently on the Astro 7 line.

Can Astro run a blog?

Yes, and it is one of the cases the framework was built for. Posts live as Markdown or MDX in a content collection with a schema, queries run type-safe through getCollection(), and the built-in caching is explicitly intended for collections holding thousands of entries.

Is Astro good for SEO?

The technical foundation is good: every page is prerendered by default, so search engines receive finished HTML and do not have to execute JavaScript. Rankings do not follow from that alone – those come from content, structure and links. Where it stalls, an SEO audit finds it.

Can you use React components in Astro?

Yes. Official integrations exist for React, Preact, Svelte, Vue, SolidJS and Alpine.js, and several of them may appear on the same page – but only inside an .astro file. Existing components can often be carried over rather than rewritten.

09 — Cluster

Everything on Astro, in one place.

Each page answers exactly one question – services, migrations, comparisons and fundamentals:

Ready for a site that stays fast?

Tell us about your project – you get an honest assessment of Astro, scope and cost. Usually within 24 hours.

Start an Astro project

10 — Related