Wo No-Code-Plattformen aufhören: regelbasierte Preisbildung
No-Code-Plattformen eignen sich gut für Marketing-Websites und inhaltsgetriebene Seiten, und Layout und Text lassen sich damit schnell ändern. Schwierig wird es, sobald die Seite rechnen oder entscheiden muss, etwa bei einem Preis, der von Optionen abhängt, die sich gegenseitig beeinflussen, oder bei einem Dashboard, in dem nur angemeldete Mitarbeiter die eingehenden Anfragen sehen.
Wo Content endet und Logik beginnt
Ein regelbasierter Preis braucht ein Datenmodell und ein Backend, und CMS-Felder an eine Formel zu binden, liefert keins von beidem. Die Preisregeln landen entweder in einer Datenbank mit Berechnungsschicht oder im Kopf eines Mitarbeiters, der sie in jedes Angebot neu abtippt.
Eine CMS-Collection speichert Datensätze. Sie stellt nicht sicher, dass Option A Option B ausschließt oder dass ab einem Schwellenwert ein Aufschlag gilt. Das sind Abhängigkeiten, und die müssen irgendwo ausgeführt werden. Übrig bleibt meist der Browser, also Skripte auf der Seite. Dann entsteht die Zahl auf einem Rechner, den das Unternehmen nicht kontrolliert, mit Code, den jeder Besucher lesen und ändern kann. Für eine Marketingzahl mag das reichen, eine Zahl für ein Angebotsdokument muss vom Server kommen.
Beim Dashboard ist es dasselbe Problem. „Nur angemeldete Mitarbeiter“ bedeutet Sitzungen und Zugriffsrechte pro Datensatz, über die der Server entscheidet, bevor Daten ausgeliefert werden. Die Seite zu verstecken, während die Datensätze weiter ausgeliefert werden, macht die Daten für jeden erreichbar, der sie direkt anfragt.
Was ein Optionsset erfordert
Der Konfigurator, den wir für aux-garagen.de gebaut haben, hat 41 Optionen.
Jedes Optionsset mit Regeln zwischen den Optionen bringt dieselben Anforderungen mit, ganz gleich, was verkauft wird:
ein Optionsmodell mit Abhängigkeiten und Ausschlüssen, damit ungültige Kombinationen weder auswählbar noch absendbar sind
eine serverseitige Validierung, die jede Regel der Oberfläche wiederholt, weil Besucher den Code im Browser ändern können
versionierte Preisregeln, damit ein Angebot, das vor der letzten Regeländerung verschickt wurde, sich heute noch erklären lässt
Währung und Mehrwertsteuer als Regeln innerhalb der Berechnung
Dokumenterzeugung auf dem Server aus der gespeicherten Konfiguration
dieselbe Konfiguration erzeugt immer dieselbe Zahl und dasselbe Dokument
Das übliche Problem sind zwei Berechnungen derselben Zahl: eine auf der Seite für die Anzeige und eine bei der PDF-Erzeugung. Sobald eine Regel nur auf einer Seite geändert wird, laufen sie auseinander, und der Kunde sieht auf dem Bildschirm einen anderen Preis als im Anhang. Deshalb rechnen wir einmal, auf dem Server, speichern das Ergebnis mit der Konfiguration und erzeugen das Dokument aus diesem Datensatz.
Versionierung ist aus demselben Grund wichtig. Ein Angebot spiegelt die Regeln wider, die am Tag des Versands galten. Werden Regeln direkt überschrieben, lassen sich alte Angebote aus dem Archiv nicht mehr erklären. Deshalb speichern wir Preisregeln in der Datenbank mit Datum für jede Änderung, und Schemaänderungen laufen über Migrationen.
Was das kostet
Das hat seinen Preis, und wir halten ihn schriftlich fest, bevor die Arbeit beginnt. Wir arbeiten mit unserem eigenen Stack: Next.js auf dem Server, dahinter Spring Boot und PostgreSQL, dazu unser eigenes CMS. Ein Kunde, der um Mitternacht einen Hero-Block an eine andere Stelle ziehen will, kann das nicht. Er bekommt einen strukturierten Editor für vorab festgelegte Abschnitte, und unter der Seite liegen keine Plugins von Drittanbietern.
Ein Backend muss außerdem betrieben werden: Migrationen werden eingespielt, die Datenbank wird gesichert, und jemand muss dafür zuständig sein. Auch Regelwerke wachsen. Jedes „nur noch eine Checkbox“ passt entweder ins Optionsmodell oder verbiegt es, und ein oft verbogenes Modell lässt sich schwer ändern.
Nicht jedes Projekt rechtfertigt das. Wenn der Preis eine einzige Zahl ist und es ein Kontaktformular gibt, ist eine No-Code-Website die richtige Antwort, und das sagen wir auch.
Unter der Marke der Agentur arbeiten
An diesem Punkt braucht eine Agentur, die ihrem Kunden eine Website verkauft hat, meist einen Backend-Entwickler. Die Agentur behält ihre Kundenbeziehung; unser Teil sind das Backend und der Konfigurator unter ihrer bestehenden Website, unter ihrer Marke.
Der Umfang wird schriftlich festgehalten, bevor irgendetwas gebaut wird. Ein Festpreis hält nur, wenn jede Regel ein Abnahmekriterium hat: was hineingeht und welches Ergebnis als korrekt gilt. Eine Regel-Engine wird getrennt von der Website kalkuliert, und alles, was später auftaucht, ist ein Änderungswunsch.
Dass dieser Punkt erreicht ist, merkt man meist daran, dass jemand im Team des Kunden dieselben Preise von Hand in jedes Angebot abtippt.
Wie wir solche Projekte abgrenzen und bepreisen, steht unter Leistungen.
