Ihre App läuft. Und sie wächst schneller, als Sie sie verstehen können.
Sie haben die Idee beschrieben, die KI hat den Code geschrieben, die App läuft und wird bereits genutzt. Dann geht etwas kaputt — und Sie sollen Code debuggen, den Sie nie geschrieben haben. Wir schauen von außen darauf und geben Ihnen eine Quittung: was bestätigt ist, was fehlerhaft ist und was niemand geprüft hat.
„Ich kann das nicht debuggen, ich habe diesen Code nicht geschrieben“ — und jeder kleine Fehler wird zu einem Abend voller Vermutungen.
Ihre Datenbankschlüssel liegen irgendwo im Seitencode und Sie wissen nicht sicher, ob das sicher ist.
Nach jedem Deploy sind Sie nicht sicher, ob das, was gestern lief, heute noch läuft.
So läuft es ab
01
Eine Prüfung von außen
Wir sehen die App so, wie ein gewöhnlicher Besucher sie sieht: Zertifikat, Erreichbarkeit, öffentlicher Seitencode, Build-Markierung. Wir zerstören nichts, ändern nichts und gehen nie in Ihren Code hinein.
02
Eine Quittung mit drei Zuständen
Jede Zeile erhält eines von drei Urteilen — bestätigt, fehlerhaft, nicht festgestellt — und die Adresse ihres Belegs. Eine Gesamtnote gibt es bewusst nicht: sie würde genau das verdecken, was Sie sehen müssen.
03
Ein fertiger Prompt für Ihre KI
Zu jeder fehlerhaften Zeile gehört ein Text, den Sie in Cursor, Lovable oder Claude Code einfügen — und Ihr Editor behebt es. Eine eigene Entwicklerin oder einen eigenen Entwickler brauchen Sie dafür nicht.
04
Ehrliches Veralten
Sie deployen — die Quittung tut nicht so, als sei weiterhin alles geprüft. Sie geht in „wartet auf erneute Prüfung“, bis wir wieder hinsehen. Eine alte Quittung, die still grün bleibt, ist schlimmer als gar keine.
So sieht eine Zeile der Quittung aus
Das sind echte Zeilen aus der Prüfung — nur an einer erfundenen App.
secret-scan:ihre-app.examplefehlerhaft
Im öffentlichen Seitencode wurde ein Supabase-Serviceschlüssel gefunden. Dieser Schlüssel umgeht alle Zugriffsregeln Ihrer Datenbank: wer ihn findet, liest und ändert alle Ihre Daten.
Fertiger Prompt für Ihren KI-Editor
Im öffentlichen Bundle meiner Web-App wurde ein Geheimnis gefunden. Finde es im Frontend-Code, entferne es aus dem Client-Bundle, verlagere alle Operationen damit auf die Serverseite (API-Route oder Edge Function), widerrufe dann den Schlüssel und stelle beim Anbieter einen neuen aus. Zeige den Diff und erkläre, was jetzt noch auf dem Client liegt.
secret-scan:andere-app.examplenicht festgestellt
Ein öffentlicher Supabase-Schlüssel wurde gefunden — das ist normal, dafür ist er da. Ob Ihre Tabellen aber durch Zugriffsregeln geschlossen sind, sieht eine Prüfung von außen nicht. Deshalb: nicht festgestellt, nicht „alles gut“.
tls:ihre-app.examplebestätigt
Das Domain-Zertifikat ist zum Prüfdatum gültig und nicht abgelaufen.
Einen gefundenen Schlüssel zitieren wir nie — weder im Bericht noch in einer E-Mail. Wir benennen die Klasse des Fundes und den Ort, damit die Quittung nicht zur zweiten undichten Stelle wird.
Lebende Belege statt Versprechen
Bevor Sie jemandem vertrauen, sehen Sie sich an, was dieses System wirklich tut. Beide Seiten sind offen und laufen jetzt gerade.
Markierungen, die an konkrete Commits gebunden sind — diese Website eingeschlossen. Bewegt sich der Code, geht die Markierung von selbst zurück auf „wartet auf erneute Prüfung“.
Was wir nicht versprechen
Das ist eine Selbsteinschätzung anhand der Prüfungen, die wir tatsächlich ausführen — kein Audit und keine Garantie.
„Nicht festgestellt“ heißt weder „alles gut“ noch „alles schlecht“. Es ist eine benannte Grenze: das haben wir nicht geprüft oder konnten es nicht.
Eine Gesamtnote gibt es nicht. Ein grüner Punkt über drei verschiedenen Zuständen ist genau das, was wir ablehnen.
Wir sehen von außen. Was nur von innen in Ihrem Code sichtbar ist, sieht eine Prüfung von außen nicht — und sagt das offen, statt zu schweigen.
Möchten Sie so eine Quittung für Ihre App?
Wir sind in geschlossener Beta und nehmen Apps einzeln an. Einen festen Bestellkanal gibt es noch nicht — und wir malen keinen Knopf, hinter dem niemand steht.