Home
Astro Agency
Astro Development Cost

Astro · Cost & Scoping

Astro development cost: what actually drives the price.

You came here with a specific question: what does it cost to have a website built with Astro? There is no honest number without knowing your project. There is, however, an honest answer to what moves that number up and down – and this page gives you all of it. The cost drivers, typical project shapes, the path to a defensible estimate, and the running costs most agencies only discuss after the contract is signed.

Request a cost estimate See the cost drivers

Templates, not pages

Effort follows the number of distinct page templates. Two hundred blog posts on one template cost less than twelve one-off layouts.

Running cost is the small line

A statically served Astro site runs on hosting that often stays inside providers' free tiers. The recurring line item is usually the CMS.

An estimate after one call

We do not quote blind package prices. After one conversation about scope, content and systems you get a transparent, itemised estimate.

In short

There is no list price – but there is a short, nameable set of factors that decide the effort. All of them are on this page, unvarnished.
The biggest lever is the number of distinct page templates, not the number of pages.
The second biggest is content: migrating is cheaper than rewriting – and whether you need a CMS at all shifts the frame considerably.
In operation, static hosting is cheap to free, a headless CMS is the usual recurring line item, and maintenance is a choice, not an obligation.
How we get to a number: a first call, scoping along the templates, then an itemised estimate you can defend internally – before the project starts, not as a surprise on the final invoice.

01 — Cost drivers

What drives the cost of an Astro website.

Astro itself costs nothing: the framework is free open-source software under the MIT licence. What you pay for is work – concept, design, build, content, integration and safeguarding. These eight factors decide how much work that becomes:

The number of distinct templates – The most important factor and the most commonly misread one. A site with 300 subpages running on five well-built templates costs less than a 15-page site where every page looks different. In scoping we therefore count templates, not pages – and we tell you where a one-off layout is not worth its price.
Content: migrated or rewritten – Taking existing copy and imagery, structuring it and fitting it into a content model is diligent work with predictable effort. New copy, new imagery and a new argument are a separate project running alongside the build. Both are legitimate – but they are two different invoices.
Does the project need a CMS at all? – Astro reads content through content collections straight from files in the repository. For a site maintained by developers or a technically confident editor, that is often enough. The moment marketing needs to publish without a developer, a headless CMS joins the build: more effort up front, a recurring line item in operation, and day-to-day independence in return.
Design: from scratch or on an existing system – If brand, colours, typography and components are already defined, we build against them. If not, design belongs to the project scope – including the rounds it takes until everyone involved agrees. An existing design system is the most reliable way to reduce cost.
Integrations – Forms with spam protection and GDPR-compliant delivery, a CRM, analytics, a consent banner, newsletter, booking, site search: each is small on its own and a noticeable block in aggregate. We list them individually in the estimate so you can see which ones can wait for phase two.
Languages – The second language costs less than the first, because the structure already exists. What gets expensive is not the technology but the content: translation, upkeep, market-specific legal pages, and the question of who keeps the second language current.
Static or server-rendered – Astro prerenders and ships static HTML by default – the cheap case in both build and operation. As soon as individual routes must be rendered on demand, an adapter for the target runtime joins the stack, along with a running server environment and the cost of operating it. We check honestly whether your dynamic area truly requires that.
Relaunch: redirects and SEO safeguarding – On a greenfield build this line disappears. On a relaunch it is one of the most important: URL mapping, a redirect plan, structured data, and measurement before and after go-live. Whatever you save here you pay later in lost rankings. Details on the migration to Astro page.

Why there is no price list here

Package prices on a website are either set high enough to cover every eventuality, which scares off small projects, or low enough to generate enquiries and get corrected in the quote. Neither helps you plan a budget.

What you get instead

An itemised estimate: templates, content, CMS, integrations, migration, safeguarding. Running costs stated separately. You can see which line carries which share – and cut with an argument.

When the budget is smaller

Then we tell you which line gives the best return and what can move to a later phase without damage. A first version that is live and working beats a perfect version that stays in the concept deck.

02 — Project shapes

Five typical project shapes – and where the effort sits.

No price tags, just the logic of effort. Find the row closest to your project: the third column shows what blows up the frame, the fourth what we would cut first.

Most projects are a mix of two of these rows. Which two is what the first call establishes.
Project shape	Typically in scope	Pushes the price up	What we would cut first
Focused marketing website	A handful of templates, content already exists, no CMS, one contact form, static delivery.	A bespoke layout per page, elaborate animation, custom illustration.	The one-off layouts. A well-built template carries more pages than most people expect.
Website with a blog and editors	Marketing templates plus an article template, content collections or a headless CMS, a clear editorial workflow.	A CMS with roles, approvals and live preview; a large set of freely combinable content blocks.	The block variety. Five well-considered blocks beat twenty half-finished ones.
Relaunch of an existing website	Inventory, content migration, redirect plan, structured data, measurement before and after go-live.	Organically grown URL structures, legacy content with no clear owner, many special-case pages.	Legacy content with no traffic and no purpose. A relaunch is the best moment to clear house.
Multilingual website	One template set for all languages, a clean hreflang structure, a defined translation workflow.	Every additional language with its own editors, its own legal pages and its own upkeep.	Languages with no sales motion behind them. Adding later is cheaper than maintaining a dead one.
Website with dynamic areas	Static pages plus individual server-rendered routes, the matching adapter, a running server environment.	Anything requiring login, personalisation or live data – in the build and permanently in operation.	Dynamics that also work as an independently deferred component or a small client-side island.

03 — Process

How we get to a number.

Five steps from the first conversation to an estimate you can put in front of a managing director.

The first call

What the website is for, who it serves, which systems already exist, the timeline, the rough budget frame. At the end we say whether Astro is the right tool for your case. If a visual builder such as Webflow would be cheaper and faster for you, you hear that from us – an honest no beats an expensive yes.

Scoping along the templates

We walk through your site structure and count distinct templates instead of pages. This is the moment a gut feeling turns into an effort estimate – and the moment it almost always turns out the website is smaller than it feels.

Settling content and systems

What gets migrated, what gets rewritten? Who maintains it afterwards, and with what prior knowledge? Is a CMS needed, and if so which one? Which forms, which consent setup, which analytics, which CRM? Every one of these answers is a line in the estimate.

The itemised estimate

You receive the effort broken down: concept and design, templates, content model, integrations, migration and safeguarding. Running costs for hosting, CMS and optional care are stated separately. Transparent means you can question each line on its own.

Decide the cut, then build

If the frame does not fit, we cut together along the fourth column above. During the build the rule is: change requests that move the frame get named before they become effort, not afterwards on the invoice. Larger programmes can run with IT project management on top.

04 — Honest limits

Hire an agency, or build it yourself?

Astro is a developer framework with good documentation. The fact that you can learn it yourself is not something we hide from you – it belongs in any honest conversation about cost.

Build with an agency when …

The investment pays off when the website has a measurable job to do.

The website is a sales channel and rankings, load time and conversion translate directly into revenue.
A relaunch is due and existing rankings must not be lost.
Marketing and editors need to publish later without a developer in the loop.
Several languages, a CMS or connected systems such as CRM and shop are in play.
Nobody on the team has lasting time for dependencies, deployments and security updates.
You need one point of contact who still knows in two years why something was built the way it was.

Build it yourself when …

Astro is open source under the MIT licence and the barrier to entry is low. We say that openly, even though there is nothing in it for us.

Someone on the team already works with a frontend framework and gets real time allocated for it.
It is a portfolio, documentation or side-project site with no revenue responsibility.
You want to test whether Astro suits your team before any budget moves.
The content lives in Markdown and nobody outside engineering has to maintain it.
You are building to learn something anyway – a perfectly legitimate project goal.
Even then a short review before go-live is worth it: a fraction of the effort of a new build.

You need a number, not a brochure.

Describe your project in three sentences: rough site structure, existing content, desired timeline. You get an honest assessment – including a straight answer if a different tool would be cheaper for your case.

Request a cost estimate

05 — Timeline

How long does it take – to the estimate, and to go-live?

Prices are not on this page. Timelines are. On a cost page that is not a side note: every extra week is effort, and most budget overruns are schedule overruns wearing a different name. The ranges below are our own experience with the way of working described above – counted from kickoff to go-live, not from the first email.

First the part that moves you forward fastest: from the first call to a written estimate is usually a few working days to a week. What we need for that is a rough site structure, a statement about the content, and information on the systems that have to be connected. That assessment costs nothing and is not conditional on us winning the project.

After that, the shape decides. Three shapes cover almost every enquiry that reaches us:

Focused marketing website, three to five page types, content already written: four to six weeks. One language, no CMS, forms and analytics wired up, static delivery. It only gets shorter when design and copy are already signed off – then it is pure implementation.
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, sign-off in several rounds. The migration section describes that sequence in detail.

What moves the range is almost always the same set of variables that moves the budget: the number of distinct page types – not pages –, whether content is carried over or rewritten, whether a CMS joins and who fills it, every further language including its legal pages, every integration with a system we do not control, and your own approval cycles. Two review rounds per template are weeks, not days – the single most underestimated item.

The usual reason for delay is not the technology. It is 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. A delay nobody names still ends up on an invoice.

Two windows sit behind go-live and belong in the plan anyway: field data on load times matures in a rolling 28-day window, so an effect is only defensible after four to six weeks. After a migration we watch indexation and positions for several weeks as well. Both are observation rather than build effort – but if you do not plan for them, you pass judgement after ten days on something that is not measurable yet.

What pulls the frame down

Few genuine page types. Content carried over rather than rewritten. One language. A design system that already exists. No CMS – or one whose model is already defined. 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. Integrations with CRM, ERP, booking or payment providers. And approvals that travel through several committees.

When the date matters more than the scope

Then we invert the order: we fix the date and cut the scope to fit – first phase live, the rest in phase two. Where coordination spans several departments, we can take on project management as well.

06 — At a glance

The cost question at a glance.

Nine dimensions that actually come up in budget conversations: answered briefly, each with its caveat next to it. The final row is our opinion, not a summary.

Cost dimensions of an Astro website. The final row is an opinion held by vincubate, not a measurement.
Criterion	How it looks with Astro	The caveat
Licence and tooling	Nothing is due for the framework: Astro is open source under the MIT licence. Image optimisation, type checking and build tooling are built in and carry no licence either.	Free is not effort-free. What you pay for is work – and a built website costs more up front than an off-the-shelf theme that somebody configures.
The largest item in the build	The number of distinct page templates. Three hundred subpages on five clean templates cost less than fifteen pages with fifteen layouts – which is why scoping counts templates, not pages.	Templates only save money if the design plays along. If you want a bespoke layout per page, you pay for it – no framework changes that.
Content	Migrating is diligent work with predictable effort: cleanly structured legacy content can be moved into schema-backed content collections with scripts.	Newly written copy is a separate project alongside the build, with its own timeline. And legacy content without clear fields becomes manual work – the item most often underestimated.
Editing and CMS	Without a CMS, content sits as Markdown in the repository: no recurring line item. With a working editorial team a headless CMS joins – or editing by chat into the same validated model.	The CMS is usually the largest recurring line item in operation, and a block of its own in the build for modelling, preview and permissions. Without a CMS every copy change stays a development task.
Hosting and operation	The static build sits on any CDN or static host, frequently still inside a free tier. What to watch for is on the Astro hosting page.	As soon as routes render on demand you need a runtime: recurring cost and one more component in monitoring. Free tiers have limits on traffic and build minutes – and an EU hosting location often takes you out of them.
Relaunch safeguarding	URL inventory, redirect map, metadata, structured data and measurement before and after go-live. On a greenfield build this item disappears entirely.	It cannot sensibly be cut. The effort scales with the state of the old URL structure – and what you save here you pay in visibility rather than in invoices.
Maintenance and upgrades	Astro follows semantic versioning, and security fixes exist for exactly one previous major version. We plan upgrades as a small recurring task – see Astro upgrade and support and maintenance.	Two major versions arrived within a single year. Leave dependencies untouched for two years and you pay the jump in one lump. Maintenance is optional – its absence is not free.
Contract and billing model	An itemised estimate, billed on time and materials against an agreed cap. Fixed price where the scope is sharply bounded: defined templates, settled content, no open questions about systems.	A fixed price over a fuzzy scope always contains a risk premium. You pay it even when the risk never materialises – so we only propose it when it buys you real certainty.
Our take	Budget an Astro project across three years, not across the last invoice of the build. The build itself usually lands where a properly made website lands in any other tool. The difference shows up afterwards: little attack surface, no extension estate that wants maintaining, and an operation that rarely surprises anyone.	We advise against it when the budget covers the build and nothing else. If there is nothing left for care and operation, a Webflow project or a well-maintained WordPress install is the more honest suggestion – both cost less than a website nobody touches after a year.

07 — FAQ

Frequently asked questions about Astro development cost.

What does an Astro website cost?

It comes down to a short list of factors: the number of distinct page templates, whether content is migrated or rewritten, the CMS, the integrations, the languages, and how much safeguarding a relaunch needs. A focused marketing site sits well below a multilingual relaunch with an editorial CMS. After the first call you receive a transparent, itemised estimate rather than a guess.

Why do you not publish a fixed price?

Because a number without knowledge of your project only comes in two forms: high enough to cover every eventuality, or low enough to generate enquiries and get corrected in the quote. Neither helps you. Instead we name every factor that sets the price openly, and deliver the number after a conversation – then defensible and broken down by line.

What does it cost to run an Astro website?

A statically served Astro site is cheap to operate: it is prerendered HTML that any static host or CDN can serve, frequently still within a free tier. The usual recurring line item is the CMS, if one is used, plus the domain and any paid services such as a form or search provider. On-demand rendering additionally requires a running server environment.

Is Astro cheaper than WordPress?

For the build, usually not: an off-the-shelf WordPress theme is cheaper than a website that gets built. In operation it often flips – no plugin licences, no update and security cycle across a large plugin estate, no PHP hosting with a database. The honest answer is that it depends on the time horizon. The details are in the Astro vs WordPress comparison.

What does migrating an existing website to Astro cost?

Three things decide it: how many distinct templates the old site has, how cleanly its content is structured, and how much ranking substance has to be protected. Documented migration paths exist for WordPress and Next.js; from Webflow or Framer the route is export plus rebuild. The process is on the WordPress to Astro page.

Can we start small and expand later?

Yes, and we often recommend it. A first phase with a few templates and the essential content goes live sooner and produces data sooner. A CMS, further languages and additional integrations can follow without rebuilding the structure – provided the content model was laid out for that from the start. Making sure of that is part of our scoping.

Who maintains the content afterwards, and what does that cost?

You decide that in scoping, and it is a genuine cost question. Without a CMS, engineering maintains it; with one, your team does. Ongoing care is an option with us, never a lock-in: you can take the code and continue on your own. What a maintenance package covers is described under Astro support and maintenance.

How binding is your estimate – and what still moves it after we have it?

The estimate states the effort per line and the assumptions it rests on. It is binding to the extent that those assumptions hold. In our experience five things move them: a page type that never surfaced in scoping; content that ends up being rewritten after all; a CMS added late; an interface that turns out to be undocumented; and extra approval rounds. All five get named before they become effort, not afterwards on the invoice.

Fixed price or time and materials – what do you propose?

Usually time and materials against an agreed cap, with the lines of the estimate as the structure. That is normally cheaper for you, because you do not pay for a risk that never materialises. We do fixed price where the scope is sharply bounded: defined templates, settled content, no open questions about systems. Over a fuzzy scope a fixed price always carries a premium – we tell you how large it would be and let you decide.

What happens if the scope changes mid-project?

Changes are normal. They only become unpleasant when they get built in quietly and billed later. Our procedure: any request that moves the frame gets named before it becomes work. You receive the effort and the schedule consequence in writing and decide – build it, defer it, or swap it against another line. Small corrections run along inside the frame; we do not draw a border there that helps nobody.

What are the payment milestones – do we pay up front?

The first call and the initial assessment cost nothing, so nobody is out of pocket there. From the order onwards we work in milestones rather than one final invoice: a deposit at project start, an interim payment on staging sign-off, the remainder after go-live. On longer projects we bill monthly against progress instead, so the amounts stay predictable. The exact split is in the quote and agreed before the project starts, not after.

Our budget is smaller than your estimate. What does the cheapest defensible version look like?

One set of templates instead of bespoke layouts, existing content instead of new copy, one language, no CMS – maintained through Markdown or chat –, static delivery, one form with consent, analytics. That is a complete website, not a stopgap. Three things we do not cut: the redirects on a relaunch, the accessibility basics, and the measurement before and after launch. Saving on those is what gets expensive later.

Our marketing team wants to publish pages themselves without waiting for a sprint. What does that cost?

Three routes with different cost curves. A headless CMS costs modelling of content types, preview and permissions in the build, plus a recurring fee in operation – the right route for daily editorial work. Content collections cost nothing to run but need somebody comfortable with files. Or editing by chat: a one-off setup, after which an agent writes into the same schema-validated model and produces a reviewable commit. Chat agents are day-to-day work for us – the proof is our own WhatsApp AI agent. What chat does not replace: approval workflows for large editorial teams and structural layout changes.

What happens to our investment if you are unavailable, or if we part ways?

You keep everything that was paid for. The repository is yours from the first week, hosting and CMS accounts are in your name, the domain anyway. Astro is open source under the MIT licence; there is no licence and no building block tied to us. A README in the repository explains build, deployment and content model. Design, content model and templates are therefore not paid for twice. Changing agencies stays unpleasant – it is not a rebuild.

Who is liable if something breaks after launch, and who pays for the repair?

We are. What we built and what does not work as agreed, we fix under statutory warranty without a new invoice. Separate from that is the change request: a new feature or a new page type is an order, not a defect. Which of the two a report falls into is something we say before we start, not afterwards. Guaranteed response and recovery times cost extra and belong in the maintenance agreement, not in a promise by email.

Security and data protection are reviewing this: attack surface, hosting location, subprocessors. What does that cost?

The base case costs little, because a prerendered Astro site runs no database, no admin login and no extensions in the delivery path. What still deserves review: permissions on the repository and build pipeline, the provenance of npm dependencies, form and API endpoints, a headless CMS as a system of its own, and the domain and hosting accounts. Effort appears in three places: hosting in Germany or the EU often takes you out of free tiers, every service in use needs a data processing agreement, and your procurement questionnaires are working time. We name every provider we use; we do not give legal advice. More under GDPR-compliant websites.

We have accessibility obligations. Is that included in the price?

The fundamentals yes, a certificate no. Semantic structure, contrast, focus order, keyboard operation and labelled forms are treated as a project requirement – far cheaper than retrofitting them. Astro helps structurally, because server-rendered HTML stays readable without JavaScript and the built-in image component sets alternative text, loading behaviour and dimensions. What costs extra is an external audit and the rework it produces. We do not issue a legally binding conformance statement. Details on accessible websites.

Do you use AI tooling in development – does that make it cheaper for us?

Yes we use it, and no, we do not sell a blanket discount for it. AI-assisted tools take routine work off the table; the expensive parts of a project stay where they were – decisions, content model, coordination, sign-off. A human stays responsible: every change goes through review, type checking and a build in continuous integration. Credentials, personal data and confidential documents do not belong in such tools. If your policy restricts their use, we follow it and put that in the contract.

Can we continue this in-house later – or does a niche framework get expensive on hiring?

You can continue it as soon as somebody on the team works with HTML, CSS, JavaScript and Git. You get the repository with full history, documented build and deployment steps, a manageable component library and a handover session; on request we pair through the first weeks. On the hiring market, honestly: there are fewer CVs with "Astro" on them than with WordPress or React. The premium stays small, 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.

You have no public Astro reference. Why should we trust you with a budget?

Because we would rather say so than invent one: we do not yet have a publicly showable Astro client project. What we do have is a built and maintained Webflow reference, our own products developed and shipped by us, and years of software development with repositories, continuous integration and operations. The framework is the smaller part of that work. Testing us is cheap: the initial assessment costs nothing, the repository is yours from day one, and on request we cut a small first phase – an affordable test rather than a leap of faith.

Is Astro free?

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

Does an Astro website need a server?

Not necessarily. By default the entire site is prerendered and served as static HTML, which runs on any CDN or static host. Only when individual routes have to render on demand does an adapter for the target runtime join in – officially for Node, Vercel and Cloudflare among others.

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 may appear on the same page – though only inside an .astro file. Existing components can often be carried over instead of being paid for a second time.

08 — Keep reading

More from the Astro cluster.

If you still need to settle whether Astro fits before the budget conversation:

What would your Astro website cost?

Three sentences on scope, content and timeline are enough for a first pass. You get a transparent estimate after the initial call – usually we come back within 24 hours.