Den Richtigen Softwareentwicklungspartner Wählen: 8 Fragen Vor der Unterschrift

Die falsche Wahl eines Softwareentwicklungspartners scheitert selten auf einen Schlag. Sie scheitert schleichend. Aus einem "Zwei-Wochen-Sprint" werden unbemerkt sechs Wochen. Ein Dienstleister, der die Code-Eigentumsübertragung nie schriftlich festgehalten hat, verschwindet eines Tages mitsamt den Repository-Zugängen. Ein Angebot, das im Verkaufsgespräch fix wirkte, bläht sich auf, sobald jede vernünftige Änderungsanfrage plötzlich als "außerhalb des Leistungsumfangs" abgerechnet wird. Wenn Gründerinnen und Gründer das bemerken, ist meist schon viel Kapital verbrannt — und es gibt immer noch kein vorzeigbares Produkt.

Nichts davon ist Pech. Es ist das vorhersehbare Ergebnis fehlender Fragen vor der Vertragsunterschrift. Dieser Leitfaden geht die acht Fragen durch, die bei der Bewertung eines Softwareentwicklungsunternehmens für ein Startup-Projekt wirklich zählen — und zeigt, wie eine gute Antwort auf jede einzelne aussieht.

Die 8 Fragen im Überblick

1. Wer besitzt den Code?
2. Wie und wie oft kommunizieren wir?
3. Können Sie einen festen Zeitrahmen zusagen?
4. Passt Ihr Tech-Stack zu unserem Produkt?
5. Welche Sicherheitspraktiken sind Standard?
6. Was passiert nach dem Launch?
7. Wer arbeitet tatsächlich an unserem Projekt?
8. Wie ist die Preisgestaltung aufgebaut?

8 Fragen vor der Vertragsunterschrift

1. Wer Besitzt den Code Nach Projektabschluss?

Das ist die folgenreichste Frage der gesamten Bewertung — und genau die, die Gründerinnen und Gründer am häufigsten vergessen zu stellen, bis es zu spät ist. Wenn der Vertrag die Übertragung des geistigen Eigentums und des vollständigen Quellcodes bei Lieferung (oder bei Schlusszahlung) nicht ausdrücklich regelt, besitzen Sie Ihr eigenes Produkt nicht — Sie leihen es sich von demjenigen, der es gebaut hat. Das bedeutet: kein Agenturwechsel, kein Aufbau eines internen Teams zur Übernahme, keine Finanzierungsrunde ohne dass ein Anwalt das IP-Risiko in der Due Diligence anmerkt.

Ein ernstzunehmender Entwicklungspartner verankert die Übertragung des Code-Eigentums als Standardklausel im Vertrag, nicht als Verhandlungssache. Fragen Sie konkret nach: Umfasst die Eigentumsübertragung auch Drittanbieter-Bibliotheken und Konfiguration, oder nur den individuell geschriebenen Code? Erhalten Sie Administratorzugriff auf jedes Repository, jede Umgebung und jede Deployment-Pipeline — nicht nur eine finale ZIP-Datei?

2. Wie und Wie Oft Werden Wir Kommunizieren?

An der Kommunikationsfrequenz zerbrechen die meisten Outsourcing-Beziehungen leise. Ein vages Versprechen "regelmäßiger Updates" bedeutet ohne konkrete Angaben nichts: Wie oft finden Standups statt? Sehen Sie jede Woche funktionierende Software, oder erst am Ende jeder Phase? Gibt es eine einzige benannte Ansprechperson, oder läuft jede Frage über wechselnde Account-Manager?

Fragen Sie, welche Tools im Tagesgeschäft genutzt werden und ob Sie direkten Zugang zu den Entwicklerinnen und Entwicklern haben — nicht nur zu einer Projektleitung, die Nachrichten weiterreicht. Auch die Zeitzonenüberlappung zählt: Ein Partner ohne gemeinsame Arbeitszeiten mit Ihrem Team wird bei Entscheidungen, die noch am selben Tag eine Antwort brauchen, immer einen Schritt hinterherhinken.

3. Können Sie Einen Festen Zeitrahmen Zusagen — und Was Passiert Bei Verzug?

Ein offener Zeitrahmen nach dem Motto "wir sehen dann weiter" ist der sicherste Weg zu einem Budget, das sich unbemerkt verdoppelt. Ein ernstzunehmender Entwicklungspartner sollte sich für ein klar umrissenes MVP auf ein festes Lieferfenster festlegen können und genau erklären, wie Änderungen am Leistungsumfang gehandhabt werden, sobald das Projekt läuft — denn sie werden kommen.

Fragen Sie konkret, was passiert, wenn der Zeitplan auf ihrer Seite nicht eingehalten wird: Gibt es einen Change-Request-Prozess mit Freigabe für zusätzliche Zeit oder Kosten, oder läuft die Uhr einfach unbegrenzt weiter? Ein Partner, der von seinem Lieferprozess überzeugt ist, hat darauf eine dokumentierte Antwort — kein Achselzucken.

4. Passt Ihr Tech-Stack zu Unserem Produkt — oder Nur zu Ihrer Komfortzone?

Vorsicht bei Agenturen, die jedem Kunden denselben Tech-Stack empfehlen, unabhängig vom Projekt. Das ist meist ein Zeichen dafür, dass Ihr Produkt an die vorhandenen Fähigkeiten des Teams angepasst wird — statt umgekehrt die Technologie an die tatsächlichen Anforderungen Ihres Produkts: Skalierbarkeit, Rekrutierungspool für Ihr künftiges internes Team, Hosting-Kosten und Eignung für die Art von Anwendung, die Sie bauen.

Lassen Sie sich erklären, warum ein bestimmtes Framework oder eine bestimmte Sprache für Ihr konkretes Produkt gewählt würde — nicht nur, dass man damit vertraut ist. Ein Partner, der Abwägungen nachvollziehbar begründen kann — warum React statt eines anderen Frontend-Frameworks, warum diese Kombination aus Backend und Datenbank — denkt an die langfristige Wartbarkeit Ihres Produkts, nicht nur an die eigene Liefergeschwindigkeit in diesem Quartal.

5. Welche Sicherheitspraktiken Sind bei Ihnen Standard?

Sicherheit sollte kein Feature sein, das man extra anfragen und bezahlen muss — sie sollte standardmäßig in die Art und Weise eingebaut sein, wie ein Entwicklungspartner überhaupt arbeitet. Fragen Sie, welche Sicherheitsstandards befolgt werden (die OWASP-Richtlinien sind eine sinnvolle Grundlage), ob es eine unabhängige Sicherheitszertifizierung gibt, wie mit Zugangsdaten und Geheimnissen umgegangen wird und wie der Prozess für Schwachstellen- und Abhängigkeitsscans aussieht.

Fragen Sie auch direkt, wie Ihre Daten und die Daten Ihrer Nutzerinnen und Nutzer während der Entwicklung behandelt werden — welche Vertraulichkeits- und Datenverarbeitungsklauseln tatsächlich im Vertrag stehen, nicht nur stillschweigend vorausgesetzt werden. Ein Partner, der Ihnen dokumentierte Sicherheitspraktiken und einen echten Incident-Response-Prozess zeigen kann, macht eine deutlich belastbarere Zusage als ein bloßes "wir nehmen Sicherheit ernst".

6. Was Passiert Nach dem Launch — Ist Support Inklusive?

Der Launch-Tag ist nicht die Ziellinie. Fragen Sie ausdrücklich, wie der Support nach dem Launch aussieht: Ist ein Wartungsfenster im Projektumfang enthalten, oder beginnt der Support am Tag nach dem Go-live bei null? Wie schnell wird auf einen kritischen Bug reagiert, wie schnell auf einen kleineren? Erhalten Sie eine vollständige Übergabedokumentation und Deployment-Anleitungen, damit Ihr Team — oder ein anderer Dienstleister — ohne Neustart übernehmen kann?

Ein Partner, der Support nach dem Launch im Verkaufsgespräch als Nebensache behandelt, wird ihn in der Praxis wahrscheinlich genauso behandeln.

7. Wer Arbeitet Tatsächlich an Unserem Projekt — und Wie Erfahren Ist das Team?

Es kommt häufig vor, dass die erfahrenen Entwicklerinnen und Entwickler, die im Verkaufsgespräch überzeugen, den eigentlichen Build nach Vertragsabschluss an ein deutlich junioreres Team übergeben. Fragen Sie direkt, wer den Code im Tagesgeschäft schreibt, wie erfahren diese Personen sind und ob die Menschen im Gespräch dieselben sind, die später tatsächlich in den Sprints sitzen.

Eine Teamstruktur, die erfahrene Aufsicht mit operativer Umsetzung verbindet — statt junioren Entwicklerinnen und Entwicklern ohne Senior-Review — schützt vor Architekturentscheidungen, die in Woche zwei unauffällig wirken und in Woche zehn teuer zu korrigieren sind.

8. Wie Ist die Preisgestaltung Aufgebaut — und Was Ist Nicht Enthalten?

Eine einzelne Zahl auf einem Angebot sagt fast nichts aus. Fragen Sie nach einer Aufschlüsselung: Handelt es sich um einen Festpreis oder um Abrechnung nach Aufwand, und wenn Festpreis — was genau ist in diesem Umfang enthalten? Was ist ausdrücklich ausgeschlossen — Hosting-Kosten, Gebühren für externe APIs, Änderungen nach dem Launch, Design-Iterationen über eine bestimmte Rundenzahl hinaus?

Transparente Preisgestaltung bedeutet, dass Sie nachvollziehen können, woher die Zahl kommt und was eine zusätzliche Rechnung auslöst. Wenn ein Partner sein eigenes Angebot nicht klar erklären kann, sollten Sie das vor der Unterschrift bemerken — nicht erst bei der ersten Überraschungsrechnung.

Warnsignale, Bei Denen Sie Absagen Sollten

• Ausweichende Antworten zum Code-Eigentum — "das klären wir später" ist keine Antwort.
• Keine benannten Entwicklerinnen und Entwickler, nur Vertriebskontakte — Sie kaufen ein Team, also sollten Sie wissen, wer dazugehört.
• Ein "kommt drauf an" beim Zeitplan, ohne Rahmen für Änderungen am Leistungsumfang — das ist ein offener Scheck, kein Plan.
• Ein einzeiliges Angebot ohne Aufschlüsselung — eine Zahl, die niemand erklären kann, lässt sich auch nicht budgetieren.
• Sicherheit kommt nur zur Sprache, wenn Sie danach fragen — sie gehört ins Verkaufsgespräch, nicht erst in Ihr Verhör.
• Funkstille zwischen Kickoff und erster Demo — wer Fortschritt nicht früh sieht, erkennt Probleme auch nicht früh.

Wie Wir Diese Fragen bei P2C Beantworten

Wir haben unseren Prozess genau um diese Fragen herum aufgebaut, weil wir gesehen haben, was passiert, wenn Startups vor der Unterschrift bei anderen Anbietern keine klaren Antworten darauf bekommen. Die Übertragung von Code- und IP-Eigentum an Sie ist bei uns Standardvertragsbestandteil, inklusive vollständigem Zugriff auf Repositories und Umgebungen — ohne Nachverhandlung. Unser Liefermodell basiert auf einem festen 12-Wochen-MVP-Zeitrahmen mit wöchentlichen Demos und einer festen Ansprechperson, damit Sie jederzeit wissen, wo das Projekt steht und an wen Sie sich wenden können. Unsere Informationssicherheitspraktiken sind dokumentiert und werden bei jedem Projekt überprüft, nicht nur selbst erklärt. Support nach dem Launch und Übergabedokumentation sind Teil des Projekts, kein separates Upsell nach dem Go-live. Und unsere Teamstruktur bringt erfahrene Entwicklerinnen und Entwickler mit den Personen zusammen, die tatsächlich Ihren Code schreiben — die Menschen im Scoping-Gespräch sind dieselben, die später liefern.

Die Preisgestaltung wird vor jeder Zusage nach Phasen aufgeschlüsselt, damit genau klar ist, was enthalten ist und was nicht.

Bereit, Uns Diese Fragen zu Stellen?

Der beste Weg, einen Softwareentwicklungspartner zu bewerten, ist, ihm die acht Fragen oben zu stellen und zu beobachten, wie konkret die Antworten ausfallen. Wenn Sie uns durch diese Übung schicken möchten, nehmen Sie Kontakt auf — wir erläutern Ihnen unsere Antworten: Code-Eigentum, Zeitrahmen, Sicherheit, Preisgestaltung und alles dazwischen.