Jedes Kundenprojekt kostet gleich viel Zeit — egal ob es das erste oder das fünfzigste ist. Nach 20 identischen Kontaktformularen, 20 identischen SEO-Setups und 20 identischen Vercel-Deployments stellte ich mir die Frage: Baue ich Websites, oder baue ich ein System, das Websites baut?

Die Antwort hat mein Geschäftsmodell verändert.

Das Zeit-gegen-Geld-Problem im Web-Freelancing

Freelance-Webentwicklung hat ein fundamentales Skalierungsproblem: 80% der Anforderungen sind bei jedem Projekt identisch.

Kontaktformular. Lokale SEO. Mobile-optimierte Navigation. Mehrsprachige Inhalte. Schema.org-Markup. Cookie-Banner. Impressum. Datenschutz. Google Analytics. Sitemap. Schnelles Deployment.

Die restlichen 20% sind individuell: Branding, spezifischer Content, vielleicht ein paar Custom-Features.

Aber du baust jedes Mal von null.

Die Rechnung ist brutal: Ein typisches KMU-Website-Projekt kostet 40-60 Stunden Entwicklungszeit. Bei einem Stundensatz von 80-100 EUR (DACH-Durchschnitt für erfahrene Freelancer) sind das 3.200-6.000 EUR pro Projekt. Klingt gut — bis du merkst, dass du bei 5 Projekten pro Monat 250 Stunden arbeitest. Das sind 62,5 Stunden pro Woche.

Nicht skalierbar. Nicht nachhaltig. Nicht smart.

Die Frage ist nicht, ob du schneller arbeiten kannst. Die Frage ist, ob du das System ändern kannst.

Die Architektur: Standalone Templates + Shell-Script-Generator

Ich habe mich gegen WordPress entschieden. Nicht weil WordPress schlecht ist — es ist für Content-Redakteure gebaut, die ohne Entwickler arbeiten wollen. Mein Ziel war anders: Ich wollte als Entwickler schnell deployen, ohne monatliche Hosting-Kosten beim Kunden, ohne Datenbank-Wartung, ohne Plugin-Updates.

Warum Astro?

Astro ist static-first. Das bedeutet: keine Datenbank, keine Server-Kosten, keine Sicherheitslücken durch veraltete Plugins. Der Output ist reines HTML, CSS und JavaScript. Lighthouse-Scores von 95+ sind Standard, nicht Ausnahme.

Die Komponenten-Architektur ist perfekt für Template-Bausteine. Ein <ContactForm>, ein <ProductGrid>, ein <HeroSection> — alles wiederverwendbar, alles typsicher, alles versioniert.

Warum ein Shell-Script statt eines No-Code-Generators?

Weil das Ziel nicht eine App ist — das Ziel ist Kontrolle.

Das Script ist 200 Zeilen Bash. Es ist lesbar, versionierbar, erweiterbar. Kein SaaS-Abo, kein Vendor-Lock-in, keine monatlichen Kosten. Ich kann es in 5 Jahren noch ausführen, ohne dass ein Startup pleite gegangen ist.

./create-customer-project.sh

# Fragen:
# - Branche? (Bäckerei, Restaurant, Handwerk, Beratung, Blog)
# - Markt? (DE, AT, CH, MX, CO, AR, CL, PE, ...)
# - Domain?
# - Primärfarbe?

# Output:
# → Vollständiges Astro-Projekt
# → Lokalisierung (14 Märkte: DACH + Lateinamerika)
# → SEO-Konfiguration (Schema.org, Sitemap, Meta-Tags)
# → Rechtliche Texte (Impressum, Datenschutz, länderspezifisch)
# → GitHub Repo
# → Vercel Deployment
# → Live URL in 5 Minuten

Der Trade-off: Kein visueller Editor. Du musst Code anfassen. Aber: Du hast volle Kontrolle. Keine Black Box. Keine Limitierungen.

Für mich als Entwickler ist das der richtige Trade-off. Für jemanden, der nie Code schreiben will, ist WordPress die bessere Wahl.

Was ich gebaut habe, das nicht funktioniert hat

Die erste Version hatte @shared-Imports.

Ich dachte: Warum sollte ich den gleichen <Button> in 5 Templates duplizieren? Ich baue ein @shared/components-Paket, und alle Templates importieren daraus.

Das Problem: Generierte Kundenprojekte hatten Abhängigkeiten.

Ein Kunde wollte selbst hosten. Er hat das Projekt geklont, npm install ausgeführt — und bekam einen Fehler. Das @shared-Paket war nicht öffentlich verfügbar. Broken Build.

Die Lösung: Templates sind vollständig standalone.

Jedes Template enthält alle Komponenten, alle Styles, alle Utils. Kein Import von außen. Wenn du ein Kundenprojekt generierst, ist es ein vollständiges, eigenständiges Astro-Projekt. Du kannst es auf GitHub pushen, auf Vercel deployen, auf deinem eigenen Server hosten — es funktioniert überall.

Der Trade-off: Code-Duplikation. Der gleiche <Button> existiert 5 Mal. Aber: Deployment-Sicherheit. Kein Kunde wird jemals einen Broken Build haben, weil eine Abhängigkeit fehlt.

Das ist der Unterschied zwischen “funktioniert auf meinem Rechner” und “funktioniert überall”.

Pastelería 2001: Der Beweis, dass es funktioniert

Das erste echte Kundenprojekt war eine mexikanische Bäckerei in Morelia, Michoacán.

Die Anforderungen:

  • 28 Produkte in 3 Kategorien (Pan Dulce, Pasteles, Galletas)
  • Preise in MXN (mexikanische Pesos)
  • Vollständig lokalisiert (es-MX, mexikanisches Spanisch — kein europäisches “vosotros”)
  • Mobile-optimiert (80% der Kunden browsen auf dem Handy)
  • Deployed auf Vercel

Die Umsetzung:

./create-customer-project.sh
→ Branche: Bäckerei
→ Markt: Mexiko (MX)
→ Domain: pasteleria2001.mx
→ Primärfarbe: #D4845A (warmes Terrakotta)

5 Minuten später: Live URL, Lighthouse Score 98/100 Performance, vollständig funktional.

Was das bewiesen hat: Es ist nicht nur ein Konzept. Es ist deployed, es läuft, es hat einen echten Kunden.

Was das System nicht löst (noch nicht)

Ich will ehrlich sein: Das ist kein CMS.

Limitierungen:

  • Kein visueller Editor für Kunden. Content-Updates erfordern Git-Kenntnisse oder meine Hilfe.
  • Keine E-Commerce-Integration. Produkt-Kataloge ja, Checkout-Flow nein.
  • Keine Benutzer-Authentifizierung. Statische Seiten, keine Login-Bereiche.

Warum das okay ist: Die Zielgruppe sind kleine Unternehmen, die eine Präsenz brauchen, keinen Online-Shop. Bäckereien, Handwerker, Berater, Restaurants. Sie brauchen eine Website, die ihre Leistungen zeigt, die auf Google gefunden wird, die auf dem Handy funktioniert.

Für alles andere gibt es Shopify, WooCommerce, oder Custom-Entwicklung.

Was als nächstes kommt: CMS-Integration ist geplant. Wahrscheinlich Decap CMS (ehemals Netlify CMS) — Git-basiert, kein Backend, kostenlos. Aber das ist Post 5 dieser Serie.

Wie die Standalone-Architektur Dependency-Hell verhindert

Der nächste Post geht in die technischen Details: Warum standalone templates besser sind als shared components, wie das Generator-Script 14 Märkte mit einem Command bedient, und warum Astro’s Content Collections das perfekte Datenmodell für Template-Systeme sind.

Dieser Artikel ist Teil 1 der Serie “Website Factory — wie ich ein skalierbares Web-Business aus Templates aufgebaut habe”.

Über den Autor: Daniel ist Solopreneur und Web-Entwickler, basiert in Berlin, operiert im DACH- und Lateinamerika-Markt. Er baut Systeme, keine einzelnen Projekte.