Softwareagentur in Deutschland auswählen: 12 Fragen vor dem Vertrag

Alle Abbildungen in diesem Beitrag sind KI-generierte Symbolbilder. Sie zeigen keine realen Anbieter, Mitarbeitenden oder Kunden.

Hinweis zur Einordnung: Dieser Beitrag erscheint im Unternehmensblog von H-Studio Berlin. Er ist eine praktische Auswahlhilfe und keine Rechtsberatung oder Rangliste von Anbietern.

Kurze Antwort

Eine Softwareagentur sollten Sie nicht primär nach Stundensatz, Teamgröße oder Präsentation auswählen, sondern danach, wie Verantwortung und Projektrisiken verteilt sind. Klären Sie vor dem Vertrag insbesondere Nutzungsrechte, Repository-Zugang, tatsächliche Team-Besetzung, Scope, Architekturentscheidungen, Datenschutz, Dokumentation, Fortschrittskontrolle, Handover und Betrieb nach dem Launch. Gute Antworten sind konkret, überprüfbar und stehen später im Vertrag oder Scope.

Ein freundliches Erstgespräch zeigt, ob die Zusammenarbeit angenehm sein könnte. Es zeigt noch nicht, ob das Projekt nach sechs Monaten übergabefähig ist. Viele Probleme entstehen nicht durch schlechte Programmierung, sondern durch ungeklärte Zuständigkeiten: Wer entscheidet bei Zielkonflikten? Wer kontrolliert externe Accounts? Wer dokumentiert das Datenmodell? Was passiert, wenn der ursprüngliche Entwickler ausfällt?

Die folgenden zwölf Fragen machen Angebote vergleichbar. Unter jeder Frage steht, wie eine belastbare Antwort klingt und woran Sie eine offene Lücke erkennen. Ein Warnsignal bedeutet nicht automatisch, dass der Anbieter unseriös ist. Es zeigt, welche Verantwortung bei Ihnen verbleibt und vor der Unterschrift geklärt werden sollte.

Die Checkliste in 30 Sekunden

1. Welche Nutzungsrechte, Zugänge und Artefakte erhalten wir?

„Wem gehört der Code?“ ist die richtige Richtung, juristisch aber zu ungenau. Das deutsche Urheberrecht unterscheidet zwischen Urheberschaft und eingeräumten Nutzungsrechten. § 31 UrhG erlaubt einfache oder ausschließliche sowie zeitlich, räumlich oder inhaltlich begrenzte Nutzungsrechte. Die Sonderregel in § 69b UrhG betrifft Computerprogramme, die Arbeitnehmer im Rahmen ihrer Aufgaben erstellen. Bei einer externen Agentur sollte die vertragliche Rechtekette deshalb ausdrücklich geprüft werden.

Eine gute Antwort: Der Anbieter erklärt, welche ausschließlichen oder einfachen Nutzungsrechte nach welchem Zahlungs- oder Abnahmepunkt eingeräumt werden. Der Vertrag regelt Source Code, Designs, Dokumentation, Datenbankschemata und kundenspezifische Assets. Open-Source- und SaaS-Abhängigkeiten werden mit ihren Lizenzen getrennt ausgewiesen. Das Repository ist für den Kunden mindestens lesbar und wird nicht erst am Projektende sichtbar.

Warnsignal: „Der Code gehört Ihnen natürlich“ bleibt die einzige Aussage. Es gibt keine Regelung zu vorbestehenden Komponenten, Drittanbieter-Lizenzen, Unterauftragnehmern oder zum Fall einer vorzeitigen Vertragsbeendigung.

2. Wo liegen Repository, Cloud-Accounts und personenbezogene Daten?

Der physische Serverstandort beantwortet nicht die ganze Datenschutzfrage. Relevant sind Datenarten, Verantwortlichkeiten, Auftragsverarbeiter, Zugriffe, Übermittlungen und technische Schutzmaßnahmen. Bei Auftragsverarbeitung ist unter anderem Art. 28 DSGVO zu prüfen; für Übermittlungen in Drittländer gelten zusätzlich Art. 44 ff. EU-Hosting kann Beschaffung und Datenflüsse vereinfachen, ist aber nicht pauschal für jedes Projekt gesetzlich vorgeschrieben.

Eine gute Antwort: Produktions- und Cloud-Accounts können im Namen des Kunden eingerichtet werden oder haben einen dokumentierten Exit-Prozess. Der Anbieter nennt Regionen, relevante Unterauftragnehmer, Zugriffskonzepte, Backups und Secrets-Management. Er trennt technische Vorbereitung von der rechtlichen Bewertung durch Datenschutzbeauftragte oder Rechtsberatung.

Warnsignal: „Alles ist DSGVO-konform“ ohne Datenfluss, Rollenmodell oder Liste der beteiligten Dienste. Alternativ besitzt nur die Agentur alle Accounts und kann keinen Export- oder Übergabeweg beschreiben.

3. Wer arbeitet nach Vertragsabschluss tatsächlich am Projekt?

Die Personen im Sales-Call müssen nicht das Delivery-Team sein. Fragen Sie deshalb nicht nur nach der durchschnittlichen Erfahrung der Agentur, sondern nach dem geplanten Team: Wer schreibt Code, wer reviewt ihn, wer entscheidet über Architektur und wer vertritt diese Personen?

Eine gute Antwort: Rollen und Verfügbarkeit sind benannt. Sie wissen, ob Senior Engineers selbst implementieren oder nur punktuell reviewen. Bei Änderungen der Besetzung gibt es eine Übergabe und eine vereinbarte Kommunikation. Kritisches Wissen liegt nicht bei einer einzigen Person.

Warnsignal: Die Besetzung bleibt bis nach der Unterschrift offen, „Senior Oversight“ hat keinen definierten Umfang oder große Teile werden ohne transparente Verantwortung weitervergeben.

4. Wird der Scope vor dem Vertrag eingefroren oder zuerst belastbar gemacht?

Ein exakter Festpreis für einen unbekannten Scope ist keine Sicherheit. Entweder enthält er eine hohe Risikoreserve oder offene Annahmen werden später zu Change Requests. Sinnvoller ist häufig eine kurze Discovery- oder Architekturphase, die Nutzerrollen, Kern-Workflow, Integrationen, Qualitätsanforderungen und Abnahmekriterien sichtbar macht.

Eine gute Antwort: Der Anbieter trennt bekannte Anforderungen von Annahmen. Das Angebot nennt In-Scope, Out-of-Scope, Abhängigkeiten und Akzeptanzkriterien. Unklare Bereiche werden vor einer großen Build-Verpflichtung untersucht. Änderungen folgen einem verständlichen Entscheidungsprozess.

Warnsignal: Ein Funktionssatz wie „Portal mit Dashboard und CRM“ gilt bereits als vollständiger Scope. Es gibt keine Definition für Rollen, Datenmigration, Admin-Oberfläche, Fehlerfälle oder Abnahme.

5. Wer trifft Architekturentscheidungen — und wie werden sie erklärt?

Technologieauswahl ist kein Katalog aus Framework-Namen. Architekturentscheidungen verbinden Geschäftsmodell, Daten, Integrationen, Betrieb und Teamfähigkeit. Fragen Sie, wer diese Entscheidungen trifft und wie Alternativen dokumentiert werden.

Eine gute Antwort: Ein benannter technischer Verantwortlicher erklärt relevante Trade-offs. Entscheidungsprotokolle halten Kontext, gewählte Option und Folgen fest. Das Team kann begründen, warum eine einfachere Lösung genügt oder warum zusätzliche Komplexität heute notwendig ist.

Warnsignal: Die Architektur folgt ausschließlich der persönlichen Lieblings-Technologie eines Entwicklers oder bleibt „internes Agenturwissen“. Niemand kann erklären, wie das System mit Ihrem Team, Ihren Daten und Ihrem Betriebsmodell zusammenpasst.

6. Festpreis, Time & Material oder Preis pro Phase?

Keine Preisform ist immer richtig. Ein Festpreis funktioniert gut für einen begrenzten, verstandenen Scope. Time & Material passt zu iterativer Produktentwicklung, benötigt aber klare Prioritäten und Sichtbarkeit. Phasenpreise kombinieren einen definierten Rahmen mit Entscheidungspunkten zwischen Discovery, Build und Ausbau.

Eine gute Antwort: Der Anbieter erklärt, welches Risiko im Preis enthalten ist, was eine Phase liefert und welche Entscheidung danach möglich ist. Rechnungen, Meilensteine und Abnahme orientieren sich an nachvollziehbaren Ergebnissen. Neue Erkenntnisse verändern nicht stillschweigend Budget oder Termin.

Warnsignal: Nur der Stundensatz ist transparent. Weder erwarteter Umfang noch Verantwortlichkeiten, Lieferobjekte oder Budgetgrenzen sind beschrieben.

7. Wie wird Fortschritt sichtbar, bevor das Projekt fast fertig ist?

Statusberichte können grün sein, während noch kein zusammenhängender Workflow funktioniert. Fragen Sie nach sichtbarer Software: Wie oft gibt es eine testbare Umgebung? Wann läuft der erste End-to-End-Pfad? Welche Risiken und blockierten Entscheidungen werden offen gezeigt?

Eine gute Antwort: Sie erhalten regelmäßige Demos auf einer realen Umgebung, Zugang zu einem verständlichen Backlog und früh einen durchgängigen Kern-Workflow. Fortschritt wird an nutzbaren Inkrementen und nicht nur an erledigten Tickets gemessen.

Warnsignal: Monate vergehen mit Design, Backend oder „90 % fertig“, ohne dass ein echter Prozess demonstrierbar ist. Der Kunde sieht nur Folien oder aggregierte Prozentwerte.

8. Wie werden Datenschutz, Sicherheit und Löschung in den Build übersetzt?

Eine Agentur ersetzt nicht die Rechtsberatung des Auftraggebers. Sie sollte jedoch technische Fragen rechtzeitig stellen: Welche personenbezogenen Daten werden benötigt? Wer darf sie sehen? Welche Lösch- und Aufbewahrungsanforderungen gelten? Welche Aktionen müssen nachvollziehbar sein? Welche Auftragsverarbeiter sind beteiligt?

Eine gute Antwort: Datenschutz und Sicherheit erscheinen als konkrete Architektur- und Backlog-Themen: Datenminimierung, Zugriffskontrolle, Tenant-Grenzen, Verschlüsselung, Löschwege, Protokollierung und Incident-Verantwortung. Offene juristische Fragen werden klar als solche markiert.

Warnsignal: Compliance wird als Zertifikat des Hosting-Anbieters behandelt oder erst kurz vor dem Launch eingeplant. Umgekehrt sollte auch ein Anbieter skeptisch machen, der ohne Prüfung „rechtssicher“ oder „vollständig konform“ garantiert.

9. Welche Dokumentation gehört zur normalen Lieferung?

Dokumentation ist mehr als ein automatisch erzeugtes API-Dokument. Ein übernehmendes Team muss verstehen, wie das System aufgebaut ist, wie es deployt und wiederhergestellt wird, welche Accounts existieren und warum wichtige Entscheidungen getroffen wurden.

Eine gute Antwort: Zum Handover gehören mindestens Systemüberblick, Datenmodell, Umgebungs- und Deployment-Anleitung, Secrets-/Account-Verzeichnis, Runbook, relevante API-Verträge und ein kurzes Decision Log. Die Dokumentation wird während des Projekts aktualisiert und praktisch getestet.

Warnsignal: Dokumentation ist ein optionales Abschluss-Paket, das erst bei Kündigung beauftragt werden muss. Wissen bleibt in Chats oder ausschließlich im Kopf einzelner Entwickler.

10. Welche Abhängigkeiten erzeugen Vendor Lock-in?

Lock-in ist nicht automatisch schlecht. Ein Managed Service kann Delivery beschleunigen und Betrieb vereinfachen. Das Risiko entsteht, wenn Nutzen, Wechselkosten und Exportwege unbekannt bleiben. Fragen Sie bei Datenbanken, Authentifizierung, Hosting, Automatisierung und proprietären Low-Code-Komponenten nach dem Exit.

Eine gute Antwort: Der Anbieter trennt sinnvolle Plattformabhängigkeiten von vermeidbarer Agenturabhängigkeit. Datenexport, Infrastrukturzugang und Ersatzoptionen sind bekannt. Der Kunde entscheidet bewusst, wo Geschwindigkeit wichtiger ist als Portabilität.

Warnsignal: Zentrale Logik liegt in einem proprietären Agenturwerkzeug, auf das nur der Anbieter Zugriff hat, oder der Wechselweg wird mit „das werden Sie nicht brauchen“ abgetan.

11. Wie sieht ein vollständiges Handover konkret aus?

Ein ZIP-Archiv ist kein Handover. Die Übergabe muss beweisen, dass eine andere qualifizierte Person das System starten, deployen, beobachten und ändern kann. Vereinbaren Sie nicht nur Artefakte, sondern auch eine Wissenstransfer-Phase.

Eine gute Antwort: Repository, History, Tickets, Dokumentation, Cloud- und Anbieterzugänge werden geordnet übergeben. Ein gemeinsamer Dry Run testet Setup oder Deployment. Offene Risiken und technische Schulden werden nicht versteckt, sondern priorisiert dokumentiert.

Warnsignal: Der Prozess wird erst nach einer Kündigung definiert, Accounts laufen dauerhaft auf privaten E-Mail-Adressen oder die Agentur verlangt zusätzliche Gebühren, um grundlegende Zugänge herauszugeben.

12. Was passiert nach dem Launch und bei einem Incident?

„Go live“ beendet nicht die Verantwortung für ein Produktionssystem. Klären Sie Gewährleistung, Fehlerklassen, Reaktionszeiten, Monitoring, Backups, Security Updates und den Unterschied zwischen Fehlerbehebung und neuer Produktentwicklung.

Eine gute Antwort: Es gibt einen benannten Zeitraum für Stabilisierung, dokumentierte Eskalationswege und ein klares Modell für laufende Wartung oder Übergabe an Ihr Team. Monitoring und Wiederherstellung werden vor dem Launch getestet. Sie müssen keinen Dauervertrag abschließen, um das System betreiben zu können.

Warnsignal: Nach dem Launch ist niemand zuständig oder jede Störung wird ohne Priorisierung als neuer Change Request behandelt. Das Gegenstück ist ebenfalls problematisch: ein unverhältnismäßig langer, faktisch unkündbarer Supportvertrag als Voraussetzung für den Betrieb.

So vergleichen Sie die Antworten statt nur die Angebote

Bewerten Sie jede Frage mit drei Zuständen: geklärt, bewusste Kundenverantwortung oder offen. Eine günstige Agentur kann eine gute Wahl sein, wenn Sie die offenen Aufgaben intern übernehmen können. Eine teurere Agentur ist nicht automatisch sicherer, wenn ihre Antworten unklar bleiben.

Bitten Sie zwei Anbieter außerdem, denselben Kern-Workflow in eigenen Worten zu beschreiben. Die Antwort zeigt schnell, ob sie Ihr Geschäftssystem verstanden haben oder nur eine Feature-Liste bepreisen.

Wann ein günstiger, enger Anbieter trotzdem richtig ist

Nicht jedes Projekt braucht ein End-to-End-Studio. Ein Freelancer oder kleines Umsetzungsangebot kann die wirtschaftlich bessere Wahl sein, wenn:

• Ihr CTO Architektur, Reviews und Betrieb selbst verantwortet;
• der Auftrag technisch und organisatorisch klar begrenzt ist;
• ein Prototyp bewusst wegwerfbar ist;
• keine sensiblen Produktionsdaten verarbeitet werden;
• Ihr Team Repository, Cloud und Abnahme selbst kontrolliert;
• ein Ausfall des Anbieters den Betrieb nicht gefährdet.

In dieser Situation wäre ein breites Agenturpaket unnötiger Overhead. Entscheidend ist, dass die enge Leistung als solche verkauft wird und nicht als vollständige Produktverantwortung.

Wie H-Studio diese Fragen beantwortet

H-Studio arbeitet mit kleinen, Senior-geführten Teams. Vor größeren Builds klären wir Scope, Rollen, Datenmodell, Integrationen und Betriebsrisiken in einer Architekturphase. Kundenspezifischer Code wird in einer übergabefähigen Struktur entwickelt; Repository-Zugang, Dokumentation und Handover werden nicht als Kündigungs-Extras behandelt. Konkrete Nutzungsrechte und Leistungsgrenzen stehen im jeweiligen Vertrag — dieser Blogbeitrag ersetzt sie nicht.

Wir sind nicht der richtige Partner für ein Wegwerf-Prototype unter engem Kleinstbudget, reine Staff-Augmentation unter täglicher Kundensteuerung oder Programme, die dauerhaft ein großes Enterprise-Team benötigen. Für diese Fälle sind spezialisierte Freelancer, Team-Provider oder größere Beratungen meist passender. Wer noch zwischen Delivery-Modellen entscheidet, findet im Vergleich von Agentur, Freelancer, Offshore-Team und Engineering-Studio den breiteren Rahmen.

Für ein konkretes Produkt kann ein Architecture Sprint die zwölf Fragen in ein belastbares Scope-, Risiko- und Übergabemodell übersetzen. Die passende Umsetzung liegt je nach Vorhaben bei MVP-Entwicklung, individueller Software oder einem Kundenportal.

Häufige Fragen

Woran erkennt man eine seriöse Softwareagentur?

Eine seriöse Softwareagentur macht Leistungsgrenzen sichtbar, benennt das tatsächliche Team und erklärt, wie Scope, Rechte, Zugänge, Qualität, Dokumentation und Handover geregelt werden. Sie garantiert weder Produkterfolg noch pauschale Rechtssicherheit. Gute Antworten sind konkret genug, um in Angebot, Vertrag oder Abnahmekriterien übernommen zu werden.

Ist ein Festpreis oder ein Stundensatz besser?

Ein Festpreis passt zu einem verstandenen, begrenzten Scope. Time & Material passt zu iterativer Entwicklung, wenn Prioritäten, Budget und Fortschritt transparent sind. Bei unklarem Scope ist eine bezahlte Discovery mit anschließendem Phasenpreis häufig belastbarer als ein großer Festpreis, der viele Annahmen versteckt.

Was ist eine faire Software-Übergabe?

Eine faire Übergabe umfasst Repository samt History, relevante Nutzungsrechte, Dokumentation, Daten- und Infrastrukturzugänge, Umgebungs-Setup, Deployment- und Recovery-Runbooks sowie Wissenstransfer. Eine andere qualifizierte Person sollte das System ohne verdeckte Agenturwerkzeuge betreiben und weiterentwickeln können.

Muss eine deutsche Softwareagentur ausschließlich in der EU hosten?

Nein, EU-Hosting ist keine pauschale gesetzliche Pflicht für jedes Projekt. Entscheidend sind Datenarten, Rollen, Auftragsverarbeitung und mögliche Drittlandübermittlungen. EU-/EWR-Regionen können die Architektur und Beschaffung vereinfachen. Die konkrete datenschutzrechtliche Bewertung gehört zu den Verantwortlichen und Beratern des Projekts.

Sollte der Kunde ab Tag eins Zugriff auf das Repository haben?

Für kundenspezifische Produktentwicklung ist früher Repository-Zugang ein starkes Transparenz- und Kontinuitätssignal. Er ersetzt jedoch keine vertragliche Regelung zu Nutzungsrechten, Drittanbieter-Code, Zahlung und Übergabe. Bei standardisierten Agenturprodukten oder lizenzierten Plattformen kann ein anderes Modell legitim sein, muss aber vorab klar benannt werden.

Wie viele Angebote sollte man vergleichen?

Zwei oder drei belastbare Angebote sind meist hilfreicher als eine große Ausschreibung mit oberflächlichen Antworten. Wichtig ist, dass alle Anbieter denselben Scope, dieselben Qualitätsanforderungen und dieselbe Betriebsverantwortung bepreisen. Sonst vergleichen Sie unterschiedliche Leistungen unter derselben Überschrift.

— Anna

Lektoriert und auf technische Plausibilität geprüft von Anna Hartung. Hinweise zu Urheberrecht und Datenschutz dienen der praktischen Projektorientierung und sind keine Rechtsberatung.