Übergabe vorbereiten: Was dein Entwickler von dir braucht

Der Moment ist da: Dein AI-Prototyp hat bewiesen, dass die Idee funktioniert. Nutzer testen es, Feedback kommt rein, vielleicht zahlst sogar schon jemand dafür. Jetzt willst du den nächsten Schritt — einen professionellen Entwickler beauftragen, der aus dem Prototyp ein echtes Produkt macht.

Aber was brauchst du für die Übergabe? Was muss der Entwickler wissen? Und wie stellst du sicher, dass nichts verloren geht?

Hier ist die Checkliste die dir und deinem Entwickler Wochen spart.

Warum die Übergabe so wichtig ist

Eine schlechte Übergabe ist der Hauptgrund warum Entwicklungsprojekte scheitern. Nicht fehlende Skills, nicht falsche Technologie — sondern Missverständnisse.

Ohne Vorbereitung passiert das: - Der Entwickler versteht nicht was die App tun soll - Er baut Features die du nicht brauchst und vergisst die du brauchst - Wochenlange Abstimmungsrunden über Basics - Das Budget explodiert weil der Scope unklar ist

Mit guter Vorbereitung passiert das: - Der Entwickler sieht den Prototyp, versteht sofort was du willst - Kalkulation in Tagen statt Wochen - Weniger Korrekturrunden, schnellere Lieferung - Festpreis statt Stundensatz weil der Scope klar ist

Dein Prototyp ist dabei dein größter Vorteil: Du zeigst statt zu beschreiben. Kein 20-seitiges Lastenheft, sondern eine funktionierende App die der Entwickler anklicken kann.

Die 7 Dinge die dein Entwickler braucht

1. Zugang zum Prototyp (URL + Login)

Das Offensichtliche — aber erstaunlich oft vergessen.

Was du bereitstellen solltest: - Die URL deines Prototyps - Ein Test-Account mit Login-Daten - Idealerweise einen Admin-Account der alle Funktionen zeigt - Screenshots der wichtigsten Screens (falls die App gerade instabil ist)

Warum: Der Entwickler will die App durchklicken. Er will sehen was funktioniert, wie die Navigation aufgebaut ist und wo die Grenzen liegen. Dein Prototyp ist die beste Spezifikation die es gibt — lebend, klickbar, verständlich.

2. Zugang zum Code (GitHub-Repository)

Wenn dein Code in einem GitHub-Repository liegt, gib dem Entwickler Zugang.

Was du bereitstellen solltest: - Link zum GitHub-Repository - Lese-Zugang (der Entwickler braucht anfangs keinen Schreibzugang) - Info welches AI Tool den Code generiert hat (Lovable, Bolt, v0)

Warum: Der Entwickler will den Code lesen. Nicht um ihn zu kritisieren — sondern um zu verstehen was die AI gebaut hat, wo die Stärken liegen und wo die Architektur verbessert werden muss.

Kein GitHub? Kein Problem. Lovable speichert den Code intern. Der Entwickler kann trotzdem mit deinem Prototyp arbeiten — er analysiert dann über den Browser und die API.

3. Zugang zur Datenbank (Supabase)

Dein Entwickler braucht Zugang zu Supabase um die Datenbankstruktur zu verstehen.

Was du bereitstellen solltest: - Supabase-Projekt-URL - Lese-Zugang zum Dashboard (über Team-Einladung) - Info zu bestehenden Daten (Testdaten oder echte Nutzerdaten?)

Wichtig: Gib keinen vollen Admin-Zugang bevor du weißt dass du dem Entwickler vertraust. Lese-Zugang reicht für die Analyse. Schreibzugang kommt wenn das Projekt startet.

4. Deine Feature-Prioritäten

Der Entwickler muss wissen was wichtig ist. Nicht alles auf einmal — die Top-Prioritäten.

Erstelle eine einfache Liste:

Must-have (ohne das geht nichts live): - Kernfunktion X muss stabil funktionieren - Login und Registrierung müssen sicher sein - Daten müssen korrekt gespeichert werden - Mobile muss benutzbar sein

Should-have (wichtig, aber nicht sofort): - Feature Y das 5 Nutzer angefragt haben - PDF-Export - E-Mail-Benachrichtigungen

Nice-to-have (irgendwann): - Dark Mode - Kalender-Integration - Erweiterte Filter

Warum: Der Entwickler kalkuliert basierend auf dem Scope. Wenn du 10 Must-haves hast, wird es teurer und dauert länger als bei 3 Must-haves. Priorisiere mit ICE und sei ehrlich über was du wirklich zum Start brauchst.

5. Dein Nutzerfeedback

Das wertvollste Dokument das du mitbringen kannst: Was sagen echte Nutzer?

Was du bereitstellen solltest: - Gesammeltes Feedback kategorisiert (Bugs, Usability, Feature-Requests) - Die häufigsten Beschwerden - Die meistgenannten Feature-Wünsche - Zitate von Nutzern (anonymisiert)

Warum: Nutzerfeedback zeigt dem Entwickler was wirklich zählt. Nicht was du denkst dass wichtig ist — sondern was echte Menschen sagen. Das hilft bei der Priorisierung und verhindert, dass der Entwickler an Dingen arbeitet die niemand braucht.

6. Deine Geschäftsziele

Technik ist kein Selbstzweck. Der Entwickler muss verstehen WARUM er etwas baut.

Beantworte diese Fragen: - Wie verdienst du Geld mit der App? (Abo, Einmalkauf, Freemium) - Wie viele Nutzer erwartest du in 6 Monaten? - Wer ist deine Zielgruppe? - Gibt es regulatorische Anforderungen? (DSGVO, branchenspezifische Regeln) - Was ist dein Budget und deine Timeline?

Warum: Diese Informationen beeinflussen Architektur-Entscheidungen. Eine App für 50 Nutzer wird anders gebaut als eine für 5.000. Eine App die Gesundheitsdaten verarbeitet braucht andere Sicherheitsmaßnahmen als ein Auftrags-Tracker.

7. Bekannte Probleme und Einschränkungen

Sei ehrlich über die Schwächen deines Prototyps. Das spart dem Entwickler Analysezeit.

Was du kommunizieren solltest: - Bekannte Bugs die du nicht fixen konntest - Features die instabil funktionieren - Bereiche wo die AI „Spaghetti-Code” produziert hat - Performance-Probleme bei mehr Nutzern - Sicherheitslücken die du vermutest

Warum: Der Entwickler findet die Probleme sowieso. Wenn du sie vorab nennst, spart das die Analyse und zeigt dass du professionell arbeitest. Kein Entwickler erwartet perfekten Code von einem AI-Prototyp.

Das Übergabe-Dokument: Eine Seite reicht

Du brauchst kein 30-seitiges Pflichtenheft. Eine Seite mit den wichtigsten Informationen reicht:

PROJEKTÜBERGABE: [Dein Produktname]

1. PROTOTYP
   URL: https://deinprodukt.de
   Test-Login: test@example.com / Passwort123
   GitHub: https://github.com/dein-repo
   Supabase: [Projekt-URL]
   Gebaut mit: Lovable + Supabase + Vercel

2. WAS DIE APP TUT
   [2–3 Sätze: Kernfunktion und Zielgruppe]

3. AKTUELLE NUTZER
   Registriert: [Anzahl]
   Aktiv (wöchentlich): [Anzahl]
   Zahlende Kunden: [Anzahl]

4. TOP-3 PRIORITÄTEN FÜR PROFESSIONALISIERUNG
   1. [Wichtigstes Ziel]
   2. [Zweitwichtigstes Ziel]
   3. [Drittwichtigstes Ziel]

5. BEKANNTE PROBLEME
   - [Problem 1]
   - [Problem 2]
   - [Problem 3]

6. BUDGET UND TIMELINE
   Budget: [Bereich]
   Gewünschter Go-Live: [Datum]

7. NUTZERFEEDBACK
   [Top-3 Feedback-Punkte]

Das ist alles. Eine Seite. Ein Entwickler der damit nicht arbeiten kann, ist nicht der richtige Entwickler.

Was der Entwickler mit deinem Prototyp macht

Nach der Übergabe passiert typischerweise Folgendes:

Tag 1–2: Analyse - Prototyp durchklicken und verstehen - Code lesen (wenn GitHub vorhanden) - Datenbank-Struktur analysieren - Security prüfen (RLS, API-Keys, Input-Validierung) - Performance-Probleme identifizieren

Tag 3: Angebot - Scope definieren basierend auf deinen Prioritäten - Technische Empfehlungen (was übernehmen, was neu bauen) - Festpreis und Timeline nennen - Fragen klären

Ab Tag 4: Umsetzung - Los geht’s — mit deinem Prototyp als Blaupause

Dos and Don’ts bei der Übergabe

Do:

• Sei ehrlich über den Zustand deines Prototyps. Kein Entwickler erwartet perfekten Code.
• Priorisiere radikal. 3 klare Prioritäten sind besser als 15 vage Wünsche.
• Zeig den Prototyp. Nicht beschreiben — zeigen. Das spart Tage an Abstimmung.
• Bring Nutzerfeedback mit. Echte Stimmen wiegen mehr als deine Vermutungen.
• Nenne dein Budget. Ein guter Entwickler passt den Scope ans Budget an — nicht andersherum.

Don’t:

• Versteck keine Probleme. Der Entwickler findet sie sowieso. Und dann hat er das Gefühl dass du ihm etwas verschweigst.
• Bestehe nicht auf technischen Lösungen. Sag was du willst, nicht wie es gebaut werden soll. „Ich will schnelle Ladezeiten” statt „Nutze Redis-Caching.”
• Vergleiche nicht mit Big Tech. „Es soll wie Salesforce funktionieren” ist kein hilfreicher Vergleich. Beschreibe dein spezifisches Problem.
• Überlade den ersten Scope nicht. Lieber ein stabiles Produkt mit 5 Features als ein instabiles mit 15.

FAQ: Häufig gestellte Fragen

Muss ich den Code verstehen um ihn zu übergeben?

Nein. Du musst die App verstehen — was sie tut, für wen und warum. Den Code versteht der Entwickler. Deine Aufgabe ist das Business-Wissen, nicht das technische. Die Grundkonzepte helfen bei der Kommunikation, aber du musst kein Programmierer sein.

Was wenn der Entwickler sagt er will alles neu bauen?

Das kann sinnvoll sein — muss es aber nicht. Frag warum. Wenn die Architektur fundamental falsch ist (z.B. kein Backend, alles im Frontend), ist ein Neubau oft günstiger als ein Umbau. Wenn nur einzelne Teile problematisch sind, sollte er gezielt verbessern. Ein guter Entwickler erklärt dir den Unterschied verständlich.

Wie schütze ich meine Idee bei der Übergabe?

Eine NDA (Vertraulichkeitsvereinbarung) ist Standard. Die meisten Entwickler und Agenturen bieten sie von sich aus an. Aber ehrlich: Deine Idee ist nicht das Wertvolle — dein validierter Prototyp mit echten Nutzern ist es. Und den zu kopieren ist deutlich schwieriger als eine Idee zu stehlen.

Kann ich den Prototyp weiter nutzen während der Entwickler die neue Version baut?

Ja. Das ist der Normalfall. Dein Prototyp bleibt live für bestehende Nutzer. Der Entwickler baut die neue Version parallel. Wenn sie fertig ist, migriert ihr die Daten und schaltet um. Kein Ausfall, kein Nutzerverlust.

Was kostet die Analyse und das Angebot?

Bei den meisten Agenturen und Entwicklern: Nichts. Die Analyse deines Prototyps und das Angebot sind Teil des Vertriebsprozesses. Manche berechnen eine geringe Pauschale (200–500 €) für besonders tiefe technische Analysen — die wird dann bei Beauftragung verrechnet.

Fazit: Gute Vorbereitung spart Geld und Zeit

Die Übergabe deines Prototyps an einen Entwickler ist kein mysteriöser Prozess. Eine Seite mit den wichtigsten Informationen, Zugang zum Prototyp, klare Prioritäten und ehrliches Nutzerfeedback. Das ist alles.

Je besser du vorbereitest, desto schneller und günstiger wird die professionelle Entwicklung. Dein Prototyp hat die Idee bewiesen. Jetzt baut ein Profi das Produkt — mit deinem Prototyp als Blaupause, in einem Bruchteil der Zeit und Kosten die es ohne deine Vorarbeit kosten würde.

Du bist bereit für die Übergabe? Schick uns deinen Prototyp-Link und wir melden uns innerhalb von 48 Stunden mit einer Einschätzung und einem Angebot.

Jetzt Prototyp übergeben