Warum fastsite existiert

Jedes Tool im Stack eines kleinen Unternehmens ist für sich genommen ausgezeichnet. Keines davon spricht mit den anderen, und alle werden monatlich abgerechnet. fastsite existiert, weil dieses Muster auch das Publishing erfasst hat.

Das Problem

Früher war es einfach, Texte ins Internet zu stellen. Dann brauchte es ein CMS, und das CMS brauchte Plugins, und die Plugins brauchten eine Build-Pipeline, und die Build-Pipeline brauchte eine Laufzeitumgebung, und die Laufzeitumgebung brauchte einen Hosting-Plan mit Abrechnung pro Nutzer. Irgendwo dazwischen wurde die eigentliche Aufgabe — etwas schreiben, es live stellen, schnell laden lassen — unter mehreren hundert Kilobyte JavaScript und einer monatlichen Rechnung begraben.

fastsite nimmt die entgegengesetzte Position ein. Inhalte kommen per API, Webhook oder MCP herein. Statisches HTML kommt heraus. Es gibt keine Laufzeitumgebung am Edge, keine Datenbank, die Besucher erreichen können, und kein ausgeliefertes JavaScript — der Build weigert sich, eine Seite zu veröffentlichen, die einen PageSpeed-Punkt kosten würde, anstatt sie stillschweigend degradieren zu lassen.

Wer es entwickelt

fastsite wird von Lennart Øster geschrieben, einem Entwickler in Dänemark, der seit 1995 programmiert und 1999 sein Unternehmen SitePoint Systems gegründet hat. Das erste Jahrzehnt verlief konventionell: Beratung für große Unternehmen in Dänemark, Schweden und Brasilien, Entwicklung von Individualsoftware für Menschen mit konkreten Problemen, statt ihnen Produkte aufzudrängen.

Vor etwa fünfzehn Jahren schlug er den umgekehrten Weg zur üblichen Gründergeschichte ein. Nachdem er bereits ein Unternehmen mit Angestellten geführt hatte, entschied er, dass ein Ein-Personen-Betrieb besser zu ihm und seiner Familie passt — und seitdem entwickelt und betreibt er Softwareprodukte alleine. Die Einschränkung erwies sich als das Nützliche daran: Wenn man das gesamte Team ist, muss etwas wirklich wichtig sein, bevor es gebaut wird.

Das Muster

Die Produkte entstehen alle auf dieselbe Weise — aus etwas in seinem eigenen Stack, das funktioniert, aber zu viel kostet.

• Da er zuverlässiges Cookie-Consent-Management benötigte und die verfügbaren Optionen zwar solide, aber teuer fand, baute er Conzent. Es wurde zu einer eigenständig zertifizierten CMP, und im Juli 2026 wurde es vollständig Open Source — mit einer gehosteten Version für alle, die keinen eigenen Server betreiben können oder wollen.
• Nichts auf dem Markt passte zu seiner Art, E-Mail und Support zu handhaben, also baute er auch das.
• Dann ein CRM, Geniziz, zum Pauschalpreis statt pro Nutzer — denn nutzerbezogene Preisgestaltung zwingt kleine Teams stillschweigend dazu, festzulegen, wer sich einloggen darf, was den Sinn des Tools untergräbt.

fastsite ist dieselbe Bewegung, auf Publishing angewendet, mit einer Ergänzung: Es wurde von Anfang an für Agenten konzipiert, nicht nachträglich dafür umgebaut. Der MCP-Server ist keine Integration, die nachträglich an ein Dashboard angeschraubt wurde. Er ist die Art, wie die Engine gedacht ist, betrieben zu werden.

Was das für das Projekt bedeutet

Ehrlich über die Kompromisse

Ein Ein-Personen-Projekt ist nicht dasselbe wie eine finanzierte Plattform, und so zu tun, als ob, wäre genau die Art von Sache, gegen die diese Website steht. Es gibt keinen 24/7-Support. Feature-Anfragen werden gegen die verfügbaren Stunden einer Person abgewogen. Wenn das für Ihre Organisation ein K.-o.-Kriterium ist, dann sollte es das sein — und die Lizenz bedeutet, dass Sie die Engine forken und selbst pflegen können, anstatt feststeckzusein.

Was Sie dafür erhalten: keine Nutzerrechnung, kein Vendor-Lock-in, keine von einem Investoren-Deck getriebene Roadmap und eine Codebasis, die klein genug ist, dass eine Person sie im Kopf behalten kann.