Wie ich SiteHorse.ai in 6 Wochen gebaut habe

Die Idee

Anfang 2026. Jeder Entwickler kennt das: Man hat eine Idee fuer ein Projekt, die einen nicht loslaeesst. Bei mir war es die Frustration darueber, wie aufwendig es immer noch ist, eine professionelle Website zu erstellen. Ja, es gibt WordPress, Wix, Squarespace. Aber all diese Tools verlangen, dass der Nutzer Entscheidungen trifft, die er eigentlich nicht treffen sollte: Welches Template? Welches Farbschema? Welche Schriftart? Wie organisiere ich die Navigation?

Meine Idee war einfach: Was waere, wenn man einer KI nur sagt, wer man ist und was man macht, und sie baut die komplette Website? Nicht ein Template, das man anpasst, sondern eine fertige, individuelle Website mit echten Inhalten, echtem Design, sofort live.

Das war die Geburtsstunde von SiteHorse.ai.

Marktanalyse in einer Woche

Bevor ich eine Zeile Code schrieb, habe ich eine Woche damit verbracht, den Markt zu analysieren. Nicht mit teuren Tools oder aufwendigen Studien, sondern pragmatisch: Wer sind die Wettbewerber? Was kostet eine Website heute? Wer braucht Websites, hat aber weder Zeit noch Budget fuer einen Designer?

Die Erkenntnis war klar: Es gibt einen riesigen Markt an kleinen Unternehmen, Freelancern und Vereinen, die eine professionelle Web-Praesenz brauchen, aber keine tausend Euro fuer einen Designer ausgeben wollen und keine Zeit haben, sich in Website-Builder einzuarbeiten.

Gleichzeitig waren die existierenden “KI-Website-Builder” enttaeuschend. Die meisten haben einfach ein Template genommen und die Platzhaltertexte durch KI-generierte Texte ersetzt. Das Ergebnis war generisch und uninspiriert. Ich wusste, dass ich es besser machen konnte.

MVP-Scope definieren

Die schwierigste Entscheidung bei jedem Produkt ist, was NICHT in die erste Version kommt. Ich hatte eine Liste mit fuenfzig Features, die SiteHorse haben sollte. Aber ich wollte schnell sein — sechs Wochen, ein einzelner Entwickler. Also habe ich radikal gekuerzt.

Der MVP musste genau drei Dinge koennen: Eine Reihe von Fragen stellen, um das Geschaeft des Nutzers zu verstehen. Aus den Antworten eine komplette Website generieren, inklusive Texte, Bilder und Design. Die Website auf einer Subdomain live schalten.

Alles andere — Custom Domains, E-Commerce-Integration, Analytics, Mehrsprachigkeit, Blog-Funktion — kam auf die “Spaeter”-Liste. Das war schmerzhaft, aber richtig.

Das Fundament: IT-Trail SaaS Stack

Bevor ich die erste Zeile SiteHorse-Code geschrieben habe, stand eine wichtige Entscheidung an: Baue ich alles von Grund auf, oder investiere ich zuerst in ein wiederverwendbares Fundament? Ich habe mich fuer Letzteres entschieden — und den IT-Trail SaaS Stack gebaut.

Der SaaS Stack ist ein All-in-One-Fundament fuer SaaS-Applikationen: OAuth2-basiertes Single Sign-On fuer alle IT-Trail-Services, User-Registrierung, Login ueber Google und Microsoft, Stripe- und Paddle-Integration fuer Payments und Subscriptions. Alles in TypeScript, alles modular, alles so gebaut, dass ich es in jedem zukuenftigen SaaS-Projekt wiederverwenden kann.

Diese Investition hat sich massiv ausgezahlt. Als ich mit SiteHorse begonnen habe, waren Authentifizierung, Payment und User-Management bereits geloest. Ich konnte mich voll auf das konzentrieren, was SiteHorse einzigartig macht: die KI-Pipeline zur Website-Generierung. Ohne den SaaS Stack haette ich Wochen laenger gebraucht — oder Kompromisse bei der Qualitaet gemacht.

Der Stack ist aktuell noch ein privates Repository, aber ich plane, ihn in Zukunft als Open Source zu veroeffentlichen. Gute Infrastruktur sollte kein Wettbewerbsvorteil sein — sie sollte ein Fundament sein, auf dem alle aufbauen koennen.

Technische Architektur

Backend: Node.js mit TypeScript

Die Wahl des Backends war schnell getroffen: Node.js mit TypeScript. Nicht weil es die objektiv beste Wahl war, sondern weil ich damit am schnellsten bin. In einem Solo-Projekt ist die Geschwindigkeit des Entwicklers der wichtigste Faktor, nicht die theoretische Ueberlegenheit einer Technologie.

Die Backend-Architektur baut auf dem IT-Trail SaaS Stack auf. Keine Microservices, kein Kubernetes, kein Over-Engineering. Ein einzelner Node.js-Service, der auf Hetzner Cloud in Deutschland laeuft, mit klar definierten Modulen fuer Website Generation, Template Rendering und Asset Management — waehrend Auth, Payments und User-Management vom SaaS Stack kommen. Alle Daten bleiben in Deutschland — das war mir von Anfang an wichtig.

Die KI-Pipeline

Das Herzsteueck von SiteHorse ist die KI-Pipeline, die aus den Nutzereingaben eine fertige Website generiert. Diese Pipeline besteht aus mehreren Schritten, die nacheinander und teilweise parallel ablaufen.

Im ersten Schritt analysiert ein LLM die Nutzereingaben und erstellt ein strukturiertes Profil: Branche, Zielgruppe, Tonalitaet, wichtigste Services oder Produkte. Im zweiten Schritt generiert ein weiterer LLM-Aufruf die Inhalte: Texte fuer jede Seite, Meta-Descriptions, CTAs. Im dritten Schritt wird ein passendes Design ausgewaehlt und konfiguriert: Farbschema, Typografie, Layout-Variante.

Jeder dieser Schritte hat seine eigenen Herausforderungen. Die Textgenerierung muss konsistent sein — der Ton auf der Startseite muss zum Ton auf der “Ueber uns”-Seite passen. Das Design muss zum Inhalt passen, nicht umgekehrt. Und das Ganze muss in unter dreissig Sekunden ablaufen, weil kein Nutzer laenger warten will.

Prompt Engineering: Die unerwartete Herausforderung

Ich habe unterschaetzt, wie viel Arbeit in den Prompts stecken wuerde. Meine ersten Versuche waren naive Single-Prompts: “Erstelle eine Website fuer einen Friseur in Wien.” Das Ergebnis war — nun ja — brauchbar, aber generisch.

Die Loesung war ein mehrstufiges Prompt-System mit spezialisierten Prompts fuer jeden Schritt. Ein Prompt fuer die Analyse, ein anderer fuer die Texterstellung, ein dritter fuer die Design-Entscheidungen. Jeder Prompt mit spezifischen Anweisungen, Beispielen und Constraints.

Ich habe ueber dreihundert Prompt-Iterationen durchlaufen, bis die Ergebnisse konsistent gut waren. Dreihundert. Das ist mehr als die Anzahl der Commits im gesamten Backend-Code.

Die groesste Herausforderung: Konsistenz. Ein einzelner guter Output ist relativ einfach zu erreichen. Tausend konsistent gute Outputs — fuer verschiedene Branchen, Sprachen, Zielgruppen — sind eine voellig andere Aufgabe.

Template-System

Ich habe mich bewusst gegen ein komplett freies Design entschieden. Stattdessen habe ich ein Template-System gebaut, das aus etwa zwanzig Design-Bausteinen besteht: Hero-Sektionen, Feature-Grids, Testimonial-Slides, Kontaktformulare, Footer-Varianten. Die KI waehlt die passenden Bausteine aus und konfiguriert sie mit den generierten Inhalten.

Das hat zwei Vorteile: Die Ergebnisse sind immer visuell ansprechend (weil die Bausteine professionell gestaltet sind), und die Generierung ist schnell und zuverlaessig (weil die KI nicht jedes Mal ein komplettes Design erfinden muss).

Herausforderungen und Fehler

Edge Cases

Der erste grosse Schock nach dem Launch: Die Vielfalt der Eingaben. Ich hatte mit Friseuren, Restaurants und Anwaelten getestet. Aber dann kamen Nutzer mit Businesses, die ich mir nicht vorgestellt hatte. Ein Alpaka-Zuechter. Ein Unterwasser-Hochzeitsfotograf. Ein Verein fuer historische Kampfkuenste.

Die KI hat das meistens gut gemeistert, aber es gab genug Ausreisser, um mich wochenlang mit Edge-Case-Handling zu beschaeftigen. Die Lektion: Egal wie viel man testet, die realen Nutzer werden Dinge tun, die man nicht erwartet hat.

Pricing

Mein erstes Pricing-Modell war falsch. Ich habe zu guenstig angefangen, weil ich Angst hatte, dass niemand zahlt. Das Ergebnis: Viele Anmeldungen, aber kaum Umsatz. Und noch schlimmer: Die Nutzer, die fuer sehr wenig Geld kommen, haben oft die hoechsten Erwartungen und den hoechsten Support-Aufwand.

Nach einem Monat habe ich die Preise verdreifacht. Die Anzahl der Anmeldungen ist gesunken, aber der Umsatz ist gestiegen, und die Qualitaet der Kunden hat sich deutlich verbessert. Preisgestaltung ist eine Kunst, und ich lerne immer noch.

Performance

Die erste Version der Generation hat zwei Minuten gedauert. Zwei Minuten, in denen der Nutzer auf einen Ladebalken geschaut hat. Die Conversion Rate war entsprechend schlecht. Ich habe wochenlang optimiert — parallele API-Aufrufe, Caching, Pre-Rendering — und bin jetzt bei unter dreissig Sekunden. Immer noch nicht perfekt, aber akzeptabel.

Lessons Learned

Sechs Wochen von der Idee zur Closed Beta. Was habe ich daraus gelernt?

Erstens: Der MVP ist nie so minimal, wie man denkt. Selbst nach radikalem Kuerzen war der Scope ambitioniert fuer eine Person in sechs Wochen. Ich habe ueber hundert Stunden Ueberstunden gemacht. Das ist nicht nachhaltig und ich wuerde es nicht empfehlen.

Zweitens: Prompt Engineering ist Software Engineering. Es braucht Struktur, Tests, Versionierung und systematisches Debugging. Wer Prompts wie Freitext behandelt, wird scheitern.

Drittens: Ship fast, aber nicht broken. Ich habe zu frueh gelauncht und die ersten Nutzer mit Bugs vergrault. Ein paar Tage mehr fuer Stabilisierung haetten mir Wochen an Firefighting erspart.

Viertens: Solo-Entwicklung hat Grenzen. Ich bin stolz auf das, was ich alleine gebaut habe. Aber ein Produkt braucht mehr als Code: Marketing, Support, Design, Content. Als Solo-Gruender muss man all das abdecken, und das ist auf Dauer nicht machbar.

SiteHorse befindet sich aktuell in der Closed Beta. Ausgewaehlte Nutzer testen das Produkt und geben wertvolles Feedback, das direkt in die Weiterentwicklung fliesst. Der oeffentliche Launch ist in Vorbereitung.

SiteHorse ist mein Beweis, dass ein einzelner Entwickler mit den richtigen Tools und genug Koffein ein SaaS-Produkt von der Idee zur Beta bringen kann. Aber es ist auch mein Beweis, dass man danach ein Team braucht.