Astro web development: fast websites your team actually owns.

Astro is an open-source, MIT-licensed web framework for content-driven websites. It renders on the server, ships static HTML by default and removes client-side JavaScript from components until you explicitly ask for it. For marketing sites, magazines and documentation that model simply fits better than a single-page application. We go into more depth on What is Astro?.

Three things set the range: the number of distinct page types (not pages), the depth of the content model including any CMS, and the scope of integrations. A focused company site sits well below a relaunch with an editorial system, multiple languages and interfaces. After the first call you get a transparent estimate with its assumptions written down. The cost drivers in detail are on Astro development cost.

Four things, and none of them is technical. One person who is allowed to decide, rather than a committee that reopens every round. Content in the state it is meant to appear 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 spans several departments, we can take on project management as well.

Not necessarily. Astro is CMS-agnostic: content can live as Markdown, MDX, JSON or YAML files in the repository and be queried through content collections. A headless CMS pays off when several people publish without developer tooling, when approvals are needed, or when content is reused across channels. Below that threshold it is extra cost and one more system to operate. We settle this with you before anything is built.

Yes, if it is set up that way – and we set it up that way. With a CMS your team edits in forms and saving triggers a build. Without a CMS you edit Markdown files directly in your repository interface, and the Zod schema flags missing fields before anything goes live. Structural changes – a new page type, a new component – remain development work. On request we can also let you edit the site by chat.

Yes, within what we define up front. We build a set of approved sections – hero, text block, image sequence, quote, form, FAQ – that your team assembles into new pages in the CMS, metadata and preview included. A new building block or a new page type stays development work. If marketing wants completely free layout control instead, Webflow is the more honest tool – we build that as well, and we would rather say so before the project than after it.

We build on them. Your tokens for colour, typography, spacing and states become a component library in code, and a maintained Figma library measurably shortens the design phase. What we raise rather than change quietly: effects that only work inside a design tool – heavy animation, large image areas, many type weights – cost load time or usability. In those cases we propose an implementation that stays on brand and still measures well. Without existing templates we design, and the design phase grows accordingly.

It is carried over structurally, not copied. First an inventory: which pages exist, what traffic and inbound links they have, what can go. Then the mapping onto collections and fields – title, date, author, image, category. Then the import through an export file or a script, images and metadata included. Content that exists in the old system only as a freely assembled page has no field model and has to be restructured. Anything we think you can drop, we say so – and still redirect the old URL properly.

Yes, and early. Every state of work sits on its own preview URL produced by continuous integration: real environment, real content, real behaviour on a phone rather than screenshots. You comment there, we work it in, and every change produces a new preview. Before sign-off we run type checking, the build, Lighthouse and a pass over metadata, redirects and accessibility. Preview environments are meant for your team: they are locked and not indexed.

As a default target, the two most recent versions of Chrome, Safari, Firefox and Edge on desktop, tablet and phone; if your own usage data says otherwise we move the target and record it in writing. There is a structural advantage on top: because an Astro page is shipped HTML at its core, it stays readable where JavaScript fails or is blocked. Old browsers such as Internet Explorer are no longer a target. Where a corporate intranet still runs one, we price that in before the proposal.

Yes, completely. The repository sits in your organisation, the hosting account and domain are in your name, the CMS credentials are yours. Astro is MIT-licensed, so there is no platform licence and no licence from us. Any other agency can take the project over without rebuilding anything. We prefer to convince through work rather than lock-in.

Yes, if someone on the team works with HTML, CSS, JavaScript and Git. You receive the repository with its full history, documented build and deployment steps, a component library small enough to hold in your head, and a walkthrough. On hiring, honestly: fewer CVs carry "Astro" than carry "WordPress". The effort stays small anyway, because Astro components are HTML, CSS and TypeScript and interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js – you hire from the general JavaScript market. On request we pair with your team for the first weeks.

You keep everything that makes up the project. The repository is yours from the first week, hosting and CMS credentials are in your name, the domain anyway. There is no licence, 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 is never pleasant, but it is not a rebuild.

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

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

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 Germany or the EU. We self-host fonts instead of loading them from third-party servers, analytics has cookieless options, and the form endpoint is chosen deliberately rather than shipped with the tool. We name every service provider involved so your data protection officer can put the processing agreements in place. What that means in practice is on GDPR-compliant websites. We do not give legal advice.

No framework makes a website accessible. That comes from markup, contrast, focus order, forms and keyboard operation. Astro helps structurally in one place: it ships server-rendered HTML that is readable without executing JavaScript, and the built-in image component sets the alt attribute, loading behaviour and dimensions. Everything else we treat as a requirement inside the project rather than as rework – details on accessible websites. We do not issue a legally binding conformance statement; we deliver a state your own audit can assess.

Not if the move is planned. We pull every indexed URL beforehand, turn it into a complete 301 list, keep the title and heading structure of the load-bearing pages stable, and test the redirects before go-live. After launch we watch indexing and rankings for several weeks and correct what drifts. The individual routes are described under Astro migration.

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

When you need an application rather than a website: user logins, roles and permissions, complex business logic, heavy client state. For that we build a custom web application. And if your marketing team wants to assemble new pages itself without ever seeing a repository, Webflow is honestly the better tool. We build both – so we do not need to sell you Astro.

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

Not necessarily. By default the whole site is prerendered, static HTML pages go to the browser, and that runs on any CDN or static host. Only when individual routes need to render at request time does an adapter for the target runtime join in – officially maintained ones include Node, Vercel and Cloudflare.

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

Yes. There are official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js, and several of them may appear on the same page – though only inside a single .astro file. Existing components can often be carried over rather than rewritten.