Astro consulting – independent, even when the answer is no.
Astro consulting for teams with their own developers: architecture fit, code review, content modelling and enablement – four modules, bookable individually, closed out in writing and genuinely open-ended.
Open-ended by design
We do not depend on Astro winning: we also build in Webflow and we build custom software. A recommendation against Astro is a regular outcome of this work, not a failure.
Written, not verbal
Every module ends with a document you can use without us: recommendation, reasoning, alternatives, risks – and the effort attached to each of them.
Short and time-boxed
Consulting here is not a retainer. Modules run days to a few weeks and end with a decision, not with the next meeting.
See for yourself what we build.
Real screenshots instead of promises: Mini Marvin is our own progressive web app – conceived, built and run live in the browser by us. We bring the same care to your web project.
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.
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
Astro consulting: the short version.
What this is
- Independent advisory work around Astro – for teams who build themselves or have not decided yet.
- Four modules, bookable individually: framework decision review, architecture and content model review, Astro code review, team enablement.
Who it is for
- In-house engineering teams, technical leads, and managing directors facing a platform decision – plus agencies who want a second opinion without handing over the account.
Why independent
- We also build in Webflow and we build custom software.
- We earn nothing from the answer turning out to be "Astro".
What you get
- A written result per module – recommendation
- Reasoning
- Named alternatives
- Findings sorted by impact and effort
- And a walkthrough with the people who decide
How long
- Days to a few weeks per module.
- The ranges, and the variables that move them, sit in their own table further down this page.
When you do not need this
- When the decision has already been made internally and only needs backing up.
- A review is the wrong instrument for that – and we would rather say so beforehand than afterwards.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
Six situations teams call us from.
None of them is an emergency. All six get expensive if you sit them out, because the decision in question gets harder to reverse every week.
The decision in a vacuum
Two developers want Astro, the rest of the team only knows React, and nobody can say what follows from that decision in two years. The discussion goes in circles because there is no independent basis – only preferences at different volumes.
The proposal you cannot evaluate
An agency has proposed Astro. The quote reads plausibly, but nobody in-house can judge the effort, the architecture or the running costs that come later. So you are signing trust rather than substance.
The content model that was fixed too early
The project is running, the first page types exist – and now it turns out the schema never anticipated a third language. Every correction touches templates, CMS, editors and redirects at the same time.
The inherited codebase
You took over an Astro site somebody else built. It runs. Whether it is healthy, nobody knows – and the first substantial change will reveal what has accumulated behind the surface.
The team left alone after launch
The site is live, the external team is gone, and your developers are supposed to carry on. Without agreed conventions, three months produce three different Astro dialects in the same repository.
The suspicion that the framework is not the problem
The site is slow, editing takes forever, the project keeps stalling. Sometimes that is an architecture question. Often it is a question of ownership and process – and then changing technology changes nothing at all.
Unsure about the stack?
We will tell you when another tool fits your project better.
Four modules. Bookable one at a time.
Each module answers exactly one question and ends with a document. You can start at module one – or step in wherever your project currently stands.
1 — Framework decision review
The independent answer to whether Astro is the right foundation for this project. With a written recommendation, at least one named alternative and the risks on both routes. The recommendation may well be "not Astro".
Astro vs. Next.js2 — Architecture and content model review
How page types, content collections, the CMS boundary and the rendering strategy should be shaped before code exists. This is the decision that is most expensive to reverse later.
Astro CMS & content collections3 — Astro code review
A read of an existing codebase: hydration, rendering, schema discipline, images, dependencies, build. Findings prioritised by impact and effort – including the ones you should deliberately leave alone.
Performance optimization4 — Team enablement
Getting your in-house team productive in Astro: the conventions worth agreeing up front, two workshop days, and accompanied weeks of pairing and reviews. The goal is that you stop needing us.
Astro web developmentGot a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
What actually happens inside each module.
Consulting is a word you can hide anything behind. So here is what we look at, how we weigh it, and what lands on the table at the end.
Module 1 – Framework decision review
The question is not "is Astro good?" but "is Astro the right foundation for this project, this team and this operating context?". Those are two entirely different questions, and only the second one can be answered. We look at what the site actually has to do: deliver content, or be a logged-in application. How many real page types exist – not how many pages. Where content comes from and who maintains it day to day. Which integrations are non-negotiable. Where it is hosted and who owns operations. Which skills the team already has and which would have to be bought in. And how long the decision has to hold before it gets reopened anyway.
The result is a written recommendation with its reasoning, at least one named alternative, the risks on both routes and an effort range. If the answer is "not Astro", it says so on the first page, in the same plain language an endorsement would get. For the most common comparisons the arguments are already public: Astro vs. Next.js, Astro vs. WordPress and Astro vs. Webflow. If you need the fundamentals first, they are on what is Astro.
Module 2 – Architecture and content model review
This is the module we would push hardest if we were only allowed to recommend one. The most expensive mistake in an Astro project is rarely the code – it is the content model. A schema that is two fields off one week into the project costs hours. The same schema corrected after launch costs templates, editor retraining, data migration and redirects at once.
So we cut it up front. Which page types genuinely exist, which fields belong to each, and which of them are required? Where does the boundary between repository and CMS run – what sits as Markdown in content collections with a Zod schema, and what belongs in a headless CMS with an editing interface and permissions? Which routes are prerendered and which genuinely need rendering at request time, on which adapter and at what running cost? Which components may carry a client directive at all, and at which loading priority? What do URL structure, multilingual setup and navigation look like before content hangs off them?
You end up with a page type matrix, a schema draft, a rendering decision per route, and a list of the decisions still open – each with our proposal and the reasoning beside it. Who builds from that is a separate question.
Module 3 – Astro code review of an existing codebase
Here we read what already exists. Twelve things are on the list regularly: the hydration strategy, and whether client:load sits where client:visible would have done; the split between prerendered and on-demand routes together with the adapter choice; discipline in the content schema and whether it has gone soft over the months; image handling, and whether images bypass the built-in processing because they live in the public directory; component boundaries, and whether layouts and components are still distinguishable; TypeScript strictness, and whether astro check and the build run in continuous integration rather than on one laptop; the state of dependencies and the distance to the current major line; build times and what drives them; routing and redirects; semantic markup and accessibility; metadata and structured data; and how secrets and environment variables are handled.
Every finding gets two values: impact and effort. That produces four buckets – fix now, fix next sprint, plan as a rebuild, and deliberately leave alone. The fourth bucket matters to us: not everything that stands out needs touching, and a review that only manufactures work has missed its purpose. You get the findings with their locations plus a walkthrough with your team. If it turns into implementation, the routes are performance optimization and support and maintenance – including for projects somebody else built.
Module 4 – Team enablement
A team does not become productive by knowing the syntax. It becomes productive once the conventions are agreed, before three people invent three answers to the same question. So we put exactly those agreements first. When is a .astro component written and when a framework component? The default is no client directive at all – every single one needs a documented reason. Who owns the content schema, and who is allowed to change it? What do folder structure and naming look like? What belongs in a layout, what in a component? What is in the definition of done, and do astro check and the build run as a gate in CI? How are images handled? And when are major upgrades scheduled, so they stay small tasks instead of becoming projects?
The format is two workshop days – one on fundamentals, one on your own project – followed optionally by four to six accompanied weeks of pairing and code reviews. The conventions land as a document in the repository, not in a slide deck. If your team comes from React, Vue or WordPress, the real adjustment is not the language but the reflex: in Astro, the normal case is that nothing hydrates.
What we bring
We come from software engineering and from IT project management. That combination is why a review here does not stop at "this is how we would do it", but continues into effort, sequence and risk.
What we do not bring
No public Astro client reference. Astro is part of our stack, but we have no case we are allowed to show yet – and we do not pretend otherwise. What you can check is the method: our Webflow work and our own products.
Access
A code review needs read access to the repository and, where they exist, build logs and field data. Production access, editor accounts and customer data are neither needed nor wanted.
Languages and places
English and German. Analysis and reports run remotely; workshops and walkthroughs can happen on site across the German-speaking region. Details on markets and collaboration.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
How a consulting module runs.
Six steps, identical across all four modules. After step one you know whether you need one of them at all.
First call
30 to 45 minutes. You describe the project, the current state and the bottleneck. We say which module fits – and whether any of them is necessary. That assessment is free and not conditional on it turning into work.
Scope and quote
A quote naming the module, its scope, its duration, the access required and what exists at the end. Transparently calculated, with the assumptions visible next to it rather than buried in the footnotes.
Material and access
Read access to the repository, existing documentation, field and analytics data, third-party proposals under consideration. Whatever is missing, we record as a named assumption instead of inventing it.
Analysis
We read, measure and calculate without tying up your team. Questions get collected and asked in one batch – not drip-fed across two weeks.
Report
A document, not a deck: recommendation, reasoning, alternatives, findings sorted by impact and effort, open decisions with a proposal. Written so that somebody who was not in the room can still read it.
Walkthrough and close
A 60 to 90 minute session with the people who decide. After that the module is finished. Whether we build anything afterwards is a new and deliberately separate question.
Unsure about the stack?
We will tell you when another tool fits your project better.
How long a module takes – and what moves the range.
We commit to time, not to prices. These durations refer to the consulting module, not to a project: whatever gets built afterwards is planned separately.
| Module | Typical duration | What moves the range |
|---|---|---|
| Framework decision review | 3 to 5 working days, spread over one to two weeks | How many stakeholders have to be heard. Whether a requirements document already exists. Whether third-party proposals are being assessed too. Whether the operating context – hosting, data protection, procurement – is already settled. |
| Architecture and content model review | 1 to 2 weeks, starting with one workshop day | The number of real page types. Multiple languages. Whether the CMS decision is open or already made. Whether legacy content is being carried over, and what state it is in. |
| Astro code review | 3 to 8 working days | Size and age of the repository. Whether tests and CI exist. How many integrations and custom extensions are in play. How quickly we get read access – that is more often the bottleneck than the code. |
| Team enablement | 2 workshop days, optionally one accompanied day per week over four to six weeks | The team's prior experience with component frameworks and Git. Team size. Whether production work runs in parallel. Whether the group works in English or German. |
| All four modules in sequence | 4 to 8 weeks of calendar time, not full time | Mostly your decision speed. The analysis rarely takes as long as scheduling the group that is supposed to hear the result. |
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
The question almost no architecture review asks.
A content model is usually checked for whether humans can work with it. We additionally check whether machines are allowed to – because that unlocks a way of editing most teams underestimate.
What this is about
vincubate does not only build with Astro; we put a modern AI stack on top. Concretely: your website can be edited by chat, usually through a Telegram bot. Change a sentence, publish a blog post, swap an image, correct a price – as a message, not as a CMS session. What that looks like day to day is covered on edit your website by chat.
Why it hinges on Astro – and therefore on this review
Because it only works when the content model is typed and schema-validated. Content collections define a schema per content type, validated with Zod and typed automatically in TypeScript. An agent can write into that in a structured way, because the schema defines what is valid – and it can only fill fields that exist, in formats that validate. A faulty edit fails the build, not the live site. Every change runs as a reviewable commit with history, review and rollback. If the content lives in a headless CMS, the same flow runs through its API instead.
That is why the question belongs in an architecture review rather than in the operations phase: whether a schema is machine-addressable is decided when it is designed. So we check it either way – even if you never switch the chat channel on. A model an agent can fill cleanly is the clearer model for humans too.
Who this is relevant for
Both ends of the size range, and that is not a marketing line. Enterprises with an editorial team use the chat channel for the many tiny corrections that otherwise clog the approval process built for campaigns. Sole traders, trades businesses and clinics use it because they will never open a CMS. If you can send a voice message, you can maintain your website.
The limits, so this does not turn into marketing talk
The chat route does not replace an editorial system with multi-stage approvals; it complements one. Editorial responsibility stays with you – an agent proposes and writes, it does not decide. Structural changes such as new page types, layout or navigation remain development work. And the scope is set per project: which collections, which fields, which approval stage. What we can evidence is the experience with chat agents itself: we built a WhatsApp AI agent for our own sales and ran it in real customer conversations, with escalation to a human and with monitoring. We name no user numbers, no product name and no price for this capability, because there would be nothing solid to report.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
When consulting is the right format – and when it is not.
The filter we apply in the first call. The right-hand column costs us work regularly and stays on the page anyway, because consulting sold into the wrong situation is more expensive than consulting declined.
Consulting fits when …
There is a decision that is hard to reverse – and nobody in-house who can evidence it independently.
- You are facing a decision that gets expensive later: framework, content model, CMS boundary, rendering strategy.
- You have an in-house engineering team that will do the building and needs a solid basis rather than one more opinion in the room.
- You have to evaluate a proposal whose effort estimates and architecture you cannot judge on the merits.
- You have inherited somebody else's Astro codebase and want to know what is coming before the first significant change.
- Your team comes from React, Vue or WordPress and the conventions have not been agreed yet.
- You need a written basis that still holds when the group who commissioned it is no longer the same set of people.
Something else fits better when …
Then we say so in the first call and point you onwards – including to places where we earn nothing.
- You want to have it built rather than reviewed. Then go straight to Astro web development or migration to Astro.
- The decision has already been made internally and a review is meant to underwrite it. That is not a review, that is a signature – and we are too expensive for one.
- The problem does not sit in the framework but in ownership, deadlines and vendor management. Then IT project management is the right format.
- Your marketing team should build pages visually themselves. Then Webflow is the more honest answer and the Astro question resolves itself.
- You expect a seal of approval for your site. We issue none, and we assess code, architecture and effort rather than people.
- No budget and no capacity are planned for implementing the results. A report nobody acts on is the most expensive form of paper.
Unsure about the stack?
We will tell you when another tool fits your project better.
Where this consulting is the wrong answer.
Five cases in which we decline or redirect – plus a sixth paragraph on why no price appears on this page.
When what is wanted is confirmation, not examination
It happens that a decision has been made internally and an external document is only meant to carry it. That is humanly understandable and still the wrong brief: we would either reach the desired conclusion and be worthless, or the opposite one and be ignored. When we get that impression, we raise it in the first call. Sometimes it turns out the decision is more open than it sounded in the room – then we keep talking.
When the report is meant as ammunition
We write findings about code, not verdicts about people or vendors. If a review is mainly supposed to prove that somebody else did poor work, we are the wrong team. We phrase things so that you can hand the report to your existing vendor without the relationship breaking over it – in most cases that is the most sensible next step. For disputes headed for court you need a court-appointed expert. We are not that, and we do not pretend to be.
When the problem is not technical at all
A substantial share of the projects that reach us as a technology question are really a governance problem: unclear requirements, a vendor with no counterpart on the client side, decisions nobody makes. Changing framework repairs none of that. In those cases we recommend external IT project management instead of an Astro review – and we say it before a consulting contract exists, not afterwards.
When the deadline is already pressing
Two weeks before a fixed launch date, an architecture review is not a contribution but a burden. The honest recommendation then is: build, launch, and run the assessment six to eight weeks later – with real field data from your own users instead of assumptions. A code review after launch is more informative than one taken halfway anyway.
When nobody can act on the results
A review creates work. If neither capacity nor budget is planned for it, and no decision is pending on who would implement it, the outcome is a document that helps nobody. So we ask about it in the first call. If the answer is open, we suggest starting with the framework decision review – it is the one module whose result has value even without implementation capacity.
What it costs – and why there is no number here
Because the shape varies too much for a single number on this page to be honest. What drives the effort can be named, though: how many modules, and whether they run individually or in sequence; the size and age of the codebase; the number of real page types and languages; how many people have to be heard in the decision; whether workshops happen on site; whether we accompany the implementation afterwards; and how quickly access and documents are available. After the first call you receive a transparent estimate with its assumptions stated. What a subsequent build costs, and what the range is made of, is broken down on Astro development cost.
A decision nobody can evidence independently?
Describe in three sentences where you stand: before the decision, mid-project, or with an inherited codebase. You get an honest read on which module fits – and whether any of them is necessary.
Astro consulting at a glance.
The short answers to the questions that come up in the first call anyway – including our own take in the final row.
| Question | Short answer |
|---|---|
| Who is this for? | In-house engineering teams, technical leads and managing directors facing a platform decision – plus agencies who need a second opinion without handing over the account. |
| What can be booked? | Four modules, individually or in sequence: framework decision review, architecture and content model review, Astro code review, team enablement. |
| How long does it take? | Three working days to two weeks per module; all four in sequence, four to eight weeks of calendar time. The variables sit in the duration table above. |
| What exists at the end? | One document per module plus a walkthrough: recommendation, reasoning, alternatives, findings by impact and effort. Usable even if you continue with somebody else. |
| Do you build afterwards too? | On request, but it is neither a condition nor part of the module. The consulting is deliberately shaped so another team can work from it. |
| Can the answer be "not Astro"? | Yes, and that is a regular outcome. We also build in Webflow and we build custom software; our revenue does not hinge on the result of this review. |
| What does it cost? | Prices are not on this page because the shape varies too much. The cost drivers are written out above; after the first call you get a transparent estimate with its assumptions stated. |
| Our take | The most expensive mistake in an Astro project is rarely the code – it is the content model. If you can only book one module, take the architecture and content model review, and take it before the first component is written. A code review afterwards finds symptoms; a model review beforehand prevents the cause. And if you have to choose between reviewing and building while a deadline presses: build. Consulting nobody acts on is an expensive document. |
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
Astro consulting: frequently asked questions.
First the questions that get asked in decision meetings. Then the short reference ones.
We already have an agency proposing Astro. What does a second opinion add?
The agency that builds is rarely the right body to answer whether it should be built. We test the proposal against what you actually need: does the proposed architecture match your page types and your editorial routine, are the effort estimates plausible, what running costs appear later, which assumptions were left unspoken? You get a list of concrete follow-up questions you can ask yourself. Often the outcome is that the proposal is sound – and then you have that in writing.
Can you really recommend against Astro while running an Astro page?
Yes, and that is not a courtesy. We also build in Webflow and we build custom software; our revenue does not depend on the answer being Astro. Concretely we advise against it when your project is a logged-in application, when your marketing team wants to assemble pages visually, or when nobody in-house wants to work with Git and deployments. A recommendation against Astro closes the module normally – you are paying for the examination, not for the outcome.
We have an in-house team. Will you end up taking the project off us?
No. The work is shaped so your team continues with it: the report contains decisions with their reasoning, not just conclusions, and the conventions live as a document in your repository. Whether we build anything afterwards is a separate question and not a condition. In team enablement the stated goal is that you stop needing us after a few weeks – the same standard we hold in IT project management.
Our Astro project is a year old. What would a code review find that our team does not see?
Mostly what every mature project accumulates: components that got client:load where client:visible would have done. Routes rendering on demand that could be prerendered. A schema that has gone soft over the months. Images bypassing the built-in processing because they sit in the public directory. Your team does not see it because they look at it every day. We see it because we are seeing it for the first time – that is the whole trick.
We have to decide within two weeks. Is that possible?
For the framework decision review, usually yes: three to five working days is the norm, spread over one to two weeks. The bottleneck is rarely our analysis but the slot where everyone who decides is available at once. A complete architecture and content model review inside two weeks is possible if the page types are already named. If they are not, we say so – and would rather deliver a solid partial answer than a fast complete one.
Who sees our code, and what happens to it afterwards?
The same person you speak to in the first call does the work. We need read access to the repository, no production access and no customer data. Working copies are deleted on completion; excerpts in the report are limited to what evidences a finding. We sign a confidentiality agreement upfront – yours if you have one, ours if you do not. Your code appears in no reference material, not even anonymised.
Our team knows React but not Astro. How long until we are productive?
For a team with component experience the syntax is not the problem, the adjustment is. Astro strips all client-side JavaScript by default, and interactivity is requested per component through a directive. People arriving from React hydrate too much at first. Two workshop days plus four to six accompanied weeks is the frame in which that reflex resets. You can keep your React components: Astro mounts them as islands.
What happens if your review finds mistakes our current vendor made?
Then they appear in the report – as a finding with location, impact and effort, not as a verdict on a company. We phrase it so you can pass the report on without the working relationship breaking over it; in most cases that is the most sensible next step. What we do not produce are reports intended as evidence in a dispute. For that you need a court-appointed expert, not us.
We are mid-project. Is it too late for an architecture review?
It is never too late, but it gets more expensive every week because more is built on top of the model. If the first page types exist and the schema is still young, changes can be absorbed in days. Once editors, redirects and translations depend on it, the same change becomes a rebuild. Which of the two situations you are in, we tell you in the first call – free, and in half an hour.
What does the consulting cost, and why is there no price on the page?
Because the shape varies too much: a decision review for one team is a different thing from a code review across a mature repository with custom extensions. The cost drivers are written out on this page – number of modules, size and age of the codebase, count of page types and languages, people involved in the decision, workshops on site. After the first call you receive a transparent estimate with its assumptions visible, not a ballpark.
What happens if you become unavailable?
That is exactly why the result is written and sits with you rather than in our heads: report, reasoning, open decisions, conventions in the repository. A module already under way can be continued by another team without starting over. For ongoing accompaniment we agree a cover arrangement and keep the state documented, instead of making ourselves indispensable. Same principle as in IT project management: becoming unnecessary on schedule.
Does a niche framework make it harder to hire developers?
A fair question, and it belongs in the decision review. Two things ease it: Astro is UI-framework-agnostic – React, Preact, Vue, Svelte, Solid and Alpine components run inside it, so existing knowledge stays usable. And most of an Astro codebase is HTML, CSS and TypeScript rather than framework-specific knowledge. Still: if your hiring market is tight and nobody on the team wants something new, that is an argument against Astro. Then we write it down exactly like that.
We have not seen an Astro reference from you. Why should we ask you?
Because there is none we are allowed to show. Astro is part of our stack; a public client reference for it does not exist yet, and we do not pretend otherwise. What you can examine instead is the method: our Webflow work, our own products, and the structure of the reports these modules produce. For an advisory engagement that is the better test anyway – ask for a sample outline in the first call and decide from that.
Do we need to give you access to production systems?
No. Read access to the repository is enough, plus build logs, configuration without secrets and field data from your analytics environment where those exist. Access to production servers, editor accounts or customer data is neither needed nor wanted. If something is missing, we continue on a named assumption and mark it as such in the report rather than setting it silently.
What is an Astro code review?
A structured read of an existing Astro codebase: hydration, rendering strategy, content schema, image handling, dependencies and build. The output is a findings list sorted by impact and effort – including the items you should deliberately leave alone.
Is Astro free?
Yes. Astro is open source under the MIT license. Costs come from development, hosting and operations, not from licensing. What the overall range is made of is broken down on Astro development cost.
What are content collections?
A set of structurally identical content entries with a schema validated through Zod, which also produces TypeScript types automatically. If a required field is missing, the build breaks instead of the live site. Covered in detail on Astro CMS.
How long does an architecture review take?
One to two weeks, starting with a workshop day. It runs longer with many page types, several languages, or while the CMS decision is still open. The full picture sits in the duration table further up this page.
Does an Astro site need a server?
Not necessarily. By default the entire site is prerendered and served as static HTML, which runs on any static host or CDN. Only when individual routes should render at request time does an adapter for the target runtime come into play.
Do you consult remotely?
Yes, by default. Analysis and reports run remotely anyway; workshops and walkthroughs can happen on site across the German-speaking region. We work in English or German – the markets and time zones we cover are listed on markets.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
More from the Astro cluster.
The pages these modules lean on most often:
An independent answer, before it gets expensive.
Briefly describe the project, the current state and the decision ahead. You get an honest read on which module fits – and a straight no if none is needed. Usually within 24 hours.
Request Astro consulting.
Tell us briefly what it is about: a decision, an architecture, an existing codebase or team enablement. We come back with an assessment of module, duration and the access required.
We usually reply within 24 hours.
Remote & on site – working across the DACH region (DE, AT, CH), with international project experience.
Related services.
IT Project Management
When the problem is not the framework but governance, vendors and decisions nobody makes.
Learn moreWebflow Agency
When your marketing team would rather build pages visually than work with a repository and deployments.
Learn moreCustom Software Development
When the website should become an application with logins, roles and business logic.
Learn more