Feldnotiz: Pilotprojekt für KI-App
Die erste Lovable-App: Checkliste vor der Veröffentlichung
Ein praktisches „Lovable“-Pilotprojekt: Erstellen Sie ein eng gefasstes Briefing, richten Sie einen Anfrage-Tracker mit fiktiven Daten ein, testen Sie Berechtigungen und Kosten und entscheiden Sie, ob das Projekt für den realen Einsatz bereit ist.
Der einfachste Weg, einen Nachmittag mit einem App-Builder zu verschwenden, besteht darin, nach einem „vollständigen CRM“ zu fragen und zu hoffen, dass es die Aspekte Ihres Unternehmens versteht, die nur in jemandes Kopf existieren. Beginnen Sie stattdessen mit einer unangenehmen Aufgabe. Diese Checkliste basiert auf dem Beispiel eines fiktiven Geräteverleihs, der Kundenanfragen nachverfolgen möchte. Passen Sie die Details an Ihre Arbeit an; behalten Sie den engen Umfang bei.
Der Einstiegsleitfaden von Lovable erklärt den Weg von der ersten Eingabe über die Vorschau bis zur veröffentlichten URL. Dieser Artikel ergänzt den geschäftlichen Rahmen und konkrete Abnahmekriterien. Es handelt sich um eine Planungsübung auf Grundlage der Herstellerdokumentation, nicht um einen Bericht über einen Praxistest oder eine Garantie für die Sicherheit einer generierten App.
1. Wählen Sie eine Aufgabe und einen Verantwortlichen aus
Die Aufgabe lautet: Ein Mitarbeiter erfasst eine Anfrage, weist sie einem Verantwortlichen zu, aktualisiert ihren Status und kann sie am nächsten Tag wiederfinden. Der Verantwortliche ist der Betriebsleiter. Wenn es keinen Verantwortlichen gibt, wird die neue App wahrscheinlich zu einer hübscheren Version der Tabellenkalkulation, die niemand aktualisiert.
Lassen Sie für das erste Pilotprojekt Zahlungen, automatisierte E-Mails, Kundenkonten, Bestandsabgleich und KI-Zusammenfassungen außer Acht. Jedes zusätzliche System führt einen neuen Ausfallmodus ein. Sie können später einen hinzufügen, wenn der Basis-Tracker eine Woche realistischen Einsatzes übersteht.
2. Schreiben Sie den Eintrag vor dem Bildschirm
Führen Sie die Informationen auf, die der Tracker benötigt. In diesem Beispiel:
| Feld | Warum es existiert | Vor der Veröffentlichung prüfen |
|---|---|---|
| Anfrage-ID | Jede Anfrage unabhängig vom Kundennamen identifizieren | Ist die ID eindeutig und für das Team sichtbar? |
| Kundenname und Kontaktdaten | Antwort an die Person | Ist sie nur für autorisierte Mitarbeiter sichtbar? |
| Gewünschtes Gerät und Termine | Den Kundenwunsch verstehen | Können Mitarbeitende Tippfehler korrigieren? |
| Status | Neue, geprüfte, angebotene und abgeschlossene Anfragen verfolgen | Sind Statuswechsel klar geregelt? |
| Eigentümer und nächste Maßnahme | Verhindern Sie, dass Anfragen verschwinden | Können Mitarbeiter überfällige Aufgaben finden? |
Verwenden Sie im Pilotprojekt fiktive Namen und E-Mail-Adressen. Ein Prototyp benötigt keine Kundenliste, um zu beweisen, dass eine Status-Schaltfläche funktioniert.
3. Geben Sie Lovable ein Briefing, das es prüfen kann
Fügen Sie einen Text wie diesen ein und passen Sie ihn dann an Ihre Situation an:
Erstellen Sie eine private App zur Bearbeitung von Anfragen für einen Geräteverleih mit drei Mitarbeitenden. Das Team soll Anfragen erstellen, bearbeiten und suchen können. Jede Anfrage benötigt eine eindeutige ID, Name und Kontaktdaten des Kunden, gewünschtes Gerät und Termine, einen Status (neu, in Prüfung, Angebot versendet oder abgeschlossen), eine zuständige Person, die nächste Maßnahme und deren Frist. Verwenden Sie ausschließlich fiktive Beispieldaten. Vor der Anzeige von Anfragen muss eine Anmeldung erfolgen. Fügen Sie keine Zahlungen, Kundenkonten, automatischen E-Mails oder öffentlichen Seiten hinzu. Zeigen Sie zuerst das Datenmodell und die Zugriffsregeln und warten Sie vor der Umsetzung auf meine Bestätigung. Sorgen Sie für eine einfache mobile Ansicht und einen Export der Anfragen. Benennen Sie alles, was Sie nicht überprüfen können.
Der wertvolle Teil sind die Grenzen: Was die App leisten muss, was sie noch nicht leisten kann und was vor der Entwicklung geprüft werden sollte. Eine Eingabeaufforderung kann Sicherheit nicht allein durch eine Deklaration gewährleisten. Dadurch lassen sich Anforderungen leichter überprüfen.
4. Testen Sie die Funktion, nicht den Screenshot
Sobald Sie eine Vorschau haben, erstellen Sie fünf fiktive Anfragen. Weisen Sie zwei Einträgen denselben Kundennamen zu, ändern Sie das Datum eines Eintrags, weisen Sie einen anderen Eintrag einem Kollegen zu, schließen Sie einen Eintrag und suchen Sie anhand der ID nach einer offenen Anfrage. Probieren Sie den Ablauf auf einem Smartphone aus. Der zukünftige Eigentümer soll den Text ohne Hilfestellung vervollständigen können.
Halten Sie Mängel als Beobachtungen fest und nicht als neue Gestaltungswünsche. „Der Eigentümer kann die heute fälligen Anfragen nicht finden“ ist umsetzbar. „Machen Sie es hochwertiger“ kann warten. Dokumente wie Vorschau- und Testtools sind zwar gut, aber die Akzeptanzkriterien müssen weiterhin vom Unternehmen kommen.
5. Prüfen Sie, wer welche Inhalte sehen kann
Falls die App personenbezogene Daten speichert, testen Sie den Zugriff gezielt. Erstellen Sie ein zweites Mitarbeiterkonto, melden Sie sich ab und versuchen Sie, eine Anfrage direkt zu öffnen. Versuchen Sie, eine Datensatz-ID in der URL zu ändern. Stellen Sie sicher, dass exportierte Daten nur den berechtigten Personen zugänglich sind. In „Lovable’s Sicherheitshinweise“ wird erläutert, warum Frontend-Prüfungen allein nicht ausreichen und warum die Sicherheit auf Datenbankzeilenebene überprüft werden muss.
Überprüfen Sie vor der Veröffentlichung die Sicherheitsergebnisse des Projekts. Fügen Sie keine privaten API-Schlüssel in die sichtbare Benutzeroberfläche oder in eine Eingabeaufforderung ein, die als Frontend-Code vorgesehen ist. Falls es im Unternehmen niemanden gibt, der die Zugriffsregeln bewerten kann, lassen Sie die App so lange mit fiktiven Daten laufen, bis eine qualifizierte Überprüfung erfolgen kann.
6. Geben Sie dem Pilotprojekt eine Nummer
Legen Sie vor der Iteration ein Limit für Zeit und Credits fest. „Lovable“ unterscheidet bei Preisseite zwischen dem für die Erstellung verwendeten Kontingent und den von einer laufenden App genutzten Ressourcen, während Anwendungsansicht den Hosting- und Backend-Verbrauch anzeigt. Erfassen Sie den Anfangssaldo, den Saldo nach der ersten Version und den Saldo nach jeder größeren Fehlerbehebung. Schätzen Sie anschließend einen Monat bei normaler Nutzung.
Wenn wiederholte Aufforderungen immer wieder denselben fehlerhaften Arbeitsablauf zur Folge haben, brechen Sie den Vorgang ab. Formulieren Sie die Regel in einfacher Sprache um, entfernen Sie optionale Funktionen oder bitten Sie einen Entwickler, den Code zu überprüfen. Mehr Hinweise sind kein Ersatz für eine klarere Entscheidung.
7. Das Verlassen der Seite proben
Exportieren Sie eine Stichprobe Ihrer fiktiven Anfragen und vergewissern Sie sich, dass Sie diese außerhalb der App lesen können. „Lovable Documents“ Git-Synchronisierung für Code – doch Code ist nur ein Teil eines Ausstiegsplans: Man muss auch Daten, Dateien, Benutzer und geheime Informationen verstehen. Beauftragen Sie eine Person damit, diese Unterlagen zu ordnen.
Veröffentlichen Sie den Beitrag nur, wenn diese Fragen mit „Ja“ beantwortet werden
- Kann der zukünftige Eigentümer die Kernaufgabe ohne Hilfe bewältigen?
- Werden die fünf Beispielanfragen bei der Bearbeitung, Suche und beim Export beibehalten?
- Wurden die Zugriffsregeln mit mehr als einem Konto getestet?
- Sind alle Kundendaten bis zum Abschluss der Datenschutz- und Sicherheitsprüfung weiterhin fiktiv?
- Liegen die Kosten für die zweiwöchige Testphase innerhalb des von Ihnen festgelegten Rahmens?
- Ist nach der Markteinführung jemand für Updates und die Reaktion auf Vorfälle zuständig?
Wenn eine Antwort „Nein“ lautet, haben Sie etwas Nützliches gefunden: ein konkretes Problem, das gelöst werden muss, bevor echte Kunden sich auf die App verlassen. Für eine umfassendere Produktübersicht siehe unsere Lovable-Analyse und Vergleich Lovable und Wix. Ein kleines, erfolgreiches Pilotprojekt ist besser als ein großartiges Dashboard, dem niemand vertraut.