Wie wählt man einen Entwickler für eine geschäftliche Webanwendung aus?

Einen geeigneten Entwicklungspartner sollte man nicht allein nach Preis und Portfolio beurteilen. Er sollte das geschäftliche Problem verstehen, die erste Etappe klar abgrenzen, Annahmen und Risiken benennen und festhalten, woran beide Seiten die Fertigstellung erkennen. Vor Projektbeginn müssen außerdem das Eigentum an Code und Daten, der Zugriff auf Repository und Konten sowie Tests, Abnahme, Inbetriebnahme, Übergabe und spätere Betreuung geklärt sein.

Angebote lassen sich erst fair vergleichen, wenn sie einen ähnlichen Umfang und ein vergleichbares Ergebnis abdecken. Ein niedriger Preis kann bedeuten, dass Datenmigration, Tests oder Betreuung nach dem Start fehlen. Ein höherer Preis ist ebenfalls kein Qualitätsnachweis, wenn das Angebot nicht erklärt, was das Unternehmen dafür erhält.

Eine kleine und eindeutig beschriebene Aufgabe braucht nicht immer eine umfangreiche Analyse. Umfasst die Anwendung jedoch mehrere Rollen, Integrationen, Ausnahmen und wichtige Daten, sollte eine schnelle Schätzung ohne Rückfragen genauer geprüft werden.

Prüfen Sie zuerst, ob der Anbieter das geschäftliche Problem versteht

Das erste Gespräch sollte sich nicht ausschließlich um Technologien und eine Liste von Masken drehen. Zuerst muss geklärt werden, wer mit dem heutigen Prozess arbeitet, wo Verzögerungen entstehen, welche Daten benötigt werden und was nach der Umsetzung anders funktionieren soll.

Ein guter Anbieter fragt beispielsweise:

• wer die einzelnen Aufgaben ausführt und wer Entscheidungen trifft;
• in welchen Programmen, Tabellen oder Dateien die Daten liegen;
• wo Arbeit wiederholt oder manuell erledigt wird;
• welche Ausnahmen im tatsächlichen Ablauf vorkommen;
• was in der ersten Etappe funktionieren muss und was warten kann;
• woran Nutzer und Auftraggeber das Ergebnis bewerten.

Ein weiteres gutes Zeichen ist die Bereitschaft, eine einfachere Lösung vorzuschlagen. Manchmal reichen die Konfiguration eines vorhandenen Systems, ein zusätzliches Modul oder eine Integration. Empfiehlt der Anbieter sofort eine vollständige Neuentwicklung, sollte er erklären können, warum einfachere Varianten nicht passen.

Für das erste Gespräch brauchen Sie kein technisches Lastenheft. Hilfreicher ist eine kurze Beschreibung des Problems, des heutigen Ablaufs und des gewünschten Ergebnisses. Der Artikel Benötigte Software ohne technisches Lastenheft beschreiben hilft bei der Vorbereitung.

Finden Sie heraus, wie der Anbieter mit offenen Punkten umgeht

Zu Beginn eines neuen Projekts sind Informationen oft noch unvollständig. Ein Unternehmen kennt sein Problem, aber vielleicht noch nicht den endgültigen Datenfluss, das Berechtigungsmodell oder die Art der Integration. Ein seriöses Angebot trennt bestätigte Anforderungen von Annahmen.

Fragen Sie, welche Informationen der Anbieter braucht, bevor er Preis und Termin nennt. Achten Sie darauf, ob er Folgendes benennen kann:

• Entscheidungen, die vor dem Start getroffen werden müssen;
• Daten und Zugänge, die geprüft werden müssen;
• Annahmen mit Einfluss auf die Kalkulation;
• Elemente, die nicht zur ersten Etappe gehören;
• Risiken durch externe Systeme oder Anbieter;
• Situationen, in denen der Umfang erneut abgestimmt werden muss.

Bei einer einfachen Aufgabe können einige Unterlagen, ein kurzes Gespräch und ein klares Abnahmekriterium genügen. Bei vielen Prozessen, Rollen, Datenquellen und Integrationen kann eine separate Business-Analyse mit Festlegung des MVP-Umfangs sinnvoll sein. Sie ist kein Pflichtzusatz für jeden Auftrag. Sie soll Unsicherheit dort verringern, wo beide Seiten sonst unterschiedliche Projekte kalkulieren würden.

Vergleichen Sie dieselbe erste Etappe, nicht nur die Summen

Zwei Angebote können ähnliche Begriffe verwenden und dennoch völlig unterschiedliche Leistungen enthalten. Das eine umfasst vielleicht Datenmigration, Tests und Inbetriebnahme, das andere nur eine Anwendung mit Beispieldaten. Ordnen Sie deshalb beide Vorschläge vor dem Preisvergleich nach derselben Liste.

Eine ausführlichere Erklärung der Preisunterschiede finden Sie im Artikel Was kostet eine Webanwendung für Unternehmen?. Ein Stundensatz allein zeigt weder den Arbeitsaufwand noch die Prüfungen oder das Ergebnis, das der Kunde erhält.

Klären Sie Eigentum an Code, Daten und Konten vor der Unterschrift

Eigentum und Zugänge werden häufig erst am Ende einer Zusammenarbeit besprochen. Dann ist ihre Ordnung besonders schwierig. Halten Sie vor dem Start fest:

• wer unter welchen Bedingungen Rechte am Projektcode erhält;
• wo das Repository liegt und wer darauf zugreifen kann;
• wem Domain, Hosting und Cloud-Konten gehören;
• über wessen Konto externe APIs, E-Mail, SMS und andere Dienste abgerechnet werden;
• wie der Kunde einen Datenexport und Unterlagen für die weitere Arbeit erhält;
• welche Bibliotheken, Vorlagen oder Dienste eigenen Lizenzbedingungen unterliegen;
• was nach Ende der Zusammenarbeit mit den Zugängen des Anbieters geschieht.

Gehen Sie nicht davon aus, dass mit der Bezahlung einer Rechnung automatisch sämtliche Rechte, Codes, Lizenzen und Konten übertragen werden. Der Vertrag muss den vereinbarten Umfang nennen.

Bei Domin Software nutzen wir ein Modell, in dem der Kunde Eigentümer seiner Domain, seines Hostings und der abgerechneten Dienstkonten bleibt. Wir erhalten den abgestimmten Zugang, den wir für unsere Arbeit benötigen. Verantwortung, Code und Übergabegegenstände müssen trotzdem für jedes Projekt konkret vereinbart werden.

Fragen Sie, wie die wichtigsten Funktionen geprüft werden

Die Aussage „Die Anwendung wird getestet“ ist zu allgemein. Ein Kontaktformular, ein Rechnungsimport und ein System mit Rollen, Zahlungen und Kundendaten brauchen unterschiedliche Prüfungen.

Bitten Sie um klare Antworten auf folgende Fragen:

1. Welche Prozesse sind kritisch und wie werden sie geprüft?
2. Findet die Abnahme in einer Testumgebung oder auf andere sichere Weise statt?
3. Wie werden Rollen, Berechtigungen und sensible Vorgänge geprüft?
4. Wer erstellt vor einer Änderung die Sicherung, und ist die Wiederherstellung bekannt?
5. Wie laufen Inbetriebnahme und Kontrolle direkt nach dem Start ab?
6. Was geschieht, wenn die Inbetriebnahme die Abnahmekriterien nicht erfüllt?
7. Wie werden Fehler gemeldet und wer bewertet ihre Dringlichkeit?

Auch Sicherheit sollte durch konkrete Anforderungen und Prüfungen beschrieben werden, nicht durch ein allgemeines Versprechen. OWASP ASVS stellt Anforderungen bereit, die bei Entwurf und Prüfung der Sicherheit von Webanwendungen helfen können. NIST SSDF beschreibt sichere Entwicklungspraktiken, die sich in einen vorhandenen Arbeitsprozess integrieren lassen. Das bedeutet nicht, dass jedes kleine Projekt einen vollständigen Standard umsetzen muss. Die Prüftiefe sollte zu Risiko, Datenart und möglichen Folgen eines Fehlers passen.

Prüfen Sie die Kommunikation an einem konkreten Beispiel

Eine schnelle Antwort auf eine Vertriebsanfrage beweist noch keine klare Kommunikation während der Umsetzung. Bitten Sie den Anbieter, einen wichtigen Teil des Angebots in verständlicher Sprache zu erklären, etwa die Abnahme, das Risiko einer Integration oder den Unterschied zwischen erster Etappe und späterer Entwicklung.

Achten Sie darauf, ob der Anbieter:

• Vereinbarungen zusammenfasst und fehlende Entscheidungen benennt;
• Folgen einer Entscheidung erklärt, statt nur Technologien aufzuzählen;
• offen sagen kann, was noch nicht bekannt ist;
• einen Fehler von einer Umfangsänderung unterscheidet;
• Entscheidungsträger und den Ablauf für Freigaben festlegt;
• angibt, wie häufig er über den Fortschritt berichtet.

Gute Kommunikation bedeutet nicht, schwierige Informationen zu vermeiden. „Das können wir erst verlässlich kalkulieren, wenn wir Datenformat und API-Dokumentation geprüft haben“ ist hilfreicher als eine genaue Zahl, die auf Vermutungen beruht.

Ein Portfolio sollte die Arbeit zeigen, nicht nur die Oberfläche

Ein Screenshot belegt, dass es eine Oberfläche gab. Er erklärt nicht, welches Problem gelöst wurde, welche Teile der Anbieter umgesetzt hat oder ob das System heute noch verwendet wird. Suchen Sie in einer Fallstudie nach getrennten Angaben zu Problem, Leistungsumfang, Einschränkungen und einem nachvollziehbaren Ergebnis.

Ein ähnlicher Prozess kann wichtiger sein als dieselbe Branche. Erfahrung mit einem Buchungssystem kann für ein Projekt mit mehreren Rollen, Kalendern und Abrechnungen relevant sein, auch wenn der neue Kunde in einem anderen Bereich tätig ist.

Unsere Fallstudien zeigen unterschiedliche Arten von Komplexität:

• 44Islands zeigt einen Buchungsprozess und ein System, das schrittweise für verschiedene Rollen entwickelt wurde;
• HUB.ITM.PL zeigt ein historisches Projekt zur Zuordnung von Daten aus verschiedenen Buchhaltungsprogrammen zum Format EDI++;
• HUB-2-API zeigt einen historischen Ablauf mit Produkten, Angeboten auf eBay.de, Bestellungen und einer API für drei Kunden in Frankreich.

HUB.ITM.PL und HUB-2-API sind nicht mehr produktiv im Einsatz. Sie belegen frühere Arbeit mit Daten, Integrationen und Geschäftsprozessen, nicht die heutige Verfügbarkeit der beteiligten externen Dienste. Solche Einschränkungen sollten in jedem Portfolio erkennbar sein.

Vereinbaren Sie Übergabe und Betreuung vor Projektbeginn

Die Abnahme einer funktionierenden Anwendung regelt noch nicht alle Verantwortlichkeiten. Klären Sie, was der Kunde am Ende einer Etappe erhält und wer die Lösung danach betreut.

Zur Übergabe können gehören:

• Zugang zum Repository und zur passenden Codeversion;
• Startanleitung und Beschreibung wichtiger Abhängigkeiten;
• Zugangsdaten, die über einen sicheren Kanal übergeben werden;
• Liste externer Dienste und ihrer Abrechnungstermine;
• Kopie oder Export der Daten im vereinbarten Umfang;
• Abnahmeergebnisse und bekannte Einschränkungen;
• Informationen zu Sicherungen, Monitoring, Aktualisierungen und Fehlermeldungen.

Betreuung kann Teil des Projekts, Gegenstand eines eigenen Vertrags oder eine Leistung nach Bedarf sein. Es gibt kein Modell, das für jedes Unternehmen passt. Begriffe wie Reaktionszeit, Servicezeiten und enthaltene Updates müssen eine konkrete Bedeutung haben. Wenn Sie Entwicklung und spätere Betreuung trennen möchten, sehen Sie sich unsere Wartung von Anwendungen und Online-Shops an.

Warnsignale, die eine weitere Frage erfordern

Ein einzelnes Warnsignal schließt einen Anbieter nicht automatisch aus. Es sollte jedoch zu einer konkreten Nachfrage führen. Seien Sie vorsichtig, wenn:

• ein Gesamtpreis und Termin genannt werden, bevor Rollen, Daten, Integrationen und Ausnahmen untersucht wurden;
• eine Technologie als Garantie für Sicherheit oder Skalierbarkeit dargestellt wird;
• das Angebot Eigentum an Repository, Daten und Konten nicht regelt;
• Abnahmekriterien und ausdrückliche Ausschlüsse fehlen;
• niemand erklären kann, wie die Lösung getestet und in Betrieb genommen wird;
• das Portfolio nicht zeigt, welche Arbeit das Unternehmen tatsächlich ausgeführt hat;
• Regeln für Änderungen, Fehlerbehebung, Betreuung und Vertragsende unklar sind;
• vor Klärung grundlegender Annahmen auf eine schnelle Unterschrift gedrängt wird.

Das Risiko liegt nicht in unterschiedlichen Meinungen oder einer nötigen Analyse. Größer ist das Risiko, wichtige Fragen offen zu lassen, während beide Seiten glauben, denselben Umfang zu meinen.

Was sollten Sie für das erste Gespräch vorbereiten?

Sie brauchen zu Beginn kein langes Lastenheft. Bereiten Sie Unterlagen vor, die das wirkliche Problem zeigen:

1. eine kurze Beschreibung der Situation und des gewünschten Ergebnisses;
2. den heutigen Ablauf und die beteiligten Personen;
3. wichtige Datenquellen, Systeme und benötigte Integrationen;
4. drei Prioritäten der ersten Etappe;
5. zeitliche, finanzielle oder infrastrukturelle Einschränkungen;
6. Beispiele für ungewöhnliche Fälle und Ausnahmen;
7. eine Person, die Entscheidungen treffen kann;
8. Beispielmaterial ohne Passwörter, Schlüssel oder echte Kundendaten.

Nutzen Sie dafür den kostenlosen Projektbriefing-Generator. Er führt durch die wichtigsten Fragen und erstellt eine geordnete Zusammenfassung für das nächste Gespräch. Das Werkzeug sendet das Projekt nicht automatisch und ersetzt keine Analyse eines größeren Umfangs.

Häufig gestellte Fragen

Brauchen wir vor der Auswahl ein vollständiges technisches Lastenheft?

Nein. Zu Beginn genügen eine Beschreibung des Problems, des heutigen Prozesses, der Nutzer, der Daten und des erwarteten Ergebnisses. Eine technische Spezifikation kann später entstehen, wenn Lösung und Umfang besser verstanden sind.

Ist ein Freelancer, ein kleines Unternehmen oder ein Softwarehaus die bessere Wahl?

Darauf gibt es keine allgemeine Antwort. Entscheidend sind Projektgröße, Risiko, benötigte Verfügbarkeit, Spezialisierung und Kommunikation. Wichtiger als die Bezeichnung ist, wer die Arbeit tatsächlich ausführt, was bei seiner Abwesenheit geschieht und wie Code und Wissen übergeben werden.

Wie vergleichen wir zwei Angebote mit unterschiedlichem Umfang?

Vergleichen Sie zuerst das Ergebnis der ersten Etappe, Funktionen, Rollen, Daten, Integrationen, Tests, Inbetriebnahme und Ausschlüsse. Bewerten Sie den Preis danach. Lassen sich die Umfänge nicht auf dieselbe Liste bringen, bitten Sie um eine Präzisierung.

Wem sollten Code, Repository und Daten gehören?

Die Bedingungen müssen eindeutig im Vertrag stehen. Das beauftragende Unternehmen sollte mindestens wissen, wo Code und Daten liegen, wer Zugriff hat, welche Lizenzen gelten und wie es die benötigten Unterlagen am Ende erhält. Die Bezahlung einer Etappe ersetzt diese Vereinbarungen nicht.

Ist eine kostenpflichtige Analyse vor jedem Angebot erforderlich?

Nein. Eine einfache Aufgabe mit klarem Ergebnis lässt sich oft anhand einer kurzen Beschreibung und einiger Unterlagen kalkulieren. Eine separate Analyse ist sinnvoll, wenn mehrere Prozesse, Datenquellen, Rollen, Integrationen und offene Punkte den Umfang wesentlich beeinflussen.

Was sollten wir zu Tests und Sicherheit fragen?

Fragen Sie, welche Prozesse geprüft werden, wo die Abnahme stattfindet, wie Rollen und sensible Vorgänge kontrolliert werden, wer die Sicherung erstellt und wie die Inbetriebnahme abgesichert wird. Die Prüftiefe sollte zum Projektrisiko passen.

Was sollte am Projektende übergeben werden?

Das hängt vom Vertrag ab. Sinnvoll sind meist Zugang zu Code und Repository, Startanleitung, Informationen zu Abhängigkeiten und externen Diensten, Datenexport, Abnahmeergebnisse und bekannte Einschränkungen. Vereinbaren Sie außerdem die sichere Übergabe von Zugangsdaten und den späteren Entzug der Anbieterzugänge.

Muss die Wartung Teil desselben Vertrags sein?

Nein. Wartung kann im Projekt enthalten sein, separat beauftragt oder an einen anderen Anbieter übergeben werden. Vor dem Start sollte aber feststehen, wer für Monitoring, Sicherungen, Updates, Störungen und den Kontakt mit Infrastrukturanbietern zuständig ist.

Geben Sie allen Anbietern denselben Ausgangspunkt

Beginnen Sie mit dem Problem, dem ersten benötigten Ergebnis und den wichtigsten Einschränkungen. Erstellen Sie mit dem Projektbriefing-Generator eine Zusammenfassung, die Sie allen verglichenen Anbietern geben. So startet jedes Gespräch mit denselben Informationen.

Wenn Sie einen Partner für eine individuelle Anwendung suchen, sehen Sie sich die PHP- und Laravel-Entwicklungsleistungen von Domin Software an. Nach Prüfung Ihrer Beschreibung können wir sagen, ob ein kurzes Gespräch und eine kleine Etappe genügen oder ob zuerst eine separate Analyse sinnvoll ist. Einen vollständigen Preis und Termin nennen wir nicht, bevor Umfang, Daten, Integrationen und Abnahmemethode bekannt sind.

Quellen

• OWASP Application Security Verification Standard, OWASP, stabile Version 5.0.0, veröffentlicht am 30.05.2025, abgerufen am 30.10.2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, veröffentlicht im Februar 2022, abgerufen am 30.10.2026.