Start
Astro Agentur
Astro Beratung

Beratung · Architektur · Code Review · Enablement

Astro Beratung – unabhängig, auch wenn die Antwort Nein lautet.

Nicht jedes Team, das über Astro nachdenkt, sucht eine Agentur, die baut. Viele haben eigene Entwicklerinnen und Entwickler und brauchen eine unabhängige Antwort auf vier Fragen: Passt Astro überhaupt zu diesem Vorhaben? Ist die bestehende Astro-Codebasis gesund? Wie muss das Inhaltsmodell aussehen, bevor die erste Komponente geschrieben wird? Und wie wird das eigene Team damit produktiv? Genau dafür gibt es diese vier Module – einzeln buchbar, schriftlich abgeschlossen, ergebnisoffen. Wir arbeiten dabei auf Ihrer Seite, so wie wir es in der IT-Projektleitung ohnehin tun.

Beratung anfragen Die vier Module

Ergebnisoffen

Wir sind nicht darauf angewiesen, dass Astro gewinnt: Wir bauen auch mit Webflow und wir bauen Individualsoftware. Eine Empfehlung gegen Astro ist ein regulärer Ausgang dieser Beratung, kein Scheitern.

Schriftlich statt mündlich

Jedes Modul endet mit einem Dokument, das ohne uns weiterverwendbar ist: Empfehlung, Begründung, Alternativen, Risiken – und die Aufwände, die daran hängen.

Kurz und befristet

Beratung ist hier kein Dauerauftrag. Die Module dauern Tage bis wenige Wochen und enden mit einer Entscheidung, nicht mit dem nächsten Termin.

01 — Kurz gesagt

Astro Beratung: das Wichtigste in sechs Punkten.

Kurz gesagt

Was das ist: unabhängige Beratung rund um Astro – für Teams, die selbst bauen oder noch entscheiden. Vier Module, einzeln buchbar: Framework-Entscheidung, Architektur- und Content-Modell-Review, Astro Code Review, Team-Enablement.
Für wen: interne Entwicklungsteams, technische Leitungen, Geschäftsführungen vor einer Plattformentscheidung – und Agenturen, die eine zweite Meinung brauchen, ohne den Auftrag abzugeben.
Warum unabhängig: Wir bauen auch mit Webflow und wir bauen Individualsoftware. Wir verdienen nichts daran, dass die Antwort am Ende „Astro“ heißt.
Was Sie bekommen: pro Modul ein schriftliches Ergebnis – Empfehlung, Begründung, benannte Alternativen, eine nach Wirkung und Aufwand sortierte Befundliste und eine Durchsprache mit den Menschen, die entscheiden.
Wie lange: Tage bis wenige Wochen pro Modul. Die Spannen und die Variablen, die sie bewegen, stehen weiter unten in einer eigenen Tabelle.
Wann Sie das nicht brauchen: wenn die Entscheidung intern längst gefallen ist und nur noch abgesichert werden soll. Dafür ist ein Review das falsche Werkzeug – und wir sagen das lieber vorher als hinterher.

02 — Ausgangslage

Sechs Lagen, aus denen heraus Teams hier anrufen.

Keine davon ist ein Notfall. Alle sechs werden teuer, wenn man sie aussitzt – weil die Entscheidung, um die es geht, mit jeder Woche schwerer zu drehen ist.

Die Entscheidung im Vakuum

Zwei Entwickler wollen Astro, der Rest des Teams kennt nur React, und niemand kann sagen, was in zwei Jahren aus dieser Entscheidung folgt. Die Diskussion dreht sich, weil es keine unabhängige Grundlage gibt – nur Präferenzen mit unterschiedlicher Lautstärke.

Das Angebot, das Sie nicht bewerten können

Eine Agentur hat Astro vorgeschlagen. Das Angebot liest sich plausibel, aber im Haus kann niemand Aufwände, Architektur und spätere Betriebskosten fachlich einordnen. Sie unterschreiben also Vertrauen, nicht Inhalt.

Das Inhaltsmodell, das zu früh feststand

Das Projekt läuft, die ersten Seitentypen stehen – und jetzt zeigt sich, dass das Schema die dritte Sprache nie vorgesehen hat. Jede Korrektur betrifft Templates, CMS, Redaktion und Weiterleitungen gleichzeitig.

Die geerbte Codebasis

Sie haben eine Astro-Website übernommen, die jemand anders gebaut hat. Sie läuft. Ob sie gesund ist, weiß niemand – und die erste größere Änderung wird zeigen, was sich hinter der Oberfläche angesammelt hat.

Das Team, das nach dem Launch alleine dasteht

Die Website ist live, das externe Team ist weg, Ihre Entwickler sollen weiterbauen. Ohne verabredete Konventionen entstehen in drei Monaten drei verschiedene Astro-Dialekte im selben Repository.

Der Verdacht, dass es nicht am Framework liegt

Die Seite ist langsam, die Pflege dauert, das Projekt hakt. Manchmal ist das eine Architekturfrage. Oft ist es eine Frage von Zuständigkeiten und Abläufen – und dann ändert ein Technologiewechsel gar nichts.

03 — Module

Vier Module. Einzeln buchbar.

Jedes Modul beantwortet genau eine Frage und endet mit einem Dokument. Sie können bei Modul eins anfangen – oder direkt dort einsteigen, wo Ihr Projekt gerade steht.

1 — Framework-Entscheidungs-Review

Die unabhängige Antwort auf die Frage, ob Astro für dieses Vorhaben die richtige Grundlage ist. Mit schriftlicher Empfehlung, mindestens einer benannten Alternative und den Risiken beider Wege. Die Empfehlung kann „nicht Astro“ lauten.

Astro vs. Next.js

2 — Architektur- und Content-Modell-Review

Wie Seitentypen, Content Collections, die CMS-Grenze und die Rendering-Strategie geschnitten sein müssen, bevor Code entsteht. Das ist die Entscheidung, die später am teuersten zu drehen ist.

Astro CMS & Content Collections

3 — Astro Code Review

Durchsicht einer bestehenden Codebasis: Hydratisierung, Rendering, Schema-Disziplin, Bilder, Abhängigkeiten, Build. Befunde priorisiert nach Wirkung und Aufwand – inklusive der Punkte, die man bewusst so lassen sollte.

Performance-Optimierung

4 — Team-Enablement

Ihr internes Team wird in Astro produktiv: Konventionen, die vorab verabredet gehören, zwei Workshop-Tage und begleitete Wochen mit Pairing und Reviews. Ziel ist, dass Sie uns danach nicht mehr brauchen.

Astro Website-Entwicklung

04 — Im Detail

Was in jedem Modul tatsächlich passiert.

Beratung ist ein Wort, unter dem sich alles verstecken lässt. Deshalb hier ausgeschrieben, was wir ansehen, wie wir es bewerten und was am Ende auf dem Tisch liegt.

Modul 1 – Framework-Entscheidungs-Review

Die Frage lautet nicht „Ist Astro gut?“, sondern „Ist Astro für dieses Vorhaben, dieses Team und diesen Betriebsrahmen die richtige Grundlage?“. Das sind zwei völlig verschiedene Fragen, und nur die zweite lässt sich beantworten. Wir sehen uns an, was die Website tatsächlich tun soll: Inhalte ausliefern oder eine eingeloggte Anwendung sein. Wie viele echte Seitentypen es gibt – nicht wie viele Seiten. Woher die Inhalte kommen und wer sie im Alltag pflegt. Welche Integrationen unverhandelbar sind. Wo gehostet wird und wer den Betrieb verantwortet. Welche Kompetenzen im Team vorhanden sind und welche man einkaufen müsste. Und wie lange die Entscheidung halten muss, bevor sie ohnehin wieder aufgemacht wird.

Am Ende steht eine schriftliche Empfehlung mit Begründung, mindestens einer benannten Alternative, den Risiken beider Wege und einer Aufwandsspanne. Wenn die Antwort „nicht Astro“ lautet, steht sie in derselben Deutlichkeit auf der ersten Seite wie eine Zustimmung. Für die häufigste Gegenüberstellung haben wir die Argumente bereits offengelegt: Astro vs. Next.js, Astro vs. WordPress und Astro vs. Webflow. Wer zuerst die Grundlagen braucht, findet sie unter Was ist Astro?.

Modul 2 – Architektur- und Content-Modell-Review

Das ist das Modul, für das wir am ehesten werben würden, wenn wir nur eines empfehlen dürften. Der teuerste Fehler in einem Astro-Projekt ist selten der Code – es ist das Inhaltsmodell. Ein Schema, das eine Woche nach Projektstart um zwei Felder daneben liegt, kostet Stunden. Dasselbe Schema, korrigiert nach dem Launch, kostet Templates, Redaktionsschulung, Datenmigration und Weiterleitungen gleichzeitig.

Wir schneiden deshalb vorab: Welche Seitentypen gibt es wirklich, welche Felder gehören zu jedem, und welche davon sind Pflicht? Wo verläuft die Grenze zwischen Repository und CMS – was liegt als Markdown in Content Collections mit Zod-Schema, was gehört in ein Headless CMS mit Redaktionsoberfläche und Rechten? Welche Routen werden vorgerendert und welche brauchen wirklich Rendering zur Laufzeit, mit welchem Adapter und zu welchen Betriebskosten? Welche Komponenten dürfen überhaupt eine client-Direktive bekommen, und mit welcher Ladepriorität? Wie sehen URL-Struktur, Mehrsprachigkeit und Navigation aus, bevor Inhalte daran hängen?

Ergebnis ist eine Seitentyp-Matrix, ein Schema-Entwurf, eine Rendering-Entscheidung je Route und eine Liste der noch offenen Entscheidungen – jede davon mit unserem Vorschlag und der Begründung daneben. Wer daraus baut, ist eine getrennte Frage.

Modul 3 – Astro Code Review einer bestehenden Codebasis

Hier lesen wir, was schon existiert. Zwölf Dinge stehen dabei regelmäßig auf der Liste: die Hydratisierungsstrategie und ob client:load dort steht, wo client:visible gereicht hätte; die Verteilung zwischen vorgerenderten und zur Laufzeit gerenderten Routen samt Adapter-Wahl; die Disziplin im Content-Schema und ob es über die Monate weich geworden ist; die Bildverarbeitung und ob Bilder an der eingebauten Optimierung vorbeilaufen, weil sie in public liegen; der Komponentenschnitt und die Frage, ob Layouts und Komponenten noch unterscheidbar sind; TypeScript-Strenge und ob astro check und der Build in der Continuous Integration laufen oder nur auf einem Rechner; der Stand der Abhängigkeiten und der Abstand zur aktuellen Major-Linie; Build-Zeiten und was sie treibt; Routing und Weiterleitungen; semantisches Markup und Barrierefreiheit; Metadaten und strukturierte Daten; der Umgang mit Geheimnissen und Umgebungsvariablen.

Jede Feststellung bekommt zwei Werte: Wirkung und Aufwand. Daraus entstehen vier Körbe – sofort erledigen, im nächsten Sprint erledigen, als Umbau planen, und bewusst so lassen. Der vierte Korb ist uns wichtig: Nicht alles, was auffällt, muss angefasst werden, und ein Review, das nur Arbeit erzeugt, hat seinen Zweck verfehlt. Sie bekommen die Befundliste mit Fundstellen und eine Durchsprache mit dem Team. Wenn daraus Umsetzung wird, steht der Weg unter Performance-Optimierung und Support und Wartung – auch für Projekte, die jemand anders gebaut hat.

Modul 4 – Team-Enablement

Ein Team wird nicht dadurch produktiv, dass es die Syntax kennt. Es wird produktiv, wenn die Konventionen verabredet sind, bevor drei Leute drei Antworten auf dieselbe Frage erfinden. Wir setzen deshalb genau diese Verabredungen an den Anfang: Wann wird eine .astro-Komponente geschrieben und wann eine Framework-Komponente? Voreinstellung ist keine client-Direktive – jede einzelne braucht eine dokumentierte Begründung. Wem gehört das Content-Schema, und wer darf es ändern? Wie sehen Verzeichnisstruktur und Benennungen aus? Was gehört in ein Layout, was in eine Komponente? Was steht in der Definition of Done, und laufen astro check und Build als Gate in der CI? Wie werden Bilder eingebunden? Und wann werden Major-Upgrades eingeplant, damit sie kleine Aufgaben bleiben statt Projekte zu werden?

Das Format sind zwei Workshop-Tage – einer an Grundlagen, einer am eigenen Projekt – und danach optional vier bis sechs begleitete Wochen mit Pairing und Code-Reviews. Die Konventionen landen als Dokument im Repository, nicht in einem Foliensatz. Wenn Ihr Team aus React, Vue oder WordPress kommt, ist die eigentliche Umgewöhnung nicht die Sprache, sondern der Reflex: In Astro ist der Normalfall, dass nichts hydratisiert wird.

Was wir mitbringen

Wir kommen aus der Software-Entwicklung und aus der IT-Projektleitung. Beides zusammen ist der Grund, warum ein Review hier nicht bei „so würden wir es machen“ endet, sondern bei Aufwand, Reihenfolge und Risiko.

Was wir nicht mitbringen

Keine öffentliche Astro-Kundenreferenz. Astro gehört zu unserem Stack, aber einen Fall, den wir zeigen dürfen, haben wir bisher nicht – und wir tun nicht so als ob. Prüfbar ist die Arbeitsweise: unsere Webflow-Arbeit und die eigenen Produkte.

Zugänge

Für ein Code Review brauchen wir Lesezugriff auf das Repository und, wenn vorhanden, Build-Logs und Felddaten. Produktivzugänge, Redaktionskonten und Kundendaten brauchen wir nicht.

Sprachen und Orte

Deutsch und Englisch. Sichtung und Berichte remote, Workshops und Durchsprachen auch vor Ort im DACH-Raum. Details unter Märkte und Zusammenarbeit.

05 — Ablauf

So läuft ein Beratungsmodul.

Sechs Schritte, gleich für alle vier Module. Nach Schritt eins wissen Sie, ob Sie überhaupt eines davon brauchen.

Erstgespräch

30 bis 45 Minuten. Sie schildern Vorhaben, Stand und Engpass. Wir sagen, welches Modul passt – und ob eines davon nötig ist. Diese Einschätzung kostet nichts und ist nicht daran gebunden, dass daraus ein Auftrag wird.

Zuschnitt und Angebot

Ein Angebot mit Modul, Umfang, Dauer, benötigten Zugängen und dem, was am Ende vorliegt. Nachvollziehbar kalkuliert, mit den Annahmen sichtbar daneben statt im Kleingedruckten.

Material und Zugänge

Lesezugriff auf das Repository, vorhandene Dokumentation, Feld- und Analysedaten, laufende Angebote Dritter. Was fehlt, halten wir als benannte Annahme fest, statt es zu erfinden.

Sichtung

Wir lesen, messen und rechnen, ohne Ihr Team dabei zu binden. Rückfragen sammeln wir und stellen sie gebündelt – nicht tröpfchenweise über zwei Wochen verteilt.

Bericht

Ein Dokument, keine Folien: Empfehlung, Begründung, Alternativen, Befunde nach Wirkung und Aufwand sortiert, offene Entscheidungen mit Vorschlag. Geschrieben so, dass es auch jemand liest, der nicht dabei war.

Durchsprache und Abschluss

Eine Runde von 60 bis 90 Minuten mit den Menschen, die entscheiden. Danach ist das Modul beendet. Ob wir anschließend bauen, ist eine neue und ausdrücklich getrennte Frage.

06 — Dauer

Wie lange ein Modul dauert – und was die Spanne bewegt.

Zeit sagen wir zu, Preise nicht. Die Dauer bezieht sich auf das Beratungsmodul, nicht auf ein Projekt: Was danach gebaut wird, ist eine getrennte Planung.

Modul	Typische Dauer	Was die Spanne bewegt
Framework-Entscheidungs-Review	3 bis 5 Arbeitstage, verteilt über ein bis zwei Wochen	Wie viele Beteiligte gehört werden müssen. Ob bereits ein Lastenheft existiert. Ob Angebote Dritter mitbewertet werden sollen. Ob der Betriebsrahmen – Hosting, Datenschutz, Einkauf – schon feststeht.
Architektur- und Content-Modell-Review	1 bis 2 Wochen, beginnend mit einem Workshop-Tag	Anzahl echter Seitentypen. Mehrsprachigkeit. Ob die CMS-Entscheidung offen oder gesetzt ist. Ob Altinhalte übernommen werden und in welchem Zustand sie sind.
Astro Code Review	3 bis 8 Arbeitstage	Größe und Alter des Repositories. Ob Tests und eine CI existieren. Wie viele Integrationen und eigene Erweiterungen im Spiel sind. Wie schnell wir Lesezugriff bekommen – das ist häufiger der Engpass als der Code.
Team-Enablement	2 Workshop-Tage, optional ein begleiteter Tag pro Woche über vier bis sechs Wochen	Vorerfahrung des Teams mit Komponenten-Frameworks und Git. Teamgröße. Ob parallel bereits produktiv gebaut wird. Ob die Runde auf Deutsch oder Englisch arbeitet.
Alle vier Module nacheinander	4 bis 8 Wochen Kalenderzeit, nicht Vollzeit	Vor allem Ihre Entscheidungsgeschwindigkeit. Die Sichtung dauert selten so lange wie das Terminieren der Runde, die das Ergebnis hören soll.

07 — KI-Stack

Die Frage, die in kaum einem Architektur-Review vorkommt.

Ein Inhaltsmodell wird üblicherweise darauf geprüft, ob Menschen damit arbeiten können. Wir prüfen zusätzlich, ob Maschinen es dürfen – weil daraus eine Pflegeform entsteht, die die meisten Teams unterschätzen.

Worum es geht

vincubate baut nicht nur mit Astro, sondern setzt einen modernen KI-Stack obendrauf: Die Website lässt sich im Chat bearbeiten, in der Regel über einen Telegram-Bot. Text ändern, einen Blogbeitrag anlegen, ein Bild tauschen, einen Preis korrigieren – als Nachricht, nicht als CMS-Sitzung. Wie das im Alltag aussieht, steht ausführlich unter Website per Chat pflegen.

Warum das an Astro hängt – und damit an diesem Review

Weil es nur funktioniert, wenn das Inhaltsmodell typisiert und schema-validiert ist. Content Collections beschreiben pro Inhaltstyp ein Schema, das über Zod validiert wird und automatisch TypeScript-Typen liefert. Ein Agent kann darin strukturiert schreiben, weil das Schema definiert, was gültig ist – und er kann nur Felder füllen, die es gibt, in Formaten, die validieren. Ein fehlerhafter Eingriff scheitert im Build, nicht auf der Live-Seite. Jede Änderung läuft als nachvollziehbarer Commit mit Historie, Review-Möglichkeit und Rollback. Liegt der Inhalt in einem Headless CMS, läuft derselbe Ablauf über dessen API.

Deshalb gehört die Frage in ein Architektur-Review und nicht in die Betriebsphase: Ob ein Schema maschinell adressierbar ist, entscheidet sich beim Entwurf. Wir prüfen sie also mit – auch dann, wenn Sie den Chat-Kanal nie einschalten. Ein Modell, das ein Agent sauber befüllen kann, ist auch für Menschen das klarere Modell.

Für wen das relevant ist

Für beide Enden der Größenskala, und das ist kein Marketing-Satz. Konzerne mit Redaktionsteam nutzen den Chat-Kanal für die vielen Kleinstkorrekturen, die sonst den Freigabeprozess verstopfen, der eigentlich für Kampagnen gedacht ist. Einzelunternehmerinnen, Handwerksbetriebe und Praxen nutzen ihn, weil sie nie ein CMS öffnen werden. Wer eine Sprachnachricht schicken kann, kann seine Website pflegen.

Die Grenzen, damit daraus kein Marketing-Sprech wird

Der Chat-Weg ersetzt kein Redaktionssystem mit mehrstufigen Freigaben, er ergänzt es. Die redaktionelle Verantwortung bleibt bei Ihnen – ein Agent schlägt vor und schreibt, er entscheidet nicht. Strukturelle Änderungen wie neue Seitentypen, Layout oder Navigation bleiben Entwicklungsarbeit. Und der Umfang wird pro Projekt festgelegt: welche Collections, welche Felder, welche Freigabestufe. Belegen können wir dabei die Erfahrung mit Chat-Agenten selbst: Wir haben einen WhatsApp-KI-Agenten für den eigenen Vertrieb gebaut und im echten Kundenkontakt betrieben, mit Eskalation an einen Menschen und mit Monitoring. Nutzerzahlen, Produktnamen oder Preise für diese Funktion nennen wir nicht, weil es dazu nichts Belastbares zu berichten gäbe.

08 — Passt / passt nicht

Wann Beratung das richtige Format ist – und wann nicht.

Der Filter, den wir im Erstgespräch anlegen. Die rechte Spalte kostet uns regelmäßig Aufträge und steht trotzdem hier, weil eine falsch verkaufte Beratung teurer ist als eine abgesagte.

Beratung passt, wenn …

Es gibt eine Entscheidung, die schwer zu drehen ist – und niemanden im Haus, der sie unabhängig belegen kann.

Sie vor einer Entscheidung stehen, die später teuer wird: Framework, Inhaltsmodell, CMS-Grenze, Rendering-Strategie.
Sie ein eigenes Entwicklungsteam haben, das bauen soll, und eine belastbare Grundlage brauchen statt einer weiteren Meinung im Raum.
Sie ein Angebot bewerten müssen, dessen Aufwände und Architektur Sie fachlich nicht einordnen können.
Sie eine fremde Astro-Codebasis geerbt haben und wissen wollen, was darin auf Sie zukommt, bevor die erste große Änderung ansteht.
Ihr Team von React, Vue oder WordPress kommt und die Konventionen noch nicht verabredet sind.
Sie eine schriftliche Grundlage brauchen, die auch dann noch trägt, wenn die Runde, die sie bestellt hat, personell nicht mehr dieselbe ist.

Etwas anderes passt besser, wenn …

Dann sagen wir das im Erstgespräch und leiten weiter – auch dorthin, wo wir nichts verdienen.

Sie bauen lassen wollen statt zu prüfen. Dann direkt Astro Website-Entwicklung oder Migration zu Astro.
Die Entscheidung intern längst gefallen ist und ein Review sie nur absichern soll. Das ist kein Review, das ist eine Unterschrift – und dafür sind wir zu teuer.
Das Problem nicht am Framework hängt, sondern an Zuständigkeiten, Terminen und Dienstleistersteuerung. Dann ist IT-Projektleitung das passende Format.
Ihr Marketing die Seiten selbst visuell bauen soll. Dann ist Webflow die ehrlichere Antwort, und die Astro-Frage erledigt sich von allein.
Sie ein Prüfsiegel für Ihre Website erwarten. Wir stellen keines aus und bewerten keine Personen, sondern Code, Architektur und Aufwand.
Kein Budget und keine Kapazität für die Umsetzung eingeplant sind. Ein Bericht, den niemand umsetzt, ist die teuerste Form von Papier.

09 — Ehrliche Grenzen

Wo diese Beratung die falsche Antwort ist.

Fünf Fälle, in denen wir absagen oder umleiten – und ein sechster Absatz zu der Frage, warum hier kein Preis steht.

Wenn eine Bestätigung gesucht wird, keine Prüfung

Es kommt vor, dass die Entscheidung intern gefallen ist und ein externes Dokument sie nur noch tragen soll. Das ist menschlich verständlich und trotzdem der falsche Auftrag: Wir kämen entweder zum gewünschten Ergebnis und wären wertlos, oder zum gegenteiligen und würden ignoriert. Wenn wir diesen Eindruck haben, sprechen wir ihn im Erstgespräch an. Manchmal stellt sich heraus, dass die Entscheidung doch offener ist, als sie im Raum klang – dann reden wir weiter.

Wenn der Bericht als Munition gedacht ist

Wir schreiben Befunde zu Code, nicht Urteile über Personen oder Dienstleister. Wenn ein Review vor allem belegen soll, dass jemand anders schlecht gearbeitet hat, sind wir das falsche Team. Wir formulieren so, dass Sie den Bericht Ihrem bisherigen Dienstleister geben können, ohne dass die Zusammenarbeit daran zerbricht – das ist in den meisten Fällen der sinnvollste nächste Schritt. Für Auseinandersetzungen, die vor Gericht landen, brauchen Sie eine öffentlich bestellte Sachverständige. Das sind wir nicht, und wir geben auch nicht vor, es zu sein.

Wenn das Problem gar nicht technisch ist

Ein erheblicher Teil der Projekte, die als Technologiefrage bei uns ankommen, ist in Wahrheit ein Steuerungsproblem: unklare Anforderungen, ein Dienstleister ohne Gegenüber auf Kundenseite, Entscheidungen, die niemand trifft. Ein Framework-Wechsel repariert davon nichts. In diesen Fällen empfehlen wir externe IT-Projektleitung statt eines Astro-Reviews – und sagen es, bevor ein Beratungsvertrag entsteht, nicht danach.

Wenn der Termin bereits drückt

Zwei Wochen vor einem gesetzten Launch ist ein Architektur-Review kein Beitrag, sondern eine Belastung. Die ehrliche Empfehlung lautet dann: bauen, launchen, und die Bestandsaufnahme sechs bis acht Wochen später fahren – mit echten Felddaten aus Ihrer eigenen Nutzerbasis statt mit Vermutungen. Ein Code Review nach dem Launch ist ohnehin aussagekräftiger als eines auf halber Strecke.

Wenn niemand die Ergebnisse umsetzen kann

Ein Review erzeugt Arbeit. Wenn im Team weder Kapazität noch Budget dafür eingeplant sind und auch keine Entscheidung darüber ansteht, wer die Umsetzung übernimmt, entsteht ein Dokument, das niemandem nützt. Wir fragen deshalb im Erstgespräch danach. Wenn die Antwort offen ist, schlagen wir vor, mit dem Framework-Entscheidungs-Review zu beginnen – das ist das einzige der vier Module, dessen Ergebnis auch ohne Umsetzungskapazität wertvoll ist.

Was das kostet – und warum hier keine Zahl steht

Weil der Zuschnitt zu unterschiedlich ist, als dass eine Zahl auf dieser Seite ehrlich wäre. Was den Aufwand treibt, lässt sich dagegen benennen: die Anzahl der Module und ob sie einzeln oder als Folge laufen; Größe und Alter der Codebasis; die Zahl echter Seitentypen und Sprachen; wie viele Menschen im Entscheidungsprozess gehört werden müssen; ob Workshops vor Ort stattfinden; ob wir die Umsetzung anschließend begleiten sollen; und wie schnell Zugänge und Unterlagen bereitstehen. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit sichtbaren Annahmen. Was eine anschließende Umsetzung kostet und woraus sich der Rahmen zusammensetzt, haben wir unter Astro-Kosten offengelegt.

Eine Entscheidung, die niemand unabhängig belegen kann?

Schildern Sie in drei Sätzen, wo Sie stehen: vor der Entscheidung, mitten im Projekt oder mit einer geerbten Codebasis. Sie bekommen eine ehrliche Einschätzung, welches Modul passt – und ob überhaupt eines nötig ist.

Ersteinschätzung anfordern

10 — Auf einen Blick

Astro Beratung auf einen Blick.

Die kurzen Antworten auf die Fragen, die im Erstgespräch ohnehin kommen – inklusive unserer eigenen Einschätzung in der letzten Zeile.

Frage	Kurze Antwort
Für wen ist das gedacht?	Interne Entwicklungsteams, technische Leitungen und Geschäftsführungen vor einer Plattformentscheidung – dazu Agenturen, die eine zweite Meinung brauchen, ohne den Auftrag abzugeben.
Was ist buchbar?	Vier Module, einzeln oder als Folge: Framework-Entscheidung, Architektur- und Content-Modell-Review, Astro Code Review, Team-Enablement.
Wie lange dauert es?	Drei Arbeitstage bis zwei Wochen pro Modul, alle vier nacheinander vier bis acht Wochen Kalenderzeit. Die Variablen stehen in der Tabelle weiter oben.
Was liegt am Ende vor?	Ein Dokument pro Modul plus eine Durchsprache: Empfehlung, Begründung, Alternativen, Befunde nach Wirkung und Aufwand. Nutzbar auch dann, wenn Sie danach mit jemand anderem weiterarbeiten.
Bauen Sie danach auch?	Auf Wunsch, aber es ist keine Bedingung und kein Bestandteil des Moduls. Die Beratung ist bewusst so geschnitten, dass ein anderes Team damit weiterarbeiten kann.
Kann das Ergebnis „kein Astro“ sein?	Ja, und das ist ein regulärer Ausgang. Wir bauen auch mit Webflow und wir bauen Individualsoftware; unser Umsatz hängt nicht am Ergebnis dieser Prüfung.
Was kostet es?	Preise stehen nicht auf dieser Seite, weil der Zuschnitt zu unterschiedlich ist. Die Kostentreiber sind oben ausgeschrieben; nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit Annahmen.
Unsere Einschätzung	Der teuerste Fehler in einem Astro-Projekt ist selten der Code, sondern das Inhaltsmodell. Wenn Sie nur ein Modul buchen können, nehmen Sie das Architektur- und Content-Modell-Review – und zwar bevor die erste Komponente geschrieben ist. Ein Code Review danach findet Symptome; ein Modell-Review vorher verhindert die Ursache. Und wenn Sie zwischen Beratung und Bauen wählen müssen, während der Termin drückt: lassen Sie bauen. Beratung, die niemand umsetzt, ist ein teures Dokument.

11 — FAQ

Häufige Fragen zur Astro Beratung.

Zuerst die Fragen, die in Entscheidungsrunden gestellt werden. Danach die kurzen Nachschlagefragen.

Wir haben schon eine Agentur, die Astro vorgeschlagen hat. Was bringt uns eine zweite Meinung?

Die Agentur, die baut, ist selten die richtige Instanz für die Frage, ob gebaut werden soll. Wir prüfen das Angebot gegen Ihr tatsächliches Vorhaben: Passt die vorgeschlagene Architektur zu Ihren Seitentypen und Ihrem Redaktionsalltag, sind die Aufwände plausibel, welche Betriebskosten entstehen später, welche Annahmen sind unausgesprochen geblieben? Sie bekommen eine Liste konkreter Rückfragen, die Sie selbst stellen können. Häufig lautet das Ergebnis, dass das Angebot in Ordnung ist – dann haben Sie es schriftlich.

Können Sie wirklich gegen Astro empfehlen, wenn Sie eine Astro-Seite betreiben?

Ja, und das ist keine Höflichkeitsformel. Wir bauen auch mit Webflow und wir bauen Individualsoftware; unser Umsatz hängt nicht daran, dass die Antwort Astro heißt. Konkret raten wir ab, wenn Ihr Vorhaben eine eingeloggte Anwendung ist, wenn Ihr Marketing Seiten selbst visuell zusammensetzen will oder wenn im Haus niemand mit Git und Deployments arbeiten möchte. Eine Empfehlung gegen Astro beendet das Modul regulär – bezahlt wird die Prüfung, nicht das Ergebnis.

Wir haben ein internes Team. Nehmen Sie uns am Ende doch das Projekt weg?

Nein. Die Beratung ist so geschnitten, dass Ihr Team damit weiterarbeitet: Der Bericht enthält Entscheidungen samt Begründung, nicht nur Ergebnisse, und die Konventionen liegen als Dokument in Ihrem Repository. Ob wir anschließend etwas bauen, ist eine getrennte Frage und keine Bedingung. Beim Team-Enablement ist das erklärte Ziel, dass Sie uns nach wenigen Wochen nicht mehr brauchen – derselbe Anspruch, den wir in der IT-Projektleitung haben.

Unser Astro-Projekt läuft seit einem Jahr. Was findet ein Code Review, das unser Team nicht sieht?

Meistens das, was jedes gewachsene Projekt ansammelt: Komponenten, die client:load bekommen haben, obwohl client:visible gereicht hätte. Routen, die zur Laufzeit rendern, obwohl sie vorgerendert werden könnten. Ein Schema, das über Monate weicher geworden ist. Bilder, die an der eingebauten Verarbeitung vorbeilaufen, weil sie im public-Verzeichnis liegen. Ihr Team sieht das nicht, weil es täglich hineinschaut. Wir sehen es, weil wir es zum ersten Mal sehen – das ist der ganze Trick.

Wir müssen in zwei Wochen entscheiden. Geht das so schnell?

Für das Framework-Entscheidungs-Review meistens ja: drei bis fünf Arbeitstage sind der Regelfall, verteilt über ein bis zwei Wochen. Der Engpass ist selten unsere Sichtung, sondern der Termin, an dem alle Entscheidenden gleichzeitig Zeit haben. Ein vollständiges Architektur- und Content-Modell-Review in zwei Wochen ist möglich, wenn die Seitentypen bereits benannt sind. Wenn nicht, sagen wir das – und liefern lieber eine belastbare Teilantwort als eine schnelle vollständige.

Wer sieht unseren Code, und was passiert damit danach?

Es arbeitet dieselbe Person daran, die Sie im Erstgespräch sprechen. Wir brauchen Lesezugriff auf das Repository, keine Produktivzugänge und keine Kundendaten. Arbeitskopien löschen wir nach Abschluss; Auszüge im Bericht beschränken sich auf das, was einen Befund belegt. Eine Vertraulichkeitsvereinbarung unterschreiben wir vorab – Ihre, wenn Sie eine haben, sonst bringen wir eine mit. Ihr Code taucht in keinem Referenztext auf, auch nicht anonymisiert.

Unser Team kennt React, aber kein Astro. Wie lange dauert es, bis wir produktiv sind?

Für ein Team mit Komponenten-Erfahrung ist die Syntax nicht das Problem, die Umgewöhnung ist es. Astro entfernt standardmäßig sämtliches clientseitige JavaScript, und Interaktivität wird pro Komponente über eine Direktive angefordert. Wer aus React kommt, hydratisiert anfangs zu viel. Zwei Workshop-Tage plus vier bis sechs begleitete Wochen sind der Rahmen, in dem sich dieser Reflex umstellt. Ihre React-Komponenten können Sie behalten: Astro bindet sie als Inseln ein.

Was passiert, wenn Ihr Review Fehler findet, die unser bisheriger Dienstleister gemacht hat?

Dann stehen sie im Bericht – als Befund mit Fundstelle, Wirkung und Aufwand, nicht als Urteil über eine Firma. Wir formulieren so, dass Sie den Bericht weitergeben können, ohne dass die Zusammenarbeit daran zerbricht; in den meisten Fällen ist genau das der sinnvollste nächste Schritt. Was wir nicht liefern, sind Berichte, die als Beweismittel in einer Auseinandersetzung dienen sollen. Dafür brauchen Sie eine öffentlich bestellte Sachverständige, nicht uns.

Wir sind mitten im Projekt. Ist es für ein Architektur-Review zu spät?

Zu spät ist es nie, aber es wird mit jeder Woche teurer, weil mehr auf dem Modell aufsetzt. Stehen die ersten Seitentypen und ist das Schema noch jung, lassen sich Änderungen in Tagen einarbeiten. Hängen bereits Redaktion, Weiterleitungen und Übersetzungen daran, wird aus derselben Änderung ein Umbau. In welcher der beiden Lagen Sie stecken, sagen wir Ihnen im Erstgespräch – das kostet nichts und dauert eine halbe Stunde.

Was kostet die Beratung, und warum steht kein Preis auf der Seite?

Weil der Zuschnitt zu unterschiedlich ist: Ein Entscheidungs-Review für ein Team ist etwas anderes als ein Code Review über ein gewachsenes Repository mit eigenen Erweiterungen. Die Kostentreiber stehen auf dieser Seite ausgeschrieben – Anzahl der Module, Größe und Alter der Codebasis, Zahl der Seitentypen und Sprachen, Beteiligte im Entscheidungsprozess, Workshops vor Ort. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit sichtbaren Annahmen, keine Hausnummer.

Was passiert, wenn Sie ausfallen?

Deshalb ist das Ergebnis schriftlich und liegt bei Ihnen, nicht in unserem Kopf: Bericht, Begründung, offene Entscheidungen, Konventionen im Repository. Ein begonnenes Modul lässt sich damit von einem anderen Team fortsetzen, ohne bei null anzufangen. Bei laufender Begleitung vereinbaren wir eine Vertretungsregel und halten den Stand fest, statt uns unentbehrlich zu machen. Das ist derselbe Grundsatz wie in der IT-Projektleitung: planmäßig wieder überflüssig werden.

Macht ein Nischen-Framework es schwerer, Entwickler zu finden?

Die Frage ist berechtigt und gehört ins Entscheidungs-Review. Zwei Punkte entlasten: Astro ist UI-Framework-agnostisch – React-, Preact-, Vue-, Svelte-, Solid- und Alpine-Komponenten laufen darin, vorhandenes Wissen bleibt also nutzbar. Und der größte Teil einer Astro-Codebasis ist HTML, CSS und TypeScript, nicht Framework-Spezialwissen. Trotzdem gilt: Wenn Ihr Personalmarkt eng ist und im Team niemand Lust auf Neues hat, ist das ein Argument gegen Astro. Dann schreiben wir es genau so hin.

Wir haben keine Astro-Referenz von Ihnen gesehen. Warum sollten wir Sie fragen?

Weil es keine gibt, die wir zeigen dürfen. Astro gehört zu unserem Stack, eine öffentliche Kundenreferenz dazu haben wir bisher nicht – und wir tun nicht so als ob. Prüfbar ist stattdessen die Arbeitsweise: unsere Webflow-Arbeit, die eigenen Produkte und die Struktur der Berichte, die aus diesen Modulen entstehen. Für ein Beratungsmodul ist das der bessere Prüfstein: Verlangen Sie im Erstgespräch eine Beispielgliederung und entscheiden Sie danach.

Brauchen wir für das Review Zugang zu Produktivsystemen?

Nein. Lesezugriff auf das Repository reicht, dazu – falls vorhanden – Build-Logs, die Konfiguration ohne Geheimnisse und Felddaten aus Ihrer Analyse-Umgebung. Zugänge zu Produktivservern, Redaktionskonten oder Kundendaten brauchen wir nicht und wollen wir auch nicht haben. Fehlt etwas davon, arbeiten wir mit einer benannten Annahme weiter und markieren sie im Bericht als solche, statt sie stillschweigend zu setzen.

Was ist ein Astro Code Review?

Eine strukturierte Durchsicht einer bestehenden Astro-Codebasis: Hydratisierung, Rendering-Strategie, Content-Schema, Bildverarbeitung, Abhängigkeiten und Build. Ergebnis ist eine Befundliste, sortiert nach Wirkung und Aufwand – inklusive der Punkte, die man bewusst so lassen sollte.

Ist Astro kostenlos?

Ja. Astro ist quelloffen und steht unter der MIT-Lizenz. Kosten entstehen durch Entwicklung, Hosting und Betrieb, nicht durch Lizenzen. Woraus sich der Rahmen zusammensetzt, steht unter Astro-Kosten. Am Aufwand der Beratung ändert die Lizenz nichts: Bezahlt wird Arbeitszeit, nicht Software.

Was sind Content Collections?

Ein Satz strukturell gleicher Inhalte mit einem Schema, das über Zod validiert wird und automatisch TypeScript-Typen liefert. Fehlt ein Pflichtfeld, bricht der Build statt der Live-Seite. Ausführlich unter Astro CMS.

Wie lange dauert ein Architektur-Review?

Ein bis zwei Wochen, beginnend mit einem Workshop-Tag. Länger wird es bei vielen Seitentypen, mehreren Sprachen oder wenn die CMS-Entscheidung noch offen ist. Die vollständige Übersicht steht in der Dauer-Tabelle weiter oben auf dieser Seite.

Braucht eine Astro-Website einen Server?

Nicht zwingend. Standardmäßig wird die gesamte Website vorgerendert und als statisches HTML ausgeliefert; das läuft auf jedem statischen Hosting oder CDN. Erst wenn einzelne Routen zur Laufzeit rendern sollen, kommt ein Adapter für die Ziellaufzeit dazu.

Beraten Sie auch remote?

Ja, standardmäßig. Sichtung und Berichte laufen ohnehin remote, Workshops und Durchsprachen gerne vor Ort im DACH-Raum. Gearbeitet wird auf Deutsch oder Englisch; welche Märkte und Zeitzonen wir abdecken, steht unter Märkte.

12 — Cluster

Weiterlesen im Astro-Cluster.

Die Seiten, auf die sich die Module am häufigsten stützen:

Eine unabhängige Antwort, bevor es teuer wird.

Beschreiben Sie kurz Vorhaben, Stand und die Entscheidung, die ansteht. Sie bekommen eine ehrliche Einschätzung, welches Modul passt – und die Absage, falls keines nötig ist. In der Regel innerhalb von 24 Stunden.

Beratung anfragen

13 — Vertiefen