Vom Excel-Monster zur DSL: Wie der Exovia Projektkalkulator entstanden ist

Die erste Version des Exovia Projektkalkulators habe ich 2017 gebaut.

Damals war React für uns noch neu und aufregend, WordPress praktisch alternativlos und ich hielt es für eine gute Idee, beides miteinander zu verheiraten. Heraus kam eine React-Anwendung, die irgendwie in einer WordPress-Seite lebte, ihre Ergebnisse per E-Mail verschickte und deren Preislogik mit jedem neuen Feature ein kleines Stück chaotischer wurde.

Technisch war das Ding vieles. Elegant gehörte nicht dazu.

Trotzdem hatte das Tool einen entscheidenden Vorteil: Es löste ein echtes Problem.

Menschen suchen seit Jahren nach Antworten auf dieselbe Frage:

Was kostet eine Website?

Und genau an dieser Stelle wird es meistens unerquicklich. Entweder bekommt man Paketpreise präsentiert, die mit dem eigenen Projekt wenig zu tun haben. Oder man bekommt die ehrliche Agenturantwort:

Es kommt darauf an.

Das stimmt zwar. Aber wer gerade ein Budget planen muss, kann mit dieser Antwort herzlich wenig anfangen. Über die Jahre wurde mir klar, dass die Preisberechnung selbst gar nicht das interessante Problem ist. Die eigentliche Herausforderung besteht darin, die richtigen Informationen einzusammeln, Projektideen zu strukturieren und aus einer vagen Vorstellung ein belastbares Bild zu erzeugen.

Als ich mich an die neue Generation des Kalkulators gesetzt habe, wollte ich deshalb nicht einfach einen moderneren Preisrechner bauen. Ich wollte das zugrundeliegende Problem sauber lösen.

Dieser Artikel handelt von genau diesem Weg: von Excel-Kalkulationen, Beratungsgesprächen, Regelwerken, einer selbstgebauten DSL und der Frage, wie man jahrelang gewachsenes Agenturwissen in Software überführt, ohne dabei in einer gigantischen If-Else-Hölle zu enden.

Das eigentliche Problem: Wissen steckt überall (und nirgends)

Wer schon einmal versucht hat, gewachsene Geschäftsprozesse zu digitalisieren, kennt das Problem: Das relevante Wissen liegt selten an einem einzigen Ort vor.

Bei Exovia war das nicht anders.

Ein Teil des Wissens steckt in den Köpfen erfahrener Berater. Ein anderer Teil versteckt sich in alten Angeboten, Kalkulationstabellen oder internen Richtwerten. Und dann sind da natürlich noch die berüchtigten Excel-Dateien – diese über Jahre gewachsenen Monster, die irgendwann geschäftskritisch werden, obwohl niemand mehr genau erklären kann, warum in Zelle X42 plötzlich mit 1,3 multipliziert wird.

Das Interessante daran: Keine dieser Quellen besitzt die alleinige Wahrheit.

Der Excel-Kalkulator rattert im Hintergrund und versucht, möglichst viele Variablen abzubilden. Parallel dazu braucht ein erfahrener Berater oft nur wenige Minuten, um das Ergebnis zu plausibilisieren. Dann kommen die Entwickler dazu und werfen technische Risiken in den Ring, während Spezialisten für SEO, Schnittstellen oder komplexe Integrationen weitere Perspektiven einbringen.

Und über all dem schweben Dinge, die in keiner Formel der Welt stehen: Kundenbeziehungen, Marktchancen oder die strategische Bedeutung eines Projekts.

Genau deshalb war das Ziel des Projektkalkulators nie, die menschliche Beratung wegzurationalisieren.

Die Aufgabe war deutlich pragmatischer.

Dieses über Jahre gewachsene Wissen sollte sichtbar, nachvollziehbar und für Interessenten nutzbar werden. Nicht als Ersatz für Beratung, sondern als Fundament für bessere Beratung. Wer neugierig ist und das Tool selbst ausprobieren möchte, findet den Exovia Projektkalkulator für Webseiten und Webprojekte hier.

Denn auch der beste Kalkulator kennt keine Kundenhistorie, keine Marktchancen und keine strategischen Ziele. Er kann Informationen strukturieren, Regeln anwenden und Muster sichtbar machen. Die eigentliche Entscheidung bleibt trotzdem eine menschliche.

Am Ende war deshalb nicht die Preisberechnung die größte Herausforderung.

Die eigentliche Herausforderung bestand darin, Wissen, das über Jahre in Köpfen, Angeboten, Gesprächen und Excel-Dateien gewachsen war, in ein konsistentes System zu überführen.

Wie aus Projektgesprächen ein System wurde

Wer echte Beratungsgespräche seziert, stößt unweigerlich auf ein Muster: Fragen existieren niemals isoliert im luftleeren Raum. Sie hängen voneinander ab.

Das liegt völlig auf der Hand. Ob bereits eine Website existiert, bestimmt die Richtung der nächsten Fragen. Ob Inhalte migriert werden müssen oder ein kompletter Neubau geplant ist, eröffnet völlig unterschiedliche Themenfelder. Und wer einen Onlineshop plant, biegt an einer ganz anderen Kreuzung ab als jemand, der lediglich seine Unternehmenswebsite modernisieren möchte.

Dafür muss man kein Raketenwissenschaftler sein. Das ist banale Logik und genau das, was bei Exovia seit Jahren in Beratungsgesprächen passiert.

In der Praxis bedeutet das: Eine Antwort macht ganze Themenblöcke überflüssig, die nächste zieht neue Fragen nach sich. Manche Antworten zeigen sofort, dass später Entwickler, SEO-Spezialisten oder andere Fachbereiche eingebunden werden müssen.

Genau hier lag der eigentliche Knackpunkt. Denn so selbstverständlich diese Zusammenhänge für einen Berater wirken, so unangenehm werden sie, sobald man versucht, sie in Software abzubilden.

Dadurch entstand nach und nach ein Modell, das deutlich interessanter war als ein klassischer Fragebogen.

Der Kalkulator ist im Kern keine Sammlung von Fragen. Er versucht, die Dynamik eines echten Projektgesprächs abzubilden.

Die Herausforderung bestand deshalb nie in der Preisberechnung am Ende. Die Herausforderung bestand darin, diese Abhängigkeiten so zu modellieren, dass Nutzer nicht mit irrelevanten Fragen bombardiert werden und gleichzeitig genügend Informationen zusammenkommen, um überhaupt eine belastbare Einschätzung treffen zu können.

Denn niemand hat Lust, fünfzig Fragen zu beantworten, von denen dreißig für das eigene Projekt keine Rolle spielen. Genauso wenig möchte man nach zehn schnellen Klicks eine Preiseinschätzung erhalten, die wesentliche Projektfaktoren ignoriert.

Zwischen diesen beiden Extremen entstand die Struktur, auf der der Kalkulator heute basiert.

Und genau an diesem Punkt wurde klar: Wenn diese gesamte Wenn-Dann-Logik dauerhaft im Frontend lebt, entsteht früher oder später das nächste Software-Monster. Die Regeln brauchten ein eigenes, sauberes Zuhause.

Warum eine eigene DSL?

An diesem Punkt war ziemlich klar: Wenn wir diese Logik dauerhaft in React-Komponenten vergraben, ist das Projekt im Eimer.

Ein paar Bedingungen im Frontend sehen am Anfang ja immer harmlos aus. Eine Frage poppt nur auf, wenn vorher „Bestehende Website” geklickt wurde. Die nächste hängt davon ab, ob Inhalte migriert werden müssen. Mehrsprachigkeit öffnet plötzlich Folgefragen zur Anzahl der Sprachen. Ein Onlineshop braucht völlig andere Pfade als eine Corporate Website.

Das geht fünf Minuten gut. Dann kommen die ersten Sonderfälle.

Und ehe du dich versiehst, steht da kein Kalkulator mehr, sondern ein Jenga-Turm aus if, else, includes, && und ||. Jede neue Frage, jede kleine Anpassung im Vertriebsprozess wird zur Operation am offenen Herzen, bei der du betest, dass an anderer Stelle nicht das Kartenhaus zusammenbricht.

Genau deshalb brauchte die Fachlogik ein eigenes, isoliertes Zuhause.

Die Lösung war allerdings keine hochtrabende, akademische DSL mit komplexem Parser, Compiler und großem Tamtam. Wir haben die Kirche im Dorf gelassen: Es ist im Kern eine schlanke, typisierte Beschreibungssprache geworden für genau dieses Tool.

Eine Frage ist bei uns nicht hart in der UI verdrahtet, sondern schlicht ein Datenobjekt. Sie hat eine ID, einen Typ, ein Label, mögliche Antworten und optionale Regeln für Sichtbarkeit, Scoring und Preislogik. Die UI ist im Grunde dumm – sie rendert nur noch stumpf, was diese Daten beschreiben.

Eine Sichtbarkeitsregel sagt zum Beispiel eben nicht im React-Code:

if (hasWebsite === "yes") {

showDomainQuestion();

}

Sondern liegt als saubere Deklaration direkt am Fragenobjekt:

{
  "visibleWhen": {

    "operator": "==",

    "question": "has_website",

    "value": "yes"

  }
}

Der Evaluator im Hintergrund rattert diese Regeln später einfach nur noch runter. Er kennt and, or, not, Vergleichsoperatoren und ein includes für Mehrfachauswahlen.

Die gleiche Idee gilt für das Scoring und die Preislogik. Fragen zahlen auf Achsen wie Scope, Setup, Ambition, Abstraction oder Budget ein. Antworten können Scores hochtreiben, Faktoren verändern oder feste Preisbestandteile triggern.

Damit wurde aus einem unübersichtlichen Haufen UI-Logik ein stabiles, zentrales Regelwerk.

Nicht perfekt für jedes Problem auf dieser Welt. Nicht universell. Und ganz sicher kein neues Open-Source-Framework, das die Tech-Welt revolutionieren will. Aber es passt wie angegossen für dieses Tool.

Und das Wichtigste: Es ist plötzlich für jeden lesbar, isoliert testbar und ohne Schweißausbrüche erweiterbar.

Die KI-Frage

Spätestens an dieser Stelle kommt heute fast automatisch dieselbe Frage auf:

Warum habt ihr dafür eigentlich keine KI verwendet?

Die Frage ist absolut nachvollziehbar. Schließlich geht es um Beratung, Projektbewertung, Aufwandsschätzungen und Preisfindung. Genau die Art von Problemen also, bei denen man inzwischen reflexartig an Large Language Models denkt.

Und natürlich haben wir uns diese Frage ebenfalls gestellt.

Auf den ersten Blick wirkt ein LLM sogar wie die offensichtliche, sexy Lösung. Man füttert das Modell mit alten Angeboten, Beratungsprotokollen und Kalkulationen und lässt die KI anschließend Aufwand, Risiken und Preise schätzen. Das klingt modern. Das klingt intelligent. Und es klingt verdammt noch mal deutlich spannender als eine Sammlung von JSON-Regeln.

Das Problem ist nur: Es löst nicht unser eigentliches Problem.

Denn das relevante Wissen existierte bereits. Wir hatten keine Wissenslücke. Wir hatten ein Strukturierungsproblem.

Die Informationen lagen längst auf dem Tisch – in Beratungsgesprächen, Angebotsprozessen, Excel-Tabellen und den Köpfen unserer Spezialisten. Die Herausforderung bestand nicht darin, durch Magie neue Erkenntnisse zu erzeugen, sondern vorhandene Erkenntnisse konsistent und nachvollziehbar abzubilden.

Ein Sprachmodell ist hervorragend darin, Wahrscheinlichkeiten zu berechnen. Es kann Zusammenhänge erkennen, Texte zusammenfassen und Muster extrapolieren. Was es konstruktionsbedingt nicht liefert, sind nachvollziehbare und deterministische Entscheidungen.

Wenn ein Interessent dieselben Antworten zweimal eingibt, muss der Kalkulator dieselbe Bewertung liefern. Wenn sich eine Preisregel ändert, müssen wir im Code glasklar nachvollziehen können, warum sich das Ergebnis verändert hat. Und wenn ein Berater später auf eine Empfehlung schaut, darf er nicht raten müssen, was die Blackbox sich dabei gedacht hat.

Genau diese Nachvollziehbarkeit war uns deutlich wichtiger als jede Form von KI-Kreativität.

Deshalb haben wir den Kern des Systems bewusst streng regelbasiert aufgebaut. Nicht weil KI grundsätzlich ungeeignet wäre. Sondern weil die eigentliche Herausforderung an einer völlig anderen Stelle lag: Wir mussten kein neues Wissen erfinden. Wir mussten vorhandenes Wissen modellieren.

Interessanterweise macht genau das viele vermeintliche KI-Probleme am Ende zu ganz klassischen Softwareproblemen. Sobald das Fachwissen klar definiert ist, Regeln existieren und Entscheidungen reproduzierbar sein müssen, landet man erstaunlich oft wieder bei soliden Datenstrukturen, logischen Modellen und sauberer Fachlogik.

Nicht alles braucht ein neuronales Netz.

Manchmal braucht man einfach nur ein gutes altes Regelwerk.

Aus Fachwissen wurde ein Regelwerk

Die DSL war am Ende nur ein kleiner Teil der Lösung.

Die eigentliche Herausforderung bestand darin, das vorhandene Wissen überhaupt in eine Form zu bringen, mit der Software arbeiten kann.

Fragen wurden zu Datenstrukturen. Antworttypen wurden beschrieben statt programmiert. Sichtbarkeitsregeln wurden als Daten definiert. Bewertungen und Gewichtungen ebenfalls. Selbst Teile der Preislogik bestehen heute aus Regeln statt aus hart verdrahtetem Anwendungscode.

Dahinter steckt allerdings keine besonders revolutionäre Idee.

Wenn Fachlogik langfristig gepflegt, erweitert und getestet werden soll, braucht sie einen festen Ort. Genau deshalb beschreibt der Kalkulator heute möglichst viel Fachwissen deklarativ statt es über Komponenten, Funktionen und Sonderfälle zu verteilen.

Eine Frage weiß beispielsweise, welche Art von Antwort sie erwartet. Sie kann festlegen, unter welchen Bedingungen sie sichtbar wird. Antworten können verschiedene Bewertungsachsen beeinflussen oder bestimmte Preisregeln auslösen.

Dadurch entsteht Schritt für Schritt ein Modell des Projekts.

Interessanterweise ist die Preisberechnung dabei gar nicht der spannendste Teil des Systems. Deutlich interessanter ist die Beschreibung des Projekts selbst. Der Kalkulator betrachtet Projekte heute entlang verschiedener Dimensionen wie Scope, Setup, Ambition, Abstraction und Budget.

Ein Projekt kann technisch überschaubar sein und trotzdem hohe Anforderungen an Abstimmung, Strategie oder Konzeption stellen. Umgekehrt kann ein großer Funktionsumfang bei sehr klaren Anforderungen vergleichsweise unkompliziert umgesetzt werden.

Der Preis entsteht deshalb nicht aus einer einzelnen Formel und auch nicht aus einer magischen Zahl. Er ist lediglich das Ergebnis verschiedener Regeln, Gewichtungen und Zusammenhänge.

Rückblickend ist genau das wahrscheinlich die wichtigste Erkenntnis des gesamten Projekts.

Nicht die Preislogik.

Sondern die Tatsache, dass sich ein großer Teil von Agenturwissen erstaunlich gut als Regelwerk beschreiben lässt.

Vom Preisrechner zum Scoping-System

Als die erste Version des Kalkulators entstand, war die Zielsetzung noch vergleichsweise simpel: Interessenten sollten eine grobe Preisindikation erhalten.

Das war sinnvoll. Und ehrlich gesagt ist es bis heute einer der Hauptgründe, warum Menschen das Tool überhaupt aufrufen.

Mit der Zeit wurde allerdings immer deutlicher, dass der Preis nur einen kleinen Ausschnitt der eigentlichen Geschichte erzählt. Denn dieselbe Preiseinschätzung kann aus völlig unterschiedlichen Gründen entstehen.

Zwei Projekte können am Ende in einer ähnlichen Budget-Größenordnung landen und trotzdem kaum etwas miteinander gemeinsam haben. Das eine Projekt ist technisch anspruchsvoll, aber organisatorisch von Anfang an klar strukturiert. Das andere besitzt einen überschaubaren Funktionsumfang, erfordert aber zahlreiche Abstimmungen, aufwendige Inhalte oder komplexe Entscheidungsprozesse.

Die Zahl auf dem Bildschirm macht diese Unterschiede nicht sichtbar.

Genau deshalb begann sich der Fokus des Systems über die Jahre zu verschieben.

Statt ausschließlich auf einen Preis hinzuarbeiten, beschreibt der Kalkulator heute zunächst das Projekt selbst. Er betrachtet unterschiedliche Dimensionen wie Umfang, technische Anforderungen, Ambitionsniveau, organisatorische Komplexität oder Budgetrahmen und erzeugt daraus ein deutlich vollständigeres Bild. Der Preis entsteht erst anschließend.

In gewisser Weise funktioniert der Kalkulator heute ähnlich wie ein gutes Erstgespräch. Nicht weil er die menschliche Beratung ersetzt – das kann er nicht –, sondern weil er genau die Informationen strukturiert einfängt, die in einem echten Beratungsgespräch ohnehin auf den Tisch kommen würden.

Das Interessante dabei: Je weiter wir das System entwickelt haben, desto weiter rückte die eigentliche Preiszahl in den Hintergrund.

Nutzer möchten verschiedene Szenarien durchspielen. Sie möchten verstehen, welche Anforderungen den Aufwand beeinflussen. Sie möchten nachvollziehen können, welche Auswirkungen bestimmte Entscheidungen auf das Gesamtprojekt haben.

Der Kalkulator beantwortet deshalb längst nicht mehr nur die klassische Frage:

„Was kostet das?”

Er hilft dabei, die oft deutlich schwierigere Frage zu beantworten:

„Was genau bauen wir hier eigentlich?”

Und vielleicht beschreibt genau das den Wandel der letzten Jahre am besten.

Aus einem Preisrechner wurde Schritt für Schritt ein Werkzeug zur Projektdefinition und zum Scoping.

Die technische Architektur

Die erste Version des Kalkulators lief als React-Komponente innerhalb von WordPress. Damals war das pragmatisch. Heute ist das Tool eine eigenständige Webanwendung mit eigenen Nutzerkonten, Datenmodellen und komplexer Geschäftslogik.

Gleichzeitig hat sich auch exovia weiterentwickelt. Die Mission ist es, moderne Architekturen wie Headless-Systeme oder maßgeschneiderte Anwendungen für Unternehmen zugänglich zu machen, die keine Konzernbudgets besitzen. Deshalb basiert die aktuelle Generation auf einem TypeScript-Stack mit Next.js, PostgreSQL, Drizzle und Better Auth. Nicht wegen des Hypes, sondern weil diese Technologien hervorragend zu der Art von Software passen, die heute entwickelt wird.

Mindestens genauso wichtig war allerdings eine andere Entscheidung:

Datenschutz war bei diesem Projekt kein lästiges Compliance-Thema, sondern eine bewusste Architekturentscheidung.

Deshalb laufen Datenbank und Anwendung auf eigener Infrastruktur. Und das bedeutet heute eben nicht mehr, dass man einen Server im Keller betreiben oder Unsummen für irgendwelche Enterprise-Cloud-Angebote ausgeben muss.

Zum Einsatz kommen klassische VPS-Instanzen mit Ubuntu bei europäischen Anbietern wie OVHcloud oder Hetzner. Warum? Weil moderne Linux-Infrastruktur heute so zugänglich, leistungsfähig und kosteneffizient ist wie nie zuvor. Für Anwendung und PostgreSQL-Datenbank bedeutet das volle Kontrolle. Und wenn zusätzlicher Speicherplatz benötigt wird – etwa für Uploads oder generierte PDFs –, reicht ein S3-kompatibler Object Storage völlig aus.

Das ist keine ideologische Entscheidung. Viele der innovativsten Technologieunternehmen der Welt kommen nach wie vor aus den USA. Gleichzeitig wäre es naiv, die Realität rund um digitale Souveränität, Datenhoheit und den US Cloud Act zu ignorieren. Wer keine Lust hat, sein Geschäftsmodell von regulatorischen Grauzonen, Plattformabhängigkeiten oder der nächsten Preisrunde eines Cloud-Anbieters abhängig zu machen, baut seine Architektur von Anfang an möglichst souverän.

Datenhoheit gehört für mich deshalb nicht in die Rechtsabteilung, sondern in die Architektur.

Vielleicht ist das die wichtigste Erkenntnis dieses Umbaus: Moderne Softwarearchitektur bedeutet nicht, die Kontrolle abzugeben.

Was WordPress über viele Jahre so attraktiv gemacht hat – die Hoheit über die eigenen Daten und die eigene Infrastruktur –, lässt sich heute mit einem modernen Stack auf einem völlig anderen technologischen Niveau erreichen. Man muss sich nicht mehr zwischen digitaler Souveränität und moderner Softwareentwicklung entscheiden.

Der Blick nach vorn: Was ich heute anders machen würde

Kein System ist perfekt, und wer nach einem solchen Umbau behauptet, er würde rückblickend alles exakt genauso wieder bauen, lügt sich selbst an. Die Fachlogik und die Persistenz standen für mich von Anfang an felsenfest – aber bei der Wahl der Werkzeuge lernt man während des Prozesses.

Wenn ich heute noch einmal anfangen würde, gäbe es drei radikale Änderungen in der Architektur:

1. Goodbye, Server Actions (Zurück in die Zukunft mit PHP-Vibes)

Ich würde beim nächsten Mal einen großen Bogen um Next.js Server Actions machen. Das mentale Modell dahinter fühlt sich phasenweise an wie PHP im Jahr 1997. Diese extrem enge Verzahnung führt am Ende dazu, dass man mehr Zeit damit verbringt, penibel darauf zu achten, welche Engine-Funktion jetzt versehentlich im Frontend-Bundle landet, anstatt einfach Code zu schreiben. Eine klare, unmissverständliche API-Schicht kostet am Anfang vielleicht fünf Minuten mehr Setup, spart hintenraus aber tonnenweise kognitiven Ballast.

2. Entkopplung von Next.js (Hallo Hono!)

Ich stelle mir zunehmend die Frage, ob Next.js überhaupt noch Backend-Code schreiben darf. Die Abhängigkeit von Vercels Ökosystem ist mir auf Dauer zu eng. Mein Favorit für die Zukunft heißt hier ganz klar Hono. Warum? Weil es leichtgewichtig ist, eine fantastische Middleware besitzt und die Verantwortlichkeiten wieder sauber trennt. Next.js darf das tun, worin es gut ist: Die UI rendern. Das komplette Backend – inklusive der mühsam aufgebauten DSL-Logik – gehört in eine eigenständige, pfeilschnelle API.

3. Die DSL als isolierter Kern (Und vielleicht Open Source?)

Im Moment teilt sich die DSL noch das Repository mit dem Kalkulator. Rückblickend hätte ich den Evaluator und das gesamte JSON-Regelwerk von Tag eins an in ein komplett eigenes, isoliertes Paket ausgelagert. Diese Logik ist der heilige Gral der Anwendung – sie hat absolut nichts mit Next.js, UI-Rendering oder Auth-Bibliotheken zu tun. Wenn das Ding in einer eigenen Box lebt, kann das Frontend explodieren, ohne dass der logische Kern einen Kratzer abbekommt.

Und wer weiß: Da der Ansatz für jede Form von bedingten Umfragen oder dynamischen Formularen erstaunlich gut funktioniert, machen wir das Paket in Zukunft vielleicht einfach Open Source.

Fazit

Rückblickend ist die eigentliche Erfolgsgeschichte dieses Projekts für mich gar nicht der Kalkulator selbst.

Es ist die Erkenntnis, dass sich erstaunlich viel von dem, was wir in Agenturen oft als „Erfahrung”, „Bauchgefühl” oder „Spezialistenwissen” verbuchen, in saubere Modelle, Regeln und Datenstrukturen gießen lässt. Aus meinen Excel-Kalkulationen wurde ein Regelwerk. Aus unzähligen Projektgesprächen entstand ein echtes Scoping-System. Und aus einem klassischen Preisrechner wurde Schritt für Schritt eine eigenständige Webanwendung.

Das Ergebnis ist heute kein internes Agenturwerkzeug, sondern eine öffentlich zugängliche Webanwendung. Jeder kann den Kalkulator nutzen, verschiedene Projektszenarien durchspielen und nachvollziehen, welche Faktoren Aufwand, Komplexität und Budget beeinflussen. Genau das war letztlich das Ziel des gesamten Projekts: Nicht Wissen hinter Angeboten und Beratungsgesprächen zu verstecken, sondern einen Teil davon transparent und für Interessenten zugänglich zu machen.

Wer den Kalkulator selbst ausprobieren möchte, findet ihn hier: https://www.exovia.de/webdesign-preise. Probiert ihn gerne aus und schreibt mir, was ihr davon haltet. Mich interessiert besonders, wo die Einschätzungen gut passen, aber auch, an welchen Stellen ihr noch Fragen, Lücken oder Verbesserungsideen seht.

Gleichzeitig ist das Projekt für mich der lebende Beweis dafür, dass moderne Webtechnologien heute mit absolut vertretbaren Mitteln und in Rekordzeit zu 100 % DSGVO-konform betrieben werden können. Jenseits des Marketing-Hypes von Vercel und großen US-Cloud-Plattformen zeigt dieser Umbau: Man kann den vollen Komfort von Next.js und TypeScript nutzen, ohne die Kontrolle über die eigenen Daten abzugeben. Digitale Souveränität im Mittelstand ist kein unbezahlbares Enterprise-Projekt – sie ist eine reine Architekturentscheidung.

Viele Probleme, die heute reflexartig als KI-Themen diskutiert werden, sind in Wahrheit Wissens- und Modellierungsprobleme. Und man muss nicht jede Welle reiten, um ganz vorne mitzuspielen.

Manchmal braucht man kein neuronales Netz. Manchmal reicht ein sauberes Modell.