Ein kanadisches Beratungsunternehmen
Härtung einer Lovable-Anwendung, direkt in Lovable.
- Kunde
- Ein Beratungsunternehmen, Kanada
- Branche
- Beratungs- & Advisory-Dienstleistungen
- Umfang
- Sicherheits-Audit, Refactoring, UX/UI-Optimierung, Feature-Entwicklung
- Dauer
- 3 Monate
- Umgebung
- Lovable.dev, beibehalten
Ausgangslage
Das Team des Kunden hatte das Tool selbst gebaut. Unter Verwendung von Lovable.dev erstellten Berater, die die Arbeit verstanden, nicht die Technologie, eine interne Plattform, die ihre Beratungsmethodik in Software verwandelte: strukturierte Kundenbewertungen, Datenerfassung, Analysen und Ergebnisse, die ihre Berater direkt dem Kunden präsentieren konnten.
Der Prototyp funktionierte. Das war sein Zweck, und er hatte das Konzept intern bereits bewiesen.
Was er noch nicht durchlaufen hatte, war die Prüfung, die erforderlich ist, bevor ein Tool echte Kundendaten verarbeitet. Beratungsunternehmen verarbeiten vertrauliche Informationen anderer als Bedingung des Mandats. Bevor dies Teil der tatsächlichen Arbeitsweise der Firma werden konnte, musste jemand die schwierigen Fragen beantworten: Wer kann was sehen, was ist exponiert, was passiert, wenn etwas schiefgeht.
Sie holten WOLKK für drei Monate an Bord, um daraus ein praxistaugliches System zu machen.
Eine Bedingung: In Lovable bleiben
Der Kunde wollte weiter darauf aufbauen. Seine Berater hatten gelernt, in Lovable Prototypen zu erstellen, und diese Fähigkeit galt es zu bewahren, die Alternative wäre gewesen, dass jede zukünftige Änderung zu einem Ticket für einen Entwickler wird.
Das Briefing lautete daher nicht „baut das ordentlich neu“. Es lautete: Macht es sicher, macht es gut und hinterlasst es in einem Zustand, in dem unsere eigenen Leute weiter daran arbeiten können.
Das prägte alles. Wir arbeiteten in der Lovable-Umgebung, anstatt die Codebasis in ein konventionelles Entwicklungs-Setup zu exportieren, was in mancher Hinsicht eingeschränkter ist, aber vollkommen machbar, wenn man die Einschränkungen versteht. Den Code so strukturieren, dass das Tooling sich darin zurechtfindet, Muster konsistent halten, die sensible Logik dorthin verlagern, wo sie nicht durch einen unbedachten Prompt aufgehoben werden kann.
Was wir getan haben
Phase 1, Audit
Wir begannen mit der Sicherheitsüberprüfung, bevor wir irgendetwas anrührten. Die Ergebnisse entsprachen dem typischen Muster KI-generierter Anwendungen: Zugriffskontrollen in der Benutzeroberfläche statt auf der Datenebene durchgesetzt, zu weit gefasste Datenbankrichtlinien, Zugangsdaten weiter vorne erreichbar als sie sein sollten und kein konsistentes Fehlerhandling. Nichts davon war Nachlässigkeit, das sind Dinge, die ein Prototyp nicht lösen soll und nach denen die promptende Person nicht zu fragen weiß. Wir lieferten einen schriftlichen Bericht, der Launch-Blocker von technischen Schulden und vollkommen intakten Elementen trennte. Der Kunde sah genau, womit er es zu tun hatte, bevor er sich zu den weiteren Arbeiten verpflichtete.
Phase 2, Refactoring und Härtung
Sicherheit. Die Autorisierung wurde serverseitig verlagert und auf Datenbankebene durchgesetzt. Row-Level-Policies wurden neu geschrieben, sodass Benutzer nur noch auf die Daten der eigenen Firma und der eigenen Kunden zugreifen können. Secrets wurden aus allen für den Browser erreichbaren Bereichen entfernt. Durchgehende Eingabevalidierung und solides Fehlerverhalten. Struktur. Duplizierte Logik wurde konsolidiert, dieselbe Berechnung war an mehreren Stellen mit leicht unterschiedlichen Ergebnissen implementiert worden. Komponenten wurden aufgeteilt und so strukturiert, dass sowohl die Berater des Kunden als auch Lovable selbst in der Codebasis arbeiten können, ohne an anderer Stelle etwas zu beschädigen. Zuverlässigkeit. Ordentliches Error-Handling statt leerer Bildschirme. Validierung eingehender Daten, damit den Analyseergebnissen vertraut werden kann.
Phase 3, Nutzerführung und UI
Der Prototyp funktionierte, weil die Personen, die ihn gebaut hatten, wussten, wo sich alles befand. Das hält dem Kontakt mit dem Rest der Firma nicht stand. Wir haben den Ablauf daran ausgerichtet, wie ein Berater sich tatsächlich durch ein Projekt bewegt, was bei jedem Schritt benötigt wird, was warten kann und was nie mehr als einen Klick entfernt sein sollte. Weniger Bildschirme, weniger erneutes Eingeben derselben Informationen, klarerer Status an jedem Punkt. Die Benutzeroberfläche wurde nach einem konsistenten Designsystem neu aufgebaut, sodass neue Bildschirme nun dazugehören, anstatt nach der Woche auszusehen, in der sie erstellt wurden.
Phase 4, Neue Funktionen
Mit einem soliden Fundament floss die verbleibende Zeit in das, was der Kunde als Nächstes wollte. Ideen, die während der Prototypenphase zurückgestellt worden waren, weil der Prototyp sie nicht tragen konnte, wurden umgesetzt: tiefere Analysen, bessere Ergebnisse für den Endkunden und Workflow-Verbesserungen, die direkt aus der Beobachtung der Berater bei der Nutzung des Tools hervorgingen. Einige davon stammten von unserer Seite und nicht aus dem Briefing des Kunden. Sobald das Team die Fachdomäne verstanden hatte, wurden die Lücken sichtbar.
Das Ergebnis
Nach drei Monaten verfügte der Kunde über ein funktionierendes Beratungstool im produktiven Einsatz, sicher, getestet an der tatsächlichen Arbeitsweise der Berater und weiterhin in der Umgebung, in der das eigene Team zu bauen versteht.
Dieser letzte Punkt ist der, den sie am meisten schätzen. WOLKK hat ihnen die Software nicht weggenommen. Ihre Berater erstellen weiterhin Prototypen und Erweiterungen; wir kommen für die Aufgaben hinzu, die Ingenieurskompetenz erfordern.
Warum dieses Modell funktioniert
Der Reflex bei einem KI-gebauten Prototyp ist es, ihn auf einem konventionellen Stack „richtig“ neu zu bauen. Manchmal ist das korrekt. Oft ist es das nicht, es verwirft funktionierende Fachlogik, kostet mehr als die Situation rechtfertigt und nimmt das Tool aus den Händen derer, die am besten verstehen, was es tun soll.
Die Alternative besteht darin, die KI-Umgebung als legitimen Ort für den Betrieb von Software zu behandeln und technische Disziplin einzubringen: echte Sicherheit, echte Struktur, echtes Testen. Das ist eine andere Aufgabe als ein Rewrite, und in diesem Fall war es die richtige.
Haben Sie etwas in Lovable gebaut, das bereit ist, ernst genommen zu werden? Beginnen Sie mit einem Audit. Wir sagen Ihnen, was solide ist, wo Risiken liegen und ob Sie bleiben oder wechseln sollten.