Beim Frühstück die Website meiner Schwester aktualisiert

Ich bin diese Woche in Zürich und besuche meine Schwester Barbara. Sie führt hier ein kleines Restaurant. Ihre Website habe ich vor einer Weile gebaut. Websites zu bauen mache ich nebenher, vor allem weil es Spass macht und weil sich die Werkzeuge schnell genug ändern, dass man nur dann weiss, was tatsächlich möglich ist, wenn man es immer wieder tut. Wie jede Kleinunternehmerin hat sie eine echte Liste mit Dingen, die sie daran anders haben möchte. Die meisten sind winzig. Keines davon ist dringend ... und wie alle grossen Brüder lasse ich sie warten.

Dieser Besuch wurde zu ein paar Minuten "irgendwann". Laptop auf ihren Küchentisch, Projekt geöffnet, Änderungen gemacht, live gestellt. Der Kaffee war noch heiss.

Was ihre Website tatsächlich kann

Als ich das damals gebaut habe, habe ich mir die Restaurant-Vorlagen von der Stange angeschaut. Wahrscheinlich schlechter. Sie sind nach dem Prinzip gebaut, möglichst vielen zu passen, und das heisst meistens: gebaut für die grossen städtischen Märkte, die den Vorlagenherstellern am Herzen liegen. Die ländliche Schweiz steht nicht auf dieser Karte. Die geografischen Voreinstellungen stimmen nicht, die angebotenen Integrationen sind die falschen, und die Annahmen darüber, wie ein Restaurant läuft, passen nicht dazu, wie ihres läuft.

Barbara hat eine Standardkarte und eine, die wöchentlich wechselt. Was sie nicht hatte, war ein richtiger Reservationsablauf oder eine Stelle, an der Gäste ihre handgemachten Kerzen bestellen können. Jetzt hat sie beides. Sie wollte ihre eigene Bestell- und Reservationslogik, gebaut um ihre tatsächliche Arbeitsweise herum. Gebaut wurde durchgehend, vom CMS über das CRM bis zu den E-Mail-Konten mit eigener Domain. So etwas ist einfacher, wenn eine Person den ganzen Stack kontrolliert, und unmöglich, wenn man sich durch eine fünfwöchige Ticket-Warteschlange bei einer Agentur arbeitet. Zugegeben: Die 9'000 km zwischen uns haben es einfacher gemacht, Dinge liegen zu lassen, wenn anderes dazwischenkam.

Die Website ist also massgeschneidert. Wir haben einen Ablauf gebaut, der die Datei mit der Wochenkarte nimmt, die sie ohnehin für Social Media erstellt, sie ausliest und auf die Website stellt. Die Karte steht auf der Seite selbst, eingebettet ins Design. Ein PDF-Download ist auch da, für alle, die noch eines möchten. Reservationen kommen über ein Formular herein und landen in den Systemen, die sie tatsächlich benutzt. Kerzenbestellungen laufen genauso.

Die Liste dieser Woche

Barbara hatte eine kleine laufende Liste. Nichts Dramatisches. Die Art von Dingen, die auf einem normalen Firmen-Stack "das schauen wir uns nächstes Quartal an" heissen würde.

Das Reservationsformular hatte sich stillschweigend von ihrem CRM und von der Geschäftsadresse gelöst, die es hätte erreichen sollen. Wieder verbunden. Die Zeitauswahl bot Termine an, die es gar nicht gab. Im Grunde gelogen. Behoben. Das Formular nahm leere Pflichtfelder an, ohne jemandem zu sagen, was fehlt. Jetzt sagt es das. Kleinigkeiten. Die Sorte, über die man einzeln nicht in Aufregung gerät, die zusammen aber den Unterschied machen zwischen einer Website, die funktioniert, und einer, die stillschweigend Buchungen verliert.

Die ganze Liste hat weniger Zeit gebraucht, als ihre Espressomaschine zum Aufwärmen braucht.

Woher das Tempo kommt

Jede Änderung läuft durch ein Audit, bevor sie ausgeliefert wird. Auch die von dieser Woche, auch die winzigen. Die Audits habe ich selbst gebaut, Code-Prüfungen auf der technischen Seite und Design-Prüfungen auf der visuellen. Sie sind auf jeder Website wiederverwendbar, an der ich arbeite, und der Build-Agent kennt sie, sie greifen also automatisch, bevor irgendetwas live geht. Die Messlatte sinkt nicht, nur weil die Änderung klein ist.

Das andere Stück ist, wie Funktionen dazukommen und wieder verschwinden. Wir beschreiben, was wir wollen, das Werkzeug baut es. Wir beschreiben, was weg soll, es geht weg. Es gibt kein CMS, das man durchsuchen muss, um zu sehen, ob eine Fähigkeit existiert. Keinen Plugin-Marktplatz zum Preisvergleich. Kein Modul von Dritten, das die Sache fast erledigt. Wenn die Fähigkeit nicht da ist, bauen wir sie.

Weg ist der Koordinationsaufwand. Die Ticket-Warteschlange, das Terminieren von Übergaben, die vier Leute, die bei einer so kleinen Änderung im Verteiler wären. Die Audits bleiben. Das Bauen auf Zuruf bleibt. Der Koordinationsaufwand geht. Und dieses Modell skaliert. Was für ein ländliches Schweizer Restaurant funktioniert, funktioniert für jedes Kleinunternehmen überall.

Ein Entwicklerteam aus einer Person

Die Bilder, die sie hatte, waren ... nun ja, sagen wir: nicht grossartig. Also habe ich einen Ablauf gebaut, der sie beim Hochladen optimiert. Nur Qualität und Hintergrundbereinigung, die Sorte, die aufhört, bevor ihr echtes Essen "zu viel KI" abbekommt. Auf ihre Bedürfnisse zugeschnitten. So etwas bekommt man aus keiner Vorlage, und normalerweise bräuchte man ein Entwicklerteam dafür.

Das ist der Teil der KI-Debatte, den ich interessanter finde als den meisten Rest. Ein Kleinunternehmen ohne Budget für einen Entwickler und ohne Geduld für eine Agentur kann jetzt eine echte Website haben, mit echten Funktionen, die zum echten Arbeitsablauf passen, betreut von jemandem, dem das Geschäft wirklich am Herzen liegt. Barbaras Entwicklerteam ist ihr Bruder. Das ist alles. Das ist das ganze Organigramm.

Die Frage, zu der ich immer wieder zurückkomme: Wie viele Kleinunternehmen bekommen demnächst die Software, die sie immer gebraucht und sich nie leisten konnten? Wahrscheinlich alle.

Übrigens: Wenn Sie in Zürich sind, schauen Sie vorbei. Ihr Lokal finden Sie hier. Bestellen Sie die Tagesempfehlung.

Und weil Sie es bis ganz ans Ende geschafft haben, noch eine kleine Bitte. Das Nächste auf Barbaras Liste ist, die Website an ihr Kassensystem anzubinden, ein Lightspeed K-Series. Wenn jemand, der das liest, uns zu einer Entwicklerlizenz verhelfen kann, geht eine Runde bei ihr auf uns. Eine schöne Getränkekarte hat sie nämlich auch.