Wir haben eine Messe-App an einem Tag gebaut. Das steckt wirklich dahinter.

Die in-cosmetics Global ist die grosste Fachmesse der Kosmetik-Rohstoffindustrie. 983 Aussteller auf drei Ebenen der Paris Expo Halle 7. Drei Tage. Tausende Besucher, die im Kreis laufen, weil der offizielle Hallenplan ein PDF ist und die Ausstellerliste alphabetisch sortiert.

Wir haben einen Routenplaner gebaut, der das lost. Keine Anmeldung. Kein Login. Wahle deine Must-Visit-Aussteller, bekomme die kurzeste Laufroute uber alle drei Ebenen. Funktioniert offline, lasst sich wie eine native App installieren, lauft auf jedem Handy.

Der Build hat einen Tag gedauert. 31 Commits. So sah dieser Tag aus, und warum das fur jeden relevant ist, der nutzliche Tools schnell bauen will.

Das Problem, das niemand lost

Jede Messe hat dasselbe Problem. Du kommst mit einer Liste von 30 Standen an. Der Hallenplan gibt dir eine alphabetische Liste und eine statische Karte. Zur Mittagspause tun dir die Beine weh und du hast vielleicht 8 Namen abgehakt.

Die offizielle in-cosmetics App listet Aussteller auf. Sie routet dich nicht zwischen ihnen. Niemand hat das auf irgendeiner Messe, die ich in 15 Jahren besucht habe, richtig gelost. Nicht weil es unmoglich ist. Weil die Entwicklungskosten nie ein Tool gerechtfertigt haben, das drei Tage nutzlich ist.

Diese Rechnung hat sich geandert.

Was wir gebaut haben

Der Routenplaner auf incos.corial.app macht drei Dinge.

Erstens findet er begehbare Wege. Die App hat die echten Grundrissdaten fur alle drei Ebenen. Jeder Stand hat Koordinaten. Der Pfadfindungs-Algorithmus weiss, wo man laufen kann und wo Stande den Weg blockieren. Wahle zwei Punkte, und er findet die tatsachliche Laufroute dazwischen.

Zweitens optimiert er die Reihenfolge. Wenn du 15 Stande besuchst, ermittelt die App, welche Abfolge deine Laufstrecke minimiert. Das ist das Traveling-Salesman-Problem, eine der klassischen Optimierungsaufgaben der Informatik. Unser Solver nutzt eine Nearest-Neighbor-Heuristik plus einen 2-Opt-Optimierer, der Routensegmente tauscht, um kurzere Wege zu finden. Bis zu 50 Iterationen.

Drittens handhabt er Ebenenwechsel. Rolltreppen und Treppen sind an bestimmten Stellen in der Paris Expo Halle 7. Der Router weiss, wo sie sind, und berechnet das Distanzaquivalent eines Ebenenwechsels (etwa 60 Meter) ein, damit er die richtige Rolltreppe wahlt statt dich ans andere Ende des Gebaudes zu schicken.

Das Ganze lauft client-seitig im Browser. Kein Server. Keine API-Aufrufe. Installiere es auf deinem Handy und es funktioniert ohne Internet. Drei Tage Messe, null Abhangigkeit vom Venue-WLAN.

Der Teil, der nichts mit Engineering zu tun hat

Der Smart-Modus findet die kurzeste Route. Das ist das offensichtliche Feature. Jeder Routenplaner macht irgendeine Version davon.

Der Fitness-Modus findet die langste Route.

Gleiches algorithmisches Framework, gegensatzliches Ziel. Statt Nearest-Neighbor nutzt er Farthest-Neighbor-Heuristik. Statt Routensegmente zu verkurzen, lauft der 2-Opt ruckwarts und tauscht Segmente, um die Route zu verlangern. Die App trackt Kilometer, verbrannte Kalorien und Schritte.

Ich habe einen Algorithmus gebaut, der deine Route absichtlich schlechter macht. Leute nutzen ihn unironisch.

Dieses Feature kam nicht aus einem Pflichtenheft. Es kam vom Kennen der Zielgruppe. Messebesucher in Kosmetik und Biotech reden uber ihre Schrittzahlen. Es ist ein Running Gag. "Ich hatte gestern 22.000 Schritte." "Nur 22? Amateur."

Der Fitness-Modus hat ein Werkzeug in etwas verwandelt, das Leute screenshotten und teilen. Diese Art von Produktentscheidung kommt nicht aus Code. Sie kommt aus 15 Jahren in diesen Hallen.

Der Build: ein Tag, 31 Commits

Hier ist der ehrliche Breakdown, wie KI-gestutzte Entwicklung bei diesem Projekt aussah.

Claude Code schrieb den A*-Pfadfindungs-Algorithmus. Es schrieb den TSP-Solver. Es ubernahm das Floor-Plan-Rendering, das Koordinaten-Mapping, das responsive Layout. Ich habe keine Pfadfindung von Grund auf geschrieben. Ich habe das Problem beschrieben, den Output gepruft, auf meinem Handy getestet und den Kurs korrigiert.

Was ich gemacht habe: jede Produktentscheidung. Welche drei Routing-Modi gebaut werden. Wie etagenubergreifendes Routing funktionieren soll. Das Fitness-Modus-Konzept. Die UI-Prioritaten. Was wegfallt. Wann wir shippen.

Dieser Split ist die ganze Geschichte. KI ubernimmt die Implementierungsgeschwindigkeit. Der Mensch ubernimmt Branchenwissen und Produkturteil. Keiner funktioniert allein.

Vor zwei Jahren hatte ein Projekt wie dieses einen Entwickler fur mindestens eine Woche gebraucht. Frontend, Pfadfindungs-Logik, PWA-Konfiguration, Responsive-Testing, Offline-Support. Nenn es 40-60 Stunden Arbeit. Heute braucht es eine Person mit Branchenwissen und KI-Tools einen fokussierten Tag.

Das ist keine marginale Verbesserung. Das verandert, was es wert ist gebaut zu werden.

Der Stack

Fur alle, die neugierig auf die technischen Entscheidungen sind.

Astro plus Svelte als Framework. Astro ubernimmt Static Site Generation und Routing. Svelte ubernimmt die interaktiven Komponenten, das Map-Rendering, die Routenberechnungs-UI. Schnell, leichtgewichtig, kein unnotiges JavaScript.

TailwindCSS fur Styling. TypeScript durchgehend. Die App ist eine Progressive Web App, installierbar aus dem Browser mit vollem Offline-Support uber Service Workers.

A*-Pfadfindung lauft auf einem Walkability-Grid, das aus echten Stand-Koordinatendaten abgeleitet wird. Der Grundriss wird in Zellen aufgeteilt. Stand-Zellen sind mit einem kleinen Rand blockiert. Der Pathfinder navigiert begehbare Zellen, um beliebige zwei Punkte zu verbinden.

Alles lauft im Browser. Kein Backend. Keine Datenbank. Keine API-Keys. Deployen, vergessen.

Was das beweist

Der Routenplaner funktioniert. Leute nutzen ihn. Aber der eigentliche Punkt ist, was der Build uber Geschwindigkeit aussagt.

Ein nutzliches Tool fur eine spezifische Zielgruppe. Technisch solide, kein Prototyp. An einem Tag geshippt. Keine laufenden Wartungskosten.

Wenn du ein Nischen-B2B-Unternehmen bist und uber Tools fur deine Kunden, deine Messe, deine Community nachdenkst: Die Rechnung hat sich geandert. Die Frage war fruher "Konnen wir es uns leisten, das zu bauen?" Jetzt ist die Frage "Welches Problem kennen wir gut genug, um es zu losen?"

Bei dieser zweiten Frage wird Branchenexpertise zum Engpass, nicht Entwicklungszeit. In dieser Lucke arbeiten wir. Branchen tief genug kennen, um zu bauen, was sie tatsachlich brauchen.