Mein Web-Stack für KMU: statisch starten, dynamisch ergänzen

Mein Web-Stack beginnt nicht bei Technologielogos, sondern bei vier Grenzen: Inhalt, Interaktion, Daten und Abnahme. Erst wenn diese Grenzen klar sind, entscheide ich, welche Werkzeuge tatsächlich nötig sind.

Für eine Unternehmenswebsite mit überwiegend öffentlichen Inhalten ist mein Ausgangspunkt häufig: statisch beginnen. Die Inhaltsseiten entstehen beim Build (einem automatisierten Erzeugungslauf) als HTML. Dynamische Funktionen können über eine gezielte API (Serverschnittstelle) hinzukommen; im Snapshot zeigt das die Kontakt-Route. Eine Datenbank wird erst Teil des Laufzeitwegs, wenn Daten wirklich dauerhaft gespeichert werden müssen. Vor der Veröffentlichung kontrollieren automatisierte Prüfungen – sogenannte Gates –, ob vereinbarte technische Regeln noch eingehalten werden.

Das ist keine universelle Blaupause. Braucht ein Redaktionsteam zwingend einen Browser-Editor, kann ein CMS (Redaktionssystem) die bessere Wahl sein. Sind personalisierte oder bei jeder Anfrage aktuelle Inhalte der Kern des Produkts, kann das Rendern bei der Anfrage oder eine Web-App besser passen. Der passende Stack ist nicht der größte. Es ist der kleinste, der die konkreten Anforderungen belastbar erfüllt.

Geprüfter, nicht öffentlich zugänglicher Repository-Snapshot (versionierter Projektstand): Commit 0d9f708, 15. September 2026. Der Quellstand ist kein Nachweis der Produktionskonfiguration.

Vier Grenzen statt acht Logos

Stack-Diskussionen beginnen oft mit Namen: Astro oder Next.js? PostgreSQL oder etwas anderes? Tailwind oder klassisches CSS? Für eine Investitionsentscheidung ist eine andere Reihenfolge nützlicher.

1. Inhalt: Was muss ausgeliefert werden?

Bleiben Leistungen, Blogbeiträge, Referenzen und Unternehmensinformationen zwischen zwei Veröffentlichungen für alle Besucher gleich, können diese Seiten vorab gebaut werden. Ändert sich der Inhalt erst mit einer redaktionellen Freigabe, muss er nicht allein deshalb bei jedem Aufruf neu erzeugt werden.

2. Interaktion: Was muss auf eine Eingabe reagieren?

Ein Kontaktformular ist dynamisch, auch wenn die Seite rundherum statisch ist. Es muss Eingaben prüfen, einen definierten Serverprozess auslösen und dem Besucher einen belastbaren Zustand anzeigen. Dafür braucht nicht automatisch jede Inhaltsseite einen Applikationsserver.

3. Daten: Was muss dauerhaft gespeichert werden?

Nicht jede Interaktion braucht eine eigene Datenbank. Eine Weiterleitung an einen konfigurierten Dienst hat andere Anforderungen als ein Kundenportal mit Konten, Berechtigungen und dauerhaftem Status. Persistenz sollte eine begründete Architekturentscheidung sein, kein Standardhäkchen im Starter.

4. Abnahme: Woran erkennen wir eine freigabefähige Änderung?

„Die Seite sieht bei mir gut aus“ ist kein vollständiger Freigabeprozess. Links, Metadaten, Sprachbeziehungen, Formverhalten, Typen und mobile Darstellung lassen sich für definierte Fälle automatisiert prüfen. Solche Tests beseitigen nicht jedes Risiko. Sie machen aber konkret vereinbarte Fehler vor einer Veröffentlichung sichtbar.

Architektur-Vorauswahl in 60 Sekunden

• Öffentliche Inhalte bleiben zwischen Builds gleich und der Veröffentlichungsweg passt zum Team: statisch beginnen.
• Fachabteilungen müssen Inhalte selbst im Browser bearbeiten und veröffentlichen: ein CMS prüfen.
• Kerninhalte müssen bei jeder Anfrage aktuell oder personalisiert sein: Rendern bei der Anfrage oder eine Web-App prüfen.
• Die Anforderungen unterscheiden sich je Bereich: eine Mischform prüfen, statt den gesamten Auftritt in ein einziges Betriebsmodell zu zwingen.

Das ist die Entscheideransicht. Eine Investitionsfreigabe sollte erst folgen, wenn Mindestumfang, Gesamtkostenrahmen, Zieltermin, interne Kapazität, ein namentlich verantworteter Betrieb und die wichtigsten Risiken akzeptiert sind. Fehlt davon Wesentliches, lautet der nächste Schritt nicht automatisch Umsetzung, sondern Klärung, Pilot oder Stopp.

Die folgenden Abschnitte zeigen, wie der aktuelle Wogenfels-Stack diese Trennung technisch umsetzt – und wo seine Grenzen liegen. Den fachlichen Rahmen dahinter beschreibe ich unter Digitalisierung für Unternehmen.

Technische Begründung: der Stack im Repository

Die folgende Tabelle ist eine Stichtagsaufnahme des tatsächlichen Projektstands, kein Einkaufszettel für jede Website.

Ebene	Bausteine am 15.09.2026	Rolle und Grenze im Projekt
Werkzeugbasis	Bun 1.4.2, Workspaces	Laufzeit, Paketmanager sowie zentraler Test- und Werkzeugpfad; Pin und Lockfile bleiben nötig
Inhaltsausgabe	Astro 7	Statischer Build, Routen, Markdown-Inhaltssammlungen, Sprachen und Bildverarbeitung; kein SSR-Adapter
Gestaltung	Tailwind CSS 4, lokale Starwind-Komponenten	Semantische Design-Tokens und wiederverwendbare UI-Bausteine; Updates und Prüfung bleiben Projektaufgabe
Interaktion	Hono 4 auf Bun, Zod 4	Getrennte API und validierte Eingabegrenzen nur für Funktionen mit Serverlogik
Daten	vorbereitetes Drizzle-/PostgreSQL-Paket über Bun SQL	Stellt typisierte Zugriffe und Migrationen bereit; der Snapshot belegt keine produktive Route mit Datenbankpersistenz
Abnahme	Lint, Typen, Tests, Build, SEO-Audit, Format und Playwright	Prüft definierte Regeln und Browserabläufe vor einer Veröffentlichung

Bun unterstützt Workspaces und bringt mit bun test einen eigenen Test-Runner mit. Im Wogenfels-Projekt ist Bun auf Version 1.4.2 gepinnt; installierte Bibliotheksstände kommen aus dem Lockfile statt aus offenen Versionsbereichen. So reduziert das Repository die Vielfalt seiner zentralen Runner. Das ist kein Geschwindigkeits- oder Kostenbenchmark.

Warum ich öffentliche Inhaltsseiten statisch beginne

Astros Konfiguration beschreibt output: "static" als Build-Modus, in dem Seiten standardmäßig vorab gerendert werden. Genau diese Betriebsart verwendet das Projekt. Blogbeiträge, Leistungsseiten und andere öffentliche Inhalte werden damit nicht erst bei der Anfrage zu HTML zusammengesetzt.

Für eine inhaltsgetriebene KMU-Website ist das eine plausible Ausgangslage, wenn zwei Bedingungen erfüllt sind:

1. Der öffentliche Inhalt darf zwischen Veröffentlichungen gleich bleiben.
2. Änderungen können einen kontrollierten Build- und Freigabeprozess durchlaufen.

In diesem Auslieferungspfad braucht die Inhaltsseite keinen Applikationsserver, der sie für jeden Besucher neu rendert. Sie braucht weiterhin Hosting, eine saubere Webserver- oder CDN-Konfiguration und einen verantworteten Veröffentlichungsprozess. Eine angebundene API und externe Dienste bleiben eigene Betriebskomponenten.

Der statische Build entfernt damit eine konkrete Laufzeitaufgabe aus der Inhaltsauslieferung: das wiederholte Erzeugen derselben öffentlichen Seite. Bildgröße, CSS, JavaScript, Inhalt und Betrieb müssen trotzdem bewusst gestaltet werden.

Statisch heißt nicht unbeweglich

Im aktuellen Frontend gibt es keine clientseitigen UI-Framework-Inseln, wohl aber gezielte Browser-Skripte und API-Aufrufe. Navigation, Consent, Formulare und Buchungsabläufe können interaktiv sein, obwohl die Ausgangsseite als statisches HTML geliefert wird.

Die nützliche Trennung lautet daher:

• Inhalt vorab bauen, wenn er zwischen Veröffentlichungen gleich bleibt.
• Interaktion gezielt ausführen, wenn eine Eingabe oder ein externer Zustand sie verlangt.
• Bei der Anfrage rendern, wenn die Seite selbst dann aktuell oder personalisiert sein muss.

Astro dokumentiert On-demand Rendering, also Rendern bei der Anfrage, mit einem Adapter unter anderem für personalisierte oder bei jeder Anfrage aktuelle Inhalte. Im geprüften Wogenfels-Frontend gibt es keinen solchen Adapter. Das ist eine Entscheidung für diesen Auftritt, kein Urteil gegen dieses Betriebsmodell.

Inhalte, Sprachen und Bilder gehören in denselben Build-Vertrag

Blogbeiträge liegen im Projekt als Markdown in einer validierten Astro-Inhaltssammlung. Content Collections verbinden Inhalte mit einem Schema und lassen sich über getCollection() abfragen. Im Wogenfels-Projekt baut getStaticPaths() daraus die Beitragsrouten.

Das ist bewusst code- und buildzentriert. Ein neuer Beitrag wird nicht in einem öffentlichen Adminbereich live editiert, sondern als geprüfte Datei versioniert und gebaut. Dieser Weg passt zu planbaren Veröffentlichungen und technischer Abnahme. Er passt schlechter, wenn viele Redakteure ohne Repository- und Build-Zugang laufend Inhalte selbst veröffentlichen müssen.

Zwei Sprachen sind mehr als zwei Textkopien

Deutsch liegt ohne Sprachpräfix unter /, Englisch unter /en/. Astros i18n-Routing unterstützt eine unpräfixierte Standardsprache. Übersetzte Slugs und ihre gegenseitige Zuordnung sind im Projekt zusätzlich zentral abgebildet; sie sind keine automatische Astro-Funktion.

Beide Sprachfassungen teilen Komponenten und strukturierte Regeln. Dadurch lässt sich doppelte Strukturarbeit begrenzen. Inhaltliche Parität entsteht trotzdem nicht von selbst. Titel, Description, Slug, Fachbegriffe, Links, Bilder und Aussagen müssen in jeder Sprache geprüft werden.

Ein Bild ist Teil der Seite, nicht Dekoration nach dem Build

Lokale Bilder laufen über eine gemeinsame Komponente auf Basis von Astros Asset-Pipeline. Astro kann importierte lokale Bilder verarbeiten und responsive Varianten erzeugen. Das Projekt erzeugt AVIF- und WebP-Ausgaben, setzt feste Maße und unterscheidet das priorisierte Titelbild von nachgeladenen Inhaltsgrafiken.

Ein Werkzeug verhindert weder ein unpassendes Motiv noch einen schlechten Alt-Text. Es kann technische Regeln – bekannte Quelle, Abmessungen, Varianten und Ladepriorität – an einer gemeinsamen Grenze durchsetzen.

Tailwind und lokale Komponenten: mehr Kontrolle, mehr Verantwortung

Tailwind CSS bildet im Projekt nicht bloß eine Sammlung kurzer Klassennamen. Markenfarben, Abstände und semantische Rollen werden als zentrale Tokens geführt. Tailwind 4 beschreibt @theme-Variablen als Grundlage für daraus erzeugte Utilities; die offizielle Vite-Integration verarbeitet die im Projekt verwendeten Klassen.

Der praktische Wert liegt in einer gemeinsamen Sprache: Eine Warnfläche, ein primärer Button oder eine Textfarbe wird über ihre Funktion gestaltet, nicht durch zufällig wiederholte Einzelwerte. Das kann konsistente Änderungen erleichtern. Gutes Design, klare Zustände und Barrierefreiheit müssen weiterhin konkret geprüft werden.

Für UI-Grundbausteine verwendet das Projekt Starwind. Starwind unterstützt Astro mit Tailwind CSS 4; seine CLI fügt Komponenten in das Projekt ein. Die verwendeten Komponenten liegen danach als lokale Dateien im Repository.

Das ist ein bewusster Tausch:

• Kontrolle: Markup und Styling liegen im eigenen Projekt und lassen sich an das Designsystem anbinden.
• Verantwortung: Updates, lokale Anpassungen, Barrierefreiheit und Regressionen müssen im Projekt geprüft werden.

„Wir besitzen den Code“ heißt nicht „wir müssen ihn nie wieder warten“.

Dynamik beginnt an einer klaren API-Grenze

Eine statische Website kann Daten entgegennehmen und Geschäftsprozesse anstoßen. Sie sollte nur klar benennen, wo der statische Teil endet.

Im Wogenfels-Projekt läuft dafür eine getrennte Hono-Anwendung auf Bun. Hono unterstützt Bun als Laufzeit und bietet anfragebezogene Validierung. Die konkrete Kontakt-Route nimmt JSON an und prüft es gegen ein Zod-Schema, bevor die fachliche Verarbeitung folgt. Zods safeParse() liefert grundsätzlich ein Ergebnis, das Erfolg und Fehler unterscheidet.

Die API sieht Kontrollstellen für Protokollierung, Sicherheits-Header, erlaubte Ursprünge, Anfragelimits und den Schutz gegen unerwünschte schreibende Fremdaufrufe vor. Das beschreibt Codegrenzen, nicht die Sicherheit eines unbekannten Produktionsbetriebs.

Das Kontaktformular illustriert den Architekturgedanken:

1. Hosting, Webserver oder CDN liefert das vorab erzeugte HTML an den Browser aus.
2. Erst die konkrete Eingabe geht als strukturierte Anfrage an die API.
3. Die API validiert und prüft die Anfrage an definierten Grenzen.
4. Ein externer Anbieter wird nur verwendet, wenn die entsprechende Konfiguration vorhanden ist.
5. Für einen belastbaren Ablauf sollten die API einen definierten Erfolgsstatus liefern und die Oberfläche ihn prüfen, bevor sie Erfolg anzeigt.

Damit wird nicht die gesamte Website dynamisch, nur weil ein Formular dynamisch sein muss. Umgekehrt wird das Formular nicht sicher oder datenschutzkonform, nur weil die Inhaltsseite statisch ist. Datenarten, Anbieter, Rechtsgrundlage, Verträge, Einwilligung, Aufbewahrung, Zugriff und Betrieb bleiben für die konkrete Verarbeitung zu prüfen. Diese technische Einordnung ersetzt keine rechtliche Prüfung und ist keine Rechtsberatung.

Datenpaket vorbereitet – Persistenz erst bei echtem Bedarf

Das Repository bereitet ein Datenpaket mit Drizzle ORM, Buns nativem SQL-Client und PostgreSQL-Dialekt vor. Drizzle dokumentiert die Verbindung über Bun SQL. Drizzle Kit kann SQL-Migrationen aus Schemaänderungen erzeugen und noch nicht angewandte Migrationen ausführen.

Der geprüfte Snapshot belegt jedoch keine produktive Route mit Datenbankpersistenz. Außerhalb des Datenpakets lädt nur ein Startup-Test das DB-Paket. Auch im Frontend und in den statischen Pfadgeneratoren gibt es keinen Datenbankimport. Build, Typprüfung und Inhaltsausgabe sind so angelegt, dass sie ohne laufende Datenbank funktionieren.

Eine Datenbank wird sinnvoll, wenn der Anwendungsfall dauerhafte strukturierte Daten braucht: beispielsweise Konten, Berechtigungen, fachliche Zustände oder nachvollziehbare Prozessstände. Dann gehören Schema, Migration, Zugriff, Backup, Aufbewahrung und Löschung gemeinsam in die Entscheidung.

Für einen reinen Inhaltsbereich wäre eine Datenbank allein deshalb kein Mehrwert, weil die Technik vorbereitet ist. Verfügbarkeit ist kein Anforderungsnachweis.

SEO und Qualität als prüfbarer Vertrag

Technisches SEO besteht aus Beziehungen, die bei einer Änderung leicht auseinanderlaufen: Titel und Description, Canonical, hreflang, Open-Graph-Bild, strukturierte Daten, interne Links, Sitemap, robots.txt, Sprache und Bildattribute.

Das gemeinsame Layout erzeugt im Projekt Canonical, hreflang, Open Graph und JSON-LD. Sitemap, robots.txt und llms.txt werden aus zentralen Daten abgeleitet. Ein eigener SEO-Prüfer liest den fertigen Build und kontrolliert definierte Regeln zu Metadaten, Überschriften, Sprachbeziehungen, Bildern, Links, strukturierten Daten und Sitemap.

Das ist für mich der Unterschied zwischen „wir haben SEO-Felder“ und „wir haben einen prüfbaren SEO-Vertrag“: Eine Regel ist nicht nur dokumentiert, sondern kann den Build mit einem konkreten Befund stoppen. Dieses Gate reduziert technische Auslassungen innerhalb seines Regelwerks; Suchnachfrage, Angebotsqualität und Ranking beurteilt es nicht.

Browser-Gates für Verhalten statt nur Dateien

Die Root-Prüfungen umfassen Lint, Typen, Unit- und Integrationstests, Build, SEO-Audit, Formatprüfung und Playwright-E2E. Playwright kann Test-Webserver konfigurieren; seine Web-Assertions warten automatisch, bis eine erwartete Bedingung eintritt oder das Zeitlimit erreicht ist.

Im Projekt prüfen Browserläufe definierte Abläufe und Darstellungen in Chromium, darunter mobile Ansichten, Navigation, Sprache, Formulare und Metadaten. Sie belegen diese Szenarien, nicht alle denkbaren Browser- und Fehlerfälle. Deshalb bleibt die Auswahl der Risiken wichtiger als eine hohe Testzahl.

Wann CMS oder Rendern bei der Anfrage besser passen

Der Wogenfels-Stack löst eine bestimmte Klasse von Anforderungen. Er wäre falsch eingesetzt, wenn seine zentrale Arbeitsweise gegen den Alltag des Kunden arbeitet.

Ausgangslage	Plausibler Startpunkt	Entscheidend zu prüfen
Öffentliche Inhalte bleiben zwischen Builds gleich	Statisch beginnen	Passt der Repo-/Build-Veröffentlichungsweg zum Team?
Browserbasiertes Editieren ist Kernanforderung	CMS, etwa WordPress, prüfen	Welche Rollen, Erweiterungen, Datenwege und Betriebsaufgaben entstehen?
Kerninhalte müssen je Anfrage aktuell oder personalisiert sein	Rendern bei der Anfrage oder Web-App prüfen	Welche Seiten benötigen diesen Modus tatsächlich?
Anforderungen unterscheiden sich nach Bereich	Mischform prüfen	Sind Grenze, Verantwortung und Freigabepfad je Bereich dokumentiert?

WordPress bietet einen browserbasierten Block-Editor. Wenn mehrere Fachabteilungen laufend Inhalte im Browser erstellen, prüfen und veröffentlichen müssen, ist ein redaktionelles System eine echte Anforderung – keine „alte“ Antwort.

Astro nennt personalisierte oder bei jeder Anfrage aktuelle Inhalte als Fälle für On-demand Rendering. Wenn Preise, Berechtigungen oder angemeldete Ansichten in diesen Bereich fallen, kann dieser Modus passend sein. Eine Mischform kann öffentliche Seiten vorab bauen und einen abgegrenzten App-Bereich dynamisch führen.

Die Arbeitsvorlage vor der Technologieauswahl

Beantworten Sie diese fünf Fragen schriftlich, bevor Angebote anhand von Frameworknamen verglichen werden:

1. Inhalt: Welche Seiten bleiben zwischen Veröffentlichungen gleich, und wie oft ändern sie sich?
2. Redaktion: Wer erstellt, prüft und veröffentlicht Inhalte – über Browser oder über einen Repository-/Build-Prozess?
3. Interaktion und Daten: Welche Funktionen brauchen Serverlogik, welche Daten müssen dauerhaft bestehen, und welche Anbieter werden berührt?
4. Aktualität: Welche Inhalte müssen tatsächlich bei jeder Anfrage aktuell oder personalisiert sein?
5. Abnahme: Welche Kernpfade, Sprachbeziehungen, Metadaten, Fehlerzustände und mobilen Ansichten müssen vor jeder Veröffentlichung nachweisbar sein?

Verantwortung gehört in die Architektur

Tragen Sie für jede Aufgabe Namen oder klar benannte Rollen ein. A steht für den Auftraggeber, der entscheidet, budgetiert und abnimmt. U steht für den Umsetzer, der plant, baut, dokumentiert und übergibt. B steht für den Betreiber, der überwacht, betreibt und wiederherstellt. Eine Person kann mehrere Rollen tragen; „Dienstleister“ oder „intern“ allein reicht für Eskalation und Budget nicht. Ein guter Digitalisierungspartner macht diese Grenzen vor der Umsetzung sichtbar.

Aufgabe	Rollen und Namen	Übergabenachweis und Eskalationsziel
Inhaltsfreigabe und Übersetzung	A: ___ / U: ___ / B: ___	___
Veröffentlichung und Rückweg	A: ___ / U: ___ / B: ___	___
Abhängigkeiten und Sicherheitsupdates	A: ___ / U: ___ / B: ___	___
Betriebskontrolle, Störung, Erreichbarkeit	A: ___ / U: ___ / B: ___	___
Sicherung und Wiederherstellung	A: ___ / U: ___ / B: ___	___
Anbieter, Verträge und Datenschutzprüfung	A: ___ / U: ___ / B: ___	___
Datenexport, Übergabe und Ausstieg	A: ___ / U: ___ / B: ___	___

Bleibt eine geschäftskritische Zeile ungeklärt, ist nicht der Stack fertig – nur die Demo.

Meilensteine bis zur Betriebsübergabe

Meilenstein	Ergebnis, Ziel, Abhängigkeit und interne Kapazität	Abnahme sowie Verantwortung für Umstieg und Rückweg
Konzeptfreigabe	___	___
Inhalts-/Datenübergabe	___	___
Pilot	___	___
Fachliche Abnahme	___	___
Betriebsübergabe	___	___

Gesamtkosten vergleichen, ohne Fantasiezahlen zu erfinden

Die Kosten eines Web-Stacks stehen nicht im Namen des Frameworks. Kopieren und befüllen Sie die folgende Vorlage für jede Option mit demselben Zeitraum und Funktionsumfang:

Feld	Einheit oder Rechnung	Eingabe
Gemeinsamer Zeitraum und Umfang	Monate, Seiten, Sprachen, Kernfunktionen und Ausschlüsse	___
Einmalige externe Aufwände	Konzeption + Design + Inhalte + Migration + Schnittstellen + Tests + Schulung	___ €
Laufende Aufwände	monatliche Beträge × Monate: Hosting, Laufzeit, Datenbank, Anbieter usw.	___ €
Interne Arbeit	Stunden je Rolle × interner Kostensatz	___ €
Änderung, Übergabe und Ausstieg	erwarteter Aufwand für Updates, Export, Dokumentation und Ablöse	___ €
Risikopuffer	begründeter Betrag für benannte Rest-Risiken	___ €
Gesamtkosten	einmalig + laufend + intern + Änderung/Ausstieg + Risikopuffer	___ €
Annahmen und Quelle	Angebotsstand, Mengengerüst, Ausschlüsse und Unsicherheiten	___
Verantwortliche Person und Datum	Name sowie Datum der letzten Prüfung	___

Ein günstiges Hostingangebot kann durch einen unpassenden Redaktionsprozess teuer werden. Ein mächtiges CMS kann wirtschaftlich sein, wenn es tägliche Fachredaktion ermöglicht. Ein schlanker statischer Stack kann unpraktisch sein, wenn jede Textänderung dauerhaft an einem überlasteten Entwicklungsteam hängt.

Ohne konkreten Umfang, Team, Anbieter und Betrieb wären Eurobeträge in diesem Beitrag nur scheinpräzise. Die bessere Vorentscheidung lautet: Welche laufende Arbeit erzeugt die Architektur – und welche Person übernimmt sie?

Was ich bewusst nicht verspreche

Dieser Stack ist für den beschriebenen Wogenfels-Auftritt nachvollziehbar. Daraus folgen keine allgemeinen Garantien:

• Astro oder ein statischer Build ist nicht automatisch schneller, sicherer oder SEO-stärker als jede Alternative.
• Technische Metadaten und ein SEO-Audit garantieren kein Ranking.
• Tests garantieren keine Fehlerfreiheit; sie prüfen die ausgewählten Szenarien.
• Statisch zu beginnen entscheidet nicht über DSGVO-Konformität. Der konkrete Datenfluss, Anbieter, Verträge, Konfiguration und Betrieb bleiben zu prüfen.
• Lokale UI-Komponenten beseitigen keine Updatepflicht.
• Der Snapshot 0d9f708 vom 15. September 2026 beweist weder den späteren Stand noch die Produktionskonfiguration.

Gerade diese Grenzen gehören für mich zur Kompetenzdarstellung: Eine gute Architektur erklärt nicht nur, was sie kann, sondern auch, wann sie nicht passt.

Kurzantworten zum Web-Stack für KMU

Warum Astro für eine KMU-Website?

Im geprüften Wogenfels-Snapshot 0d9f708 ist Astro passend, weil es die öffentlichen Inhaltsseiten gemäß seiner static-Konfiguration beim Build vorab erzeugen kann. Das gilt nur, solange diese Inhalte zwischen Veröffentlichungen weitgehend gleich bleiben und der Build-Ablauf zum Team passt.

Kann eine statische Website Formulare und Daten verarbeiten?

Ja. „Statisch“ beschreibt hier die Auslieferung der Inhaltsseite. Im Snapshot ruft das Kontaktformular eine getrennte, auf Bun laufende Hono-API auf. Dauerhafte Speicherung ist davon zu trennen: Das Drizzle-/PostgreSQL-Paket ist technisch vorbereitet, aber keine produktive Route mit Datenbankpersistenz ist im Snapshot belegt. API und Datenweg bleiben eigenständig zu prüfen.

Wann sind WordPress, ein CMS oder das Rendern bei der Anfrage sinnvoller?

Ein CMS ist plausibler, wenn browserbasiertes Editieren und redaktionelle Selbstständigkeit Kernanforderungen sind. Rendern bei der Anfrage oder eine Web-App ist plausibler, wenn zentrale Inhalte dann aktuell oder personalisiert sein müssen.

Fazit: Architektur zeigt sich an den Grenzen

Der aktuelle Wogenfels-Stack trennt vorab gebaute Inhalte, gezielte Interaktion, vorbereitete Persistenz und technische Abnahme. Ob diese Aufteilung für ein anderes KMU passt, entscheiden Redaktionsweg, Aktualität, Daten, Verantwortungen und Gesamtkosten – nicht die Logos im Stack.

Der nächste Prüfpunkt ist deshalb kein Framework-Angebot, sondern ein einseitiger, versionsgebundener Architektur-Steckbrief. Er verwendet für alle Optionen denselben Umfang und Zeitraum. Er nennt Anforderungen und ausgeschlossene Optionen, drei geschäftskritische Abläufe samt Ausfallfolge und Ausweichweg, Rollen mit Namen, Meilensteine, Abnahmekriterien und Annahmen zu den Gesamtkosten. Die wichtigsten Risiken erhalten Eintrittswahrscheinlichkeit, Auswirkung, Maßnahme, verbleibende Entscheidung und verantwortliche Person. Keine kritische Aufgabe bleibt ohne A-, U- und B-Zuordnung.

Fachlich und budgetverantwortlich benannte Personen bestätigen Version und Datum. Das Ergebnis muss eindeutig sein: Go, Pilot, Klärung oder Stopp. Erst danach folgt das passende Angebot oder die bewusst begrenzte Erprobung.

Einen Überblick über die konkrete Umsetzung finden Sie unter Leistungen. Für die gemeinsame Bestandsaufnahme bringen Sie Inhaltsrhythmus, Redaktionsrollen, Interaktionen, dauerhaft benötigte Daten und heutige Abnahmekriterien mit. In einem unverbindlichen Erstgespräch lässt sich daraus der Architektur-Steckbrief erarbeiten – bevor ein Framework feststeht.

Quellen und Aktualität

Die technischen Herstellerquellen wurden am 15. September 2026 direkt geprüft. Sie dokumentieren Funktionen, nicht die Überlegenheit des Wogenfels-Stacks. Aussagen zum versionierten Projektstand beziehen sich auf den nicht öffentlich zugänglichen Snapshot 0d9f708; er wird deshalb nicht als Leserquelle verlinkt.

• Astro: output-Konfiguration, Content Collections, Bilder, Internationalisierung, On-demand Rendering
• Bun: Workspaces, Test-Runner
• Tailwind CSS: Theme-Variablen, Vite-Integration
• Hono und Zod: Hono auf Bun, Hono-Validierung, Zod-Grundlagen
• Drizzle: Bun-SQL-Verbindung, Migrationen erzeugen, Migrationen ausführen
• Starwind UI: Installation, CLI
• Playwright: Testkonfiguration, Assertions
• WordPress: Block-Editor