Lab

Es läuft. Nur darf es so nicht in Betrieb.

Die Fachabteilung hat sich das Tool selbst gebaut, und die IT gibt es nicht frei. Der MVP steht, aber der erste zahlende Kunde stellt Fragen zur Datenhaltung. Im Haus laufen inzwischen vier selbstgebaute Anwendungen, und niemand weiß, welche davon ein Problem ist.

In allen drei Fällen ist dieselbe Frage offen: Was fehlt bis zur Produktionsreife, und was kostet es?

Prototypen scheitern selten an der Funktion.

Sie scheitern an dem, was der Baukasten nicht mitgebaut hat. Vier Achsen, in denen wir nachsehen — mit den Befunden, die wir tatsächlich finden.

Nachts im Labor: Auf der Werkbank läuft ein mit Klebeband geflicktes Gerät mit offener
Platine. Der Nighthog im blauen Shirt prüft es skeptisch mit einem Messgerät, der
Blechroboter hält eine lange Prüfliste

Achse 1/4 · Sicherheit

  • Secrets und API-Keys, die im Client-Bundle mit ausgeliefert werden
  • Fehlende oder umgehbare Autorisierung — etwa abgeschaltetes Row Level Security
  • Validierung, die nur im Frontend stattfindet
  • Endpunkte, die ohne Anmeldung erreichbar sind

Zwei Pakete. Beide enden mit einem Urteil, nicht mit einem Angebot.

Fixpreis, feste Dauer, festes Ergebnis. Was danach passiert, entscheidet ihr — auch gegen uns.

Was in den Tagen passiert.

Die vollständige Codebasis wird gelesen, nicht stichprobenartig geprüft — genau deshalb ist ein Fixpreis über drei oder fünf Werktage überhaupt möglich. Bewertung, Priorisierung und das Urteil kommen von Menschen.

  1. Schritt 1

    Zugang und Eingrenzung

    Wir sehen uns an, was ihr gebaut habt und wofür es benutzt wird. Wozu die Anwendung dienen soll, entscheidet mit, welche Befunde überhaupt zählen.

  2. Schritt 2

    Vollständiger Lesedurchlauf

    Die gesamte Codebasis wird gelesen — dazu Konfiguration, Abhängigkeiten und die Dienste, an denen die Anwendung hängt.

  3. Schritt 3

    Nachstellen statt behaupten

    Wo sich ein Befund reproduzieren lässt, stellen wir ihn nach, bevor er in den Bericht kommt. Was sich im Zeitrahmen nicht nachstellen ließ, steht mit genau diesem Vermerk drin — als Verdacht, nicht als gesicherter Fund.

  4. Schritt 4

    Priorisierung und Urteil

    Die Befunde werden nach Schweregrad sortiert, nicht nach Regelverstoß. Dazu das Urteil zur Härtbarkeit und die Aufwandsspanne für den nächsten Schritt.

  5. Schritt 5

    Ergebnisgespräch

    Wir gehen den Bericht mit euch durch und beantworten, was offen geblieben ist.

  • Zugriff auf das Repository oder einen Export aus dem Baukasten
  • Zugang zu einer laufenden Instanz — eine Kopie genügt
  • Eine Ansprechperson für Rückfragen zum Fachprozess

Drei mögliche Wege. Einer davon führt an uns vorbei.

Keine Rechtsberatung, kein Penetrationstest, keine Zertifizierung. Wir prüfen technisch und benennen, wo ihr juristischen Rat braucht — die Bewertung selbst ist nicht unsere.

Standardmäßig arbeiten wir mit Claude Code. Auf Wunsch läuft die Prüfung über eine Plattform mit EU-Hosting oder vollständig auf lokalen Modellen — dann verlassen euer Code und eure Daten eure Umgebung nicht.

Geht es nicht um einen Prototyp, sondern um gewachsene Bestandssoftware, ist dieCode-Analyse & Auditdie passende Leistung — dort lautet die Frage „erweitern, ablösen oder ersetzen?".

Schickt uns, was ihr habt.

Kurze Beschreibung genügt für den Anfang: womit gebaut, was es tut, wer es nutzen soll. Wir sagen euch, welches Paket passt — und wenn keines passt, auch das. Antwort innerhalb eines Werktages.

Prüfung anfragen
Gebaut aus Tokens, nicht aus Stock-Fotos. Keine Cookies an Bord.