Code-Review für selbst gebaute Software.

370.000+

Zeilen Code geprüft

fast 500

Datenbank-Zugriffsregeln geprüft

170+

belegte Befunde und Maßnahmen

5 Werktage

bis zum Kompakt-Bericht

Selbst gebaut — und jetzt? Die drei Fragen vor dem Launch

Wer eine Anwendung selbst gebaut hat, kennt jede Funktion. Was man beim Bauen nicht sieht, ist das Fundament darunter. Bevor echte Daten, Kunden oder Zahlungen dazukommen, sollten diese drei Fragen eine belastbare Antwort haben:

Für wen sich ein Code-Review lohnt

Immer dann, wenn viel an einer Software hängt, die ohne klassisches Entwicklerteam entstanden ist — oder die jemand anderes gebaut hat:

Wie Unternehmen mit selbst gebauter Software umgehen können, ohne sie zu verbieten: Citizen Developer & Schatten-IT — wenn Mitarbeiter mit KI eigene Software bauen. Für Investoren und Käufer gibt es eine eigene Prüfung: die technische Due Diligence vor Investment oder Kauf.

Was ist ein Code-Review bzw. Code-Audit?

Ein Code-Review ist die systematische Prüfung einer Software durch erfahrene Entwickler — auf Code-Qualität, Architektur, Sicherheit und konkrete Fehler. Ein Code-Audit weitet das auf Datenbank, Datenschutz, Wiederherstellbarkeit und Betrieb aus. Aus Käufer- oder Investorensicht heißt dieselbe Prüfung technische Due Diligence. Bei selbst gebauter Software kommt eine vierte Frage hinzu: Wer betreibt das System, wenn es wichtig wird? Ziel ist immer eine ehrliche, priorisierte Entscheidungsgrundlage — was vor dem Livegang gelöst sein muss und was warten kann.

Was wir prüfen

Was wir in selbst gebauten Anwendungen immer wieder finden

Typische Muster in Anwendungen, die mit Lovable, Cursor und ähnlichen Werkzeugen entstehen. Allgemeine Erfahrungswerte — keine Aussage über ein bestimmtes Kundenprojekt:

// src/lib/supabase.ts — läuft im Browser
const supabase = createClient(
  url,
  import.meta.env.VITE_SUPABASE_SERVICE_KEY
)

// Browser: nur der öffentliche Schlüssel
const supabase = createClient(
  url,
  import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY
)
// Vollzugriff nur noch in Serverfunktionen

Die gute Nachricht: Kaum etwas davon erzwingt einen Neubau. Das meiste lässt sich gezielt beheben, und genau diese Einordnung liefert der Bericht. Warum KI-Werkzeuge diese Muster so oft erzeugen, erklärt der Ratgeber Vibe Coding: Risiken und 10-Fragen-Check.

Was alle bisher geprüften Eigenbauten gemeinsam hatten

Über alle bisherigen Code-Reviews und Abnahmeprüfungen haben wir mehr als 370.000 Zeilen Code, fast 500 Zugriffsregeln und fast 300 Datenbankänderungen geprüft (Stand Oktober 2026). Details aus einzelnen Kundenprojekten veröffentlichen wir nicht.

In jedem bisher geprüften selbst gebauten System …

• ●gab es Go-live-Blocker, die vor dem Betrieb mit echten Kunden geschlossen sein mussten
• ●war die Wiederherstellung aus dem Backup noch nie praktisch erprobt
• ●waren hochgeladene Dateien nicht vollständig gesichert
• ●fehlte eine Fehlerüberwachung — Störungen wären erst durch Nutzer aufgefallen
• ●ließ sich der übergebene Stand nicht ohne Korrekturen frisch bauen
• ●gab es keine automatisierten Tests für die Zugriffsregeln

Und in keinem davon war ein Neubau die bessere Lösung: Die Empfehlung lautete jedes Mal, auf dem vorhandenen Code gezielt nachzubessern und in Stufen live zu gehen. Beim Bauen achtet kaum jemand auf Wiederherstellung, Überwachung und Tests — im Ernstfall entscheiden genau sie.

DSGVO: was wir bei Supabase, Lovable & Vercel prüfen

Die meisten KI-Werkzeuge setzen auf US-Anbieter. Das ist kein Ausschlussgrund — aber es braucht eine bewusste Konfiguration und lückenlose Verträge. Für den dauerhaften Betrieb mit Personendaten empfehlen wir meist den einfacheren Weg: einen eigenen Server in Deutschland mit PostgreSQL. Geprüft wird in jedem Fall:

• ✓Region der Datenbank (EU, etwa Frankfurt) und wo Logs, Auth-Mails und Dateien landen
• ✓Auftragsverarbeitungsverträge für jeden Dienst im Datenfluss — inklusive KI-APIs
• ✓Übermittlungen in die USA: Data Privacy Framework, Standardvertragsklauseln, CLOUD Act
• ✓Zugriffsregeln, die personenbezogene Daten wirklich pro Nutzer trennen
• ✓Dokumente: private Ablage, kurzlebige Freigaben, Zugriffsprotokoll
• ✓Auskunft, Export und Löschung — technisch umsetzbar statt nur versprochen

Wichtig: Wir liefern technische Feststellungen, keine Rechtsberatung. Der Bericht ist so geschrieben, dass dein Datenschutzbeauftragter oder deine Rechtsberatung damit arbeiten kann. Hintergrund, Regionen und AVV-Wege im Ratgeber Supabase, Lovable & Vercel DSGVO-konform betreiben.

So läuft ein Review ab

1. 1

   Erstgespräch & Sichtung

   Du zeigst uns, was du gebaut hast und wofür. Wir sichten Stack und Repository-Struktur kurz und machen dir ein Festpreis-Angebot.

2. 2

   Vereinbarungen & Zugänge

   Auftragsverarbeitungsvertrag, dann lesender Zugriff auf Repository (mit Historie), Datenbank-Struktur und Hosting-Konfiguration sowie eine Liste der eingebundenen Dienste. Keine Schreibrechte, keine Datensätze.

3. 3

   Prüfung

   Automatisiert über den gesamten Bestand, manuell in der Tiefe an den Stellen mit dem höchsten Schadenspotenzial. Finden wir ein unmittelbares Risiko, melden wir es noch am selben Tag — nicht erst mit dem Bericht.

4. 4

   Bericht & Ergebnis-Call

   Befunde nach Schwere, je mit Beleg, Auswirkung in verständlicher Sprache und Empfehlung. Dazu Kennzahlen, Ampel und Handlungsplan. Wir gehen alles gemeinsam durch; danach entziehen wir alle Zugänge.

5. 5

   Optional: Behebung, Stufen-Launch & Betrieb

   Wir schließen die Go-live-Blocker, nehmen die Anwendung in Stufen live und übernehmen den laufenden Betrieb — während du weiter Funktionen baust.

So prüfen wir — und was ausdrücklich nicht dazugehört

Was du am Ende in der Hand hast

Nach dem Launch: Du baust weiter, wir betreiben

Selbst gebaute Software lebt davon, dass die Menschen, die das Geschäft verstehen, sie weiterentwickeln. Das soll so bleiben. Was sie dafür nicht nebenher leisten sollten, übernehmen wir:

Unsere Standardempfehlung für den Betrieb: ein eigener Server bei einem deutschen Anbieter wie Hetzner mit PostgreSQL — ein Vertragspartner, kein US-Anbieter im Kern, planbare Kosten. Bewusst nicht: Kubernetes, Microservices oder Datenbank-Replikate ohne gemessenen Bedarf. Vorsorgliche Komplexität kostet im Betrieb mehr, als sie löst — die Infrastruktur wächst erst, wenn die Zahlen es verlangen. Wie Export, Hosting und Betrieb einer Lovable-App konkret aussehen: Lovable-App exportieren, hosten und betreiben.

Was ein Review kostet

Das hängt am Umfang — Zahl der Serverfunktionen, Komplexität von Datenmodell und Zahlungsflüssen — und variiert stark. Deshalb nennen wir hier bewusst keine Zahl ins Blaue. Im kostenlosen Erstgespräch sichten wir Repository und Stack kurz und machen dir dann ein verbindliches Festpreis-Angebot.

Kostenloses Erstgespräch

30 Minuten, in denen wir Stack und Repository-Struktur kurz sichten und dir sagen, ob ein Kompakt-Review reicht oder ein Voll-Audit sinnvoll ist. Unverbindlich, ohne Verkaufsdruck. Auf Wunsch unterschreiben wir vorher eine NDA.

Erstgespräch sichern

Für Behebung, Stufen-Launch und laufenden Betrieb erstellen wir nach dem Review ein separates Angebot — auf Basis der tatsächlichen Befunde.

Wer dein Review macht

Moritz Lehmann

Geschäftsführer adfera · M.Sc. Wirtschaftsinformatik · BAfA-akkreditierter Berater

Leitet jedes Review und ist dein Ansprechpartner vom Erstgespräch bis zum Ergebnis-Call. Übersetzt Befunde in Entscheidungen, die auch ohne Entwicklerwissen tragen.

Tobias Waggoner

Partner · Senior-Architekt · 30+ Jahre Softwareentwicklung

Prüft Architektur, Betrieb und Skalierung im Vier-Augen-Prinzip. Erfahrung aus Projekten bei Deutscher Bahn, SAP und Bosch.

Warum adfera für dein Review?

Häufige Fragen zum Code-Review

Ratgeber zum Thema

• Vibe Coding: Risiken und 10-Fragen-Check →
• Supabase, Lovable & Vercel DSGVO-konform betreiben →
• Lovable-App exportieren, hosten und betreiben →
• Citizen Developer & Schatten-IT →

Verwandte Leistungen: Softwareentwicklung · Web-App-Entwicklung · SaaS- und MVP-Entwicklung · KI-Beratung