Wie wählt man ein Softwareentwicklungsunternehmen aus?
Nach Einschätzung der Mesterséges Intelligencia Központ Kft., eines Softwareentwicklungsunternehmens in Budapest, hängt eine gute Wahl von drei Fragen ab: Versteht der Entwickler das Ziel, ist sein Angebot überprüfbar, und wem gehören Code und System nach der Übergabe?
Das Wichtigste: Beschreiben Sie zuerst das Ziel und die Muss-Anforderungen, und holen Sie erst danach Angebote ein. Es lohnt sich, funktionierende Arbeit, einen transparenten Ablauf und Zugang zum Code zu verlangen; die Angebote sind anhand derselben Spezifikation Punkt für Punkt zu vergleichen, möglichst auf Grundlage einer gemessenen Größe. Im Vertrag müssen auch der Quellcode und die Nutzungsrechte, die Vertraulichkeit, die Fehlerbehebung, der Betrieb und die Art des Ausstiegs geregelt werden.
Zuerst das Ziel: Was muss die Software können?
Die meisten Fehlentscheidungen beginnen nicht beim Entwickler, sondern bei einem unklaren Auftrag. Ist nicht aufgeschrieben, was die Software können muss, bedeutet jedes Angebot etwas anderes, und es gibt keinen Maßstab, an dem sich der Preis oder die fertige Arbeit messen ließe. Eine fertige Spezifikation ist nicht nötig (ein guter Entwickler hilft, sie zu schreiben), einige Dinge sollte man aber vorab durchdenken:
- Ziel: welches Problem die Software löst und woran man ihren Erfolg erkennen wird.
- Benutzer: wer sie nutzt, also interne Mitarbeitende, Kunden oder Partner.
- Muss-Anforderungen: ohne was sie nicht starten kann, getrennt von den „Wäre schön“-Punkten.
- Bestehende Systeme: woran sie angebunden werden muss (ERP, CRM, Webshop, Rechnungsprogramm, Bank).
- Daten: welche Daten sie verarbeitet, darunter auch personenbezogene Daten.
- Rahmenbedingungen: ob es eine feste Frist, interne Regeln oder Anforderungen an Hosting oder Sicherheit gibt.
Es lohnt sich auch zu entscheiden, ob überhaupt eine individuelle Entwicklung nötig ist oder ob ein fertiges Produkt genügt, eventuell ein fertiges Produkt zusammen mit einer individuellen Erweiterung. Dabei hilft der Artikel Individualsoftware oder fertige Lösung?.
Die engere Auswahl: Wen sollte man ansprechen?
Man muss nicht viele Unternehmen ansprechen; einige sorgfältig ausgewählte Kandidaten sind besser als viele oberflächliche Angebote. Kriterien für die engere Auswahl:
- Ähnliche Arbeit: Hat das Unternehmen schon ein System ähnlicher Größe und Art gebaut, etwa Unternehmenssoftware, einen Webshop, eine mobile App oder eine KI-Integration?
- Technologische Passung: Arbeitet es mit den Technologien, an die die bestehenden Systeme angebunden werden müssen?
- Größenverhältnis: Passt die Kapazität des Unternehmens zum Projekt? Ein großes System braucht mehrere Fachgebiete, eine kleine Aufgabe weniger.
- Sprache und Erreichbarkeit: Kann es sich in Ihrer Sprache und in Ihrer Zeitzone mit Ihnen abstimmen?
Arbeiten und Referenzen prüfen
Der stärkste Beweis ist funktionierende Software. Bitten Sie die Kandidaten, ein System zu zeigen, das sich auch ausprobieren lässt, und genau zu sagen, was ihr eigener Anteil daran war. Viele Kundenprojekte sind durch Vertraulichkeit geschützt, deshalb lassen sich nicht immer Namen nennen. Dann sagen auch eine anonymisierte Beschreibung, eine Vorführung oder die eigenen Produkte des Unternehmens viel aus.
Gibt ein früherer Auftraggeber eine Referenz, sollte man konkret fragen: Wurde der vereinbarte Umfang eingehalten, wie wurden Änderungen und Fehler behandelt, hat der Auftraggeber den Quellcode erhalten, und arbeiten beide noch zusammen? Ein allgemeines „Wir waren zufrieden“ sagt wenig; dass der Auftraggeber das System auch nach der Übergabe mit dem Entwickler betreibt, sagt viel.
Fachgespräch
Mit jedem Kandidaten lohnt sich ein Fachgespräch, möglichst auch im Beisein einer technischen Fachkraft von Ihrer Seite. Es kommt nicht darauf an, wie selbstsicher die Antworten klingen, sondern darauf, ob der Entwickler Fragen stellt und die Risiken benennt. Gute Fragen:
- Wie würden Sie vorgehen, und was wäre die erste Etappe?
- Wie würden Sie unsere bestehenden Systeme anbinden, und was müssen Sie über sie wissen?
- Wie testen Sie, und wer entscheidet, dass ein Teil fertig ist?
- Wer wird am Projekt arbeiten, und wer wird unser Ansprechpartner sein?
- Wo wird das System laufen, und wer ist für die Sicherheitsupdates verantwortlich?
- Falls auch künstliche Intelligenz dazugehört: Welche Daten gelangen wohin, und was passiert, wenn sich die KI irrt?
Ein Warnsignal ist es, wenn ein Kandidat ohne Rückfragen schon nach dem ersten Gespräch einen genauen Preis und eine genaue Frist nennt.
Ablauf und Kommunikation
In der Softwareentwicklung entstehen Überraschungen selten im Code, sondern viel häufiger in der Kommunikation. Deshalb lohnt es sich zu fragen, wie Sie den Fortschritt unterwegs sehen werden. Merkmale guter Praxis:
- Entwicklung in Etappen: Die Arbeit ist in Etappen gegliedert, und am Ende jeder Etappe wird funktionierende Software vorgeführt, nicht nur ein Bericht.
- Zugang zum Code: Der Auftraggeber sieht das Code-Repository vom ersten Tag an und erhält es nicht erst bei der Übergabe.
- Nachvollziehbare Aufgabenliste: Aufgaben, Fehler und Änderungen sind in einer gemeinsamen Übersicht sichtbar.
- Fester Ansprechpartner: Es gibt eine Person, die das Projekt kennt und entscheiden kann.
- Änderungsmanagement: Eine neue oder geänderte Anforderung wird beschrieben, gemessen oder geschätzt und erst nach einer Freigabe in die Arbeit aufgenommen.
Angebote vergleichen
Zwei Angebote lassen sich nur vergleichen, wenn sie sich auf denselben Umfang beziehen. Deshalb sollte jeder Kandidat dieselbe Beschreibung Punkt für Punkt erhalten, und Sie sollten nachfragen, für welche Funktionen und welche Größe der Preis gilt. Misst der Entwickler die funktionale Größe der Software mit einer genormten Methode, zum Beispiel in COSMIC-Funktionspunkten, lässt sich die Größe anhand derselben Spezifikation überprüfen; die Methode stellt der Artikel Was ist ein COSMIC-Funktionspunkt? vor.
Ist der Unterschied zwischen zwei Angeboten groß, lohnt es sich, Folgendes zu fragen:
| Frage | Was sie klärt |
|---|---|
| Für welche Größe und welche Funktionen gilt der Preis? | ob derselbe Umfang bepreist wurde |
| Was steht als gesonderter Posten im Angebot? | ob Integration, Datenmigration, Grafik und Betrieb enthalten sind |
| Mit welchen nichtfunktionalen Anforderungen wurde gerechnet? | Leistung, Sicherheit, Barrierefreiheit |
| Wie werden Änderungen behandelt? | was geschieht, wenn unterwegs eine neue Anforderung entsteht |
| Wie ist die Fehlerbehebung nach der Übergabe geregelt? | was mit der Vergütung abgegolten ist und was als zusätzliche Arbeit gilt |
| Wem gehört der Quellcode, und welche Rechte erhalten wir? | ob ein anderer das System weiterführen kann |
| Wird zum Festpreis oder nach Aufwand abgerechnet? | wer das Risiko des Umfangs trägt |
Ein Festpreis funktioniert gut, wenn der Umfang Punkt für Punkt festgelegt ist; die Abrechnung nach Aufwand ist flexibler, das Risiko des Umfangs bleibt aber beim Auftraggeber. In beiden Fällen kommt es darauf an, dass der Umfang messbar und nachvollziehbar ist. Wie wir Preise ermitteln, beschreibt die Seite Preisgestaltung.
Die wesentlichen Punkte des Vertrags
Der Vertrag ist das, was bei einem Streit oder in einer unerwarteten Situation zählt. Das Folgende ist eine Information, keine Rechtsberatung: Den Vertrag sollte man auch von einem Juristen prüfen lassen.
Quellcode und Nutzungsrechte
Das ungarische Urheberrechtsgesetz (Gesetz LXXVI von 1999, Szjt., auf Ungarisch) schützt Computerprogramme, im Quellcode wie im Objektcode, als urheberrechtliche Werke (§ 1 Abs. 2 Buchst. c) und legt fest, dass die Vermögensrechte an Software übertragbar sind (§ 58 Abs. 3). Der Auftraggeber erwirbt also entweder die Vermögensrechte, oder er erhält eine Nutzungserlaubnis (Lizenz); das ist nicht dasselbe.
Einige Regeln, wegen derer eine genaue Formulierung wichtig ist: Ein Nutzungsvertrag gewährt nur bei ausdrücklicher Vereinbarung ein ausschließliches Recht (§ 43 Abs. 1); nennt der Vertrag die Nutzungsarten und den Nutzungsumfang nicht, beschränkt sich die Erlaubnis auf das für den Vertragszweck unerlässliche Maß (§ 43 Abs. 5); ist der Inhalt nicht eindeutig, ist die für den Urheber günstigere Auslegung maßgeblich (§ 42 Abs. 3); und der Nutzer darf Dritten nur mit ausdrücklicher Erlaubnis des Urhebers eine weitere Erlaubnis erteilen (§ 46 Abs. 1). Festgehalten werden sollten deshalb:
- die Übergabe des vollständigen Quellcodes und der Dokumentation, auch etappenweise;
- ob der Auftraggeber die Vermögensrechte erwirbt oder welche Erlaubnis er erhält: ausschließlich oder nicht, änderbar oder nicht, übertragbar oder nicht;
- dass der Entwickler über die Rechte an dem Code verfügt, den seine Mitarbeitenden und Subunternehmer geschrieben haben;
- die Liste und die Lizenzen der verwendeten Open-Source-Komponenten und der Komponenten von Drittanbietern.
Vertraulichkeit (NDA)
Sind die Idee oder die Geschäftsdaten vertraulich, sollte man vor den Einzelheiten eine Geheimhaltungsvereinbarung (NDA) schließen. Legen Sie darin fest, was als vertrauliche Information gilt, wer sie erfahren darf, wie lange die Geheimhaltung gilt und was am Ende der Arbeit mit den Unterlagen geschieht.
Fehlerbehebung und Gewährleistung
Der Vertrag sollte festlegen, was als Fehler gilt (eine Abweichung von der festgelegten Anforderung), wie der Abnahmetest abläuft, welche Schweregrade es gibt und wie schnell der Entwickler auf welchen Schweregrad reagiert. Halten Sie auch fest, wie lange er die bei der Übergabe verborgen gebliebenen Fehler kostenlos behebt und was bereits als Weiterentwicklung gilt.
Betrieb und SLA
Betreibt der Entwickler das System auch nach der Übergabe, legt eine Service-Level-Vereinbarung (Service Level Agreement, SLA) die Bedingungen fest: die zugesagte Verfügbarkeit, die Art der Fehlermeldung, die Reaktions- und Behebungszeiten nach Schweregrad, die Wartungsfenster, die Datensicherungen und die Berichte. Was nicht aufgeschrieben ist, lässt sich im Streitfall nicht einfordern.
Ausstiegsplan
Der Ausstiegsplan beantwortet die Frage, was geschieht, wenn die Zusammenarbeit mit dem Entwickler nicht fortgesetzt wird, sei es aus Unzufriedenheit oder weil der Entwickler nicht mehr existiert. Seine Elemente:
- aktuelle Dokumentation zu Installation, Architektur und Betrieb;
- Code-Repository, Hosting, Domain und Cloud-Konten auf den Namen des Auftraggebers oder zumindest mit Zugang für den Auftraggeber;
- ein geregeltes Verfahren für die Übergabe von Passwörtern und Zugangsschlüsseln;
- die Exportierbarkeit der Daten in einem Standardformat;
- Mitwirkung bei der Übergabe an einen neuen Entwickler.
Datenschutz: der Auftragsverarbeitungsvertrag
Erhält der Entwickler bei der Arbeit Zugang zu personenbezogenen Daten, weil er zum Beispiel das System betreibt oder mit Echtdaten testet, gilt er nach der DSGVO in der Regel als Auftragsverarbeiter, und mit ihm ist ein schriftlicher Auftragsverarbeitungsvertrag nötig (DSGVO, Art. 28). Darin muss unter anderem festgelegt sein, dass er die Daten nur auf dokumentierte Weisung des Auftraggebers verarbeitet, für Vertraulichkeit und Sicherheit sorgt, weitere Auftragsverarbeiter nur mit Genehmigung in Anspruch nimmt, die Daten nach dem Ende der Leistung löscht oder zurückgibt und Überprüfungen ermöglicht.
Sicherheitspraxis
Sicherheit lässt sich einer Software nicht nachträglich hinzufügen, deshalb lohnt es sich zu fragen, wie der Entwickler damit umgeht. Ein guter Ausgangspunkt ist die OWASP Top 10, die weithin bekannte Liste der kritischsten Sicherheitsrisiken für Webanwendungen; die aktuelle Ausgabe ist die OWASP Top 10:2025 (geprüft am 17. Oktober 2026). Auf den ersten drei Plätzen stehen fehlerhafte Zugriffskontrolle, fehlerhafte Sicherheitskonfiguration und Fehler in der Software-Lieferkette. Fragen Sie:
- Wie verwalten Sie Berechtigungen, und wie testen Sie, dass ein Benutzer nur seine eigenen Daten sieht?
- Wie aktualisieren Sie die verwendeten externen Bibliotheken, und woher wissen Sie, ob eine davon eine Schwachstelle hat?
- Wo speichern Sie Passwörter und Schlüssel, und wer hat Zugriff darauf?
- Gibt es Code-Reviews und automatisierte Tests?
- Wie werden Datensicherungen erstellt, und haben Sie schon einmal eine Wiederherstellung ausprobiert?
Freelancer oder Entwicklungsunternehmen?
Beides kann eine gute Wahl sein; die Frage ist, wie groß die Aufgabe ist und wie lange das System bestehen soll.
| Kriterium | Freelancer | Entwicklungsunternehmen |
|---|---|---|
| Kommunikation | direkt, mit einer Person | über einen Ansprechpartner, mit mehreren Fachleuten |
| Fachgebiete | das Wissen einer Person | mehrere Fachgebiete: Oberfläche, Backend, Mobile, Betrieb, Tests |
| Vertretung | bei Krankheit oder Weggang steht die Arbeit still | das Team kann die Arbeit der anderen übernehmen |
| Kapazität | für kleinere, klar abgegrenzte Aufgaben | für größere Systeme, parallele Arbeit |
| Vertrag | direkt mit der Fachkraft | mit dem Unternehmen, das für die Arbeit des Teams einsteht |
| Langfristiger Betrieb | hängt von der Erreichbarkeit des Freelancers ab | lässt sich organisiert übernehmen |
Ein Freelancer passt gut zu einer klar abgegrenzten Aufgabe, besonders wenn der Auftraggeber eine eigene technische Leitung hat, die die Arbeit steuert und abnimmt. Ist das System Teil des täglichen Betriebs des Unternehmens, braucht es mehrere Fachgebiete und wird es jahrelang laufen, ist ein Entwicklungsunternehmen in der Regel das geringere Risiko. Der Ausstiegsplan und die Übergabe des Quellcodes sind in beiden Fällen gleich wichtig.
Warnsignale
- Ein genauer Preis und eine genaue Frist schon nach dem ersten Gespräch, ohne Rückfragen.
- Keine schriftliche Spezifikation, oder das Angebot sagt nicht, worauf es sich bezieht.
- Der Auftraggeber darf den Code nicht sehen und würde ihn erst bei der Übergabe erhalten.
- Eine vage Antwort darauf, wer am Projekt arbeiten wird.
- Unklar, wem der Quellcode gehören wird und welche Rechte der Auftraggeber erhält.
- Ablehnung eines Auftragsverarbeitungsvertrags oder einer Geheimhaltungsvereinbarung.
- Keine funktionierende Arbeit, die sich vorzeigen ließe.
Checkliste
| Frage | In Ordnung, wenn |
|---|---|
| Sind das Ziel und die Muss-Anforderungen aufgeschrieben? | es eine kurze, von allen gleich verstandene Beschreibung gibt |
| Haben wir funktionierende Arbeit gesehen? | wir mindestens ein ähnliches System ausprobiert haben |
| Versteht der Entwickler die Aufgabe? | er Fragen gestellt und die Risiken benannt hat |
| Werden wir den Fortschritt sehen? | Vorführungen nach Etappen, Zugang zum Code-Repository |
| Ist das Angebot vergleichbar? | es sich auf denselben Umfang Punkt für Punkt bezieht und die gesonderten Posten sichtbar sind |
| Sind Quellcode und Rechte geregelt? | der Vertrag die Übergabe und den Umfang der Rechte nennt |
| Gibt es eine Geheimhaltungsvereinbarung und einen Auftragsverarbeitungsvertrag? | wo nötig, unterschrieben |
| Sind Fehlerbehebung und Betrieb festgelegt? | Schweregrade, Reaktionszeiten, SLA |
| Gibt es einen Ausstiegsplan? | Dokumentation, Zugänge, Datenexport |
| Haben wir nach der Sicherheit gefragt? | konkrete Antworten zu Berechtigungen, Updates, Datensicherung |
Häufige Fragen
Freelancer oder Entwicklungsunternehmen?
Für eine klar abgegrenzte, kleinere Aufgabe kann auch ein erfahrener Freelancer eine gute Wahl sein, besonders wenn das Unternehmen eine eigene technische Leitung hat. Ist das System Teil des täglichen Betriebs, braucht es mehrere Fachgebiete und läuft es lange, ist ein Entwicklungsunternehmen das geringere Risiko, weil die Arbeit nicht von einer einzigen Person abhängt.
Wie vergleicht man zwei Angebote?
Vergleichen lassen sich nur Angebote zur selben Spezifikation Punkt für Punkt. Fragen Sie beide Bieter, für welche Größe und welche Funktionen ihr Preis gilt, was als gesonderter Posten aufgeführt ist und wie sie mit Änderungen umgehen. Wurde die Größe mit einer genormten Methode gemessen, zum Beispiel in COSMIC-Funktionspunkten, lässt sie sich anhand derselben Spezifikation überprüfen.
Was sollte der Vertrag enthalten?
Den Umfang (die Spezifikation Punkt für Punkt), den Preis und den Zeitplan, die Übergabe des Quellcodes und den Umfang der Nutzungsrechte, die Vertraulichkeit, die Regeln für Abnahme und Fehlerbehebung, den Betrieb und das SLA, den Ausstiegsplan und, wenn auch personenbezogene Daten betroffen sind, den Auftragsverarbeitungsvertrag. Dies ist eine Information, keine Rechtsberatung.
Was passiert, wenn der Entwickler verschwindet?
Liegen Quellcode, Dokumentation und Zugänge beim Auftraggeber, kann ein anderer Entwickler das System übernehmen. Deshalb lohnt es sich, das Code-Repository vom ersten Tag an einzusehen, Hosting und Domain auf den eigenen Namen zu führen und im Vertrag einen Ausstiegsplan festzuhalten. Fehlt das, kann die Weiterführung des Systems schwierig und langsam werden.
Wem gehört der Quellcode?
Demjenigen, dem er nach dem Vertrag zusteht: Nach dem ungarischen Urheberrechtsgesetz sind die Vermögensrechte an Software übertragbar, das geschieht aber nicht automatisch. Im Vertrag sollte festgehalten werden, dass der Auftraggeber den vollständigen Quellcode erhält und welche Rechte genau er daran erwirbt. Quellcode und Nutzungsrechte regelt auch bei uns der Vertrag.
Wie können wir helfen?
So arbeiten wir: Das Erstgespräch ist kostenlos, die Spezifikation schreiben wir gemeinsam, die Größe der Software messen wir in COSMIC-Funktionspunkten, und daraus entstehen das Angebot und der Zeitplan. Die Entwicklung verläuft in Etappen, mit einer Vorführung am Ende jeder Etappe; auf Wunsch schließen wir eine Geheimhaltungsvereinbarung (NDA), und nach der Übergabe übernehmen wir auch Betrieb und Wartung. Quellcode und Nutzungsrechte regelt der Vertrag. Die Schritte beschreibt die Seite So arbeiten wir, die Methode der Preisgestaltung die Seite Preisgestaltung.
Derzeit entwickeln wir ein großes ERP- und CRM-System; unsere eigenen Entwicklungen, die sich ausprobieren lassen, stellen wir auf der Seite Unsere Projekte vor, über das Unternehmen lesen Sie auf der Seite Über uns, und Antworten auf häufige Fragen finden Sie auf der Seite Häufige Fragen. Wenn Sie einen Entwickler suchen, schreiben Sie uns über die Kontaktdaten auf der Seite Kontakt.