Softwareentwickler beauftragen: Der KMU-Guide

Einen Softwareentwickler beauftragen im Mittelstand bedeutet: das richtige Problem lösen, den richtigen Partner wählen und den Vertrag so aufsetzen, dass Sie als Auftraggeber geschützt sind. Nur 19 % der IT-Projekte werden innerhalb von Zeit und Budget abgeschlossen (Standish Group CHAOS Report, 2022). Der Rest scheitert fast nie an der Technik, sondern an schlechter Vorbereitung, falschen Erwartungen und den falschen Fragen im ersten Gespräch.

Dieser Guide ist eine Einkaufshilfe - keine Agentur-Eigenwerbung. Er beantwortet die Fragen, die ein Geschäftsführer vor dem ersten Anruf stellen sollte: Wann lohnt sich externe Entwicklung? Was kostet das realistisch? Wie erkennt man ein gutes Angebot? Und welche Vertragsklauseln schützen den Auftraggeber?

Auf einen Blick

• Nur 19 % der IT-Projekte halten Zeit und Budget (Standish Group, 2022) - die Vorbereitung entscheidet.
• 75 % aller Projektfehler entstehen bereits in der Definitions- und Initialisierungsphase (Bitkom, 2021).
• Agenturen kosten 100-180 EUR/Std., Freelancer 60-120 EUR/Std. - der Unterschied ist nicht nur Preis.
• Ein MVP ist bei klaren Anforderungen in 8-12 Wochen realisierbar (CodeGuides, 2026).
• Die wichtigsten Hebel liegen vor dem ersten Entwickler-Gespräch, nicht danach.

[IMAGE: Entscheider am Schreibtisch mit Lastenheft und Laptop - search terms: business decision maker laptop document planning]

---

Wann lohnt es sich, einen Softwareentwickler zu beauftragen?

In Deutschland fehlen laut Bitkom IT-Fachkräftestudie 2025 über 100.000 IT-Fachkräfte - ein wesentlicher Grund, warum viele Mittelständler externe Partner statt eigenem Team aufbauen. Externe Entwicklung lohnt sich immer dann, wenn ein internes Problem mit Standardsoftware nicht lösbar ist und der manuelle Workaround mehr kostet als die einmalige Entwicklung.

Die ehrliche Frage lautet nicht „Wollen wir eine eigene Software?", sondern: Was kostet uns der Status quo? Ein Betrieb mit 40 Mitarbeitern, der fünf davon täglich drei Stunden mit manuellen Excel-Übertragungen beschäftigt, verbrennt pro Jahr über 300 Arbeitstage. Bei einem Stundensatz von 35 EUR intern sind das rund 84.000 EUR - jährlich, wiederkehrend.

Gegenüber dieser Zahl sieht ein einmaliges Entwicklungsbudget von 40.000-60.000 EUR anders aus. Das ist der Rechner, den Sie vor jedem Gespräch mit einem Entwickler aufmachen sollten.

Wann externe Entwicklung sinnvoll ist:

• Ein Prozess kostet messbar mehr als seine Automatisierung, wenn man den Status quo über drei Jahre aufschreibt.
• Standardsoftware (ERP, CRM, Branchenlösung) deckt Ihre spezifischen Abläufe nicht ab - und wird es nie tun.
• Sie haben proprietäre Daten oder Abläufe, die ein Wettbewerbsvorteil sind und nicht in eine SaaS-Plattform gehören.
• Schnittstellenprobleme zwischen bestehenden Systemen erzeugen täglich manuelle Arbeit.

Wann Sie besser bei Standardsoftware bleiben:

• Ihr Prozess ist generisch und wird von mehreren etablierten Tools abgedeckt.
• Sie haben keine Zeit für Anforderungsdefinition, Feedback-Runden und interne Projektbegleitung.
• Das Budget reicht nicht für ein ordentliches MVP - und ein schlechtes MVP ist teurer als nichts.

Mehr zur Entscheidung zwischen Standardsoftware und Eigenentwicklung: Standardsoftware oder eigene App im Mittelstand.

[INTERNAL-LINK: Standardsoftware vs. eigene App → /blog/standardsoftware-oder-eigene-app-mittelstand]

---

Die vier Wege zur Umsetzung: Agentur, Freelancer, Nearshore oder Inhouse

Die Wahl des Entwicklungsmodells ist keine reine Kostenfrage. Agenturen bieten Prozessstruktur und Vertretungsregelungen; Freelancer bieten direkte Kommunikation und oft günstigere Stundensätze. Nearshore-Teams (Polen, Rumänien, Portugal) kombinieren beides - mit sprachlichen und kulturellen Risiken, die man kennen sollte.

[CHART: Vergleichsmatrix - Agentur / Freelancer / Nearshore / Inhouse nach Kosten, Verlässlichkeit, Flexibilität, Kommunikationsaufwand]

Agentur

Agenturen verlangen 2026 in Deutschland zwischen 100 und 180 EUR pro Stunde (Marktübersicht 2026, diverse Anbieter). Dafür bekommen Sie: ein Team statt einer Person, jemanden der das Projektmanagement übernimmt, und eine Vertretungsregelung wenn der Lead-Entwickler krank wird.

Der Nachteil: mehr Overhead, manchmal mehr Account-Management als tatsächliche Entwicklung. Und manchmal wird Ihr Projekt an einen Junior weitergegeben, während der Senior im Erstgespräch saß.

Geeignet für: Projekte mit mehreren Disziplinen (Backend, Frontend, UX, Testing), wenn Verlässlichkeit und Prozessstruktur wichtiger sind als der günstigste Tagessatz.

Einen ausführlichen Vergleich finden Sie hier: IT-Agentur vs. Freelancer - was ist das richtige Modell?

[INTERNAL-LINK: Agentur vs. Freelancer → /blog/it-agentur-vs-freelancer]

Freelancer

Freelancer verlangen zwischen 60 und 120 EUR pro Stunde (Marktübersicht 2026, diverse Anbieter). Die Kommunikation ist direkt, die Entscheidungswege kurz. Das funktioniert gut bei klar abgegrenzten Aufgaben: ein Frontend, eine API-Anbindung, ein Design-Refresh.

Das Risiko: wenn der Freelancer krank wird, ausfällt oder einen besseren Kunden bekommt, liegt Ihr Projekt still. Kein Urlaubs-Backup, keine strukturierten Prozesse, kein Testprotokoll per Default.

Geeignet für: klar umrissene Einzelaufgaben unter 3 Monaten, bei denen Sie selbst Projektverantwortung tragen können.

Nearshore

Teams in Polen, Rumänien oder Portugal bieten oft 40-70 EUR pro Stunde. Gute Nearshore-Teams sind technisch stark - das ist nicht die Frage. Die Frage ist: Wie viel Ihrer Zeit kostet das Alignment? Tägliche Abstimmung über Zeitzone, Sprache und Anforderungen zu koordinieren ist Arbeit. Diese Arbeit sitzt bei Ihnen.

Geeignet für: klar dokumentierte Projekte mit stabilen Anforderungen, wenn Sie oder jemand bei Ihnen im Haus als dedizierter Product Owner fungieren kann.

Inhouse

Ein eigener Entwickler kostet 2026 in Deutschland 60.000-85.000 EUR Jahresgehalt, plus Arbeitgeberkosten, plus Einarbeitung, plus das Risiko, dass er nach 18 Monaten weiterzieht. Und: Sie finden ihn kaum - nicht bei über 100.000 offenen IT-Stellen bundesweit (Bitkom, 2025).

Geeignet für: Unternehmen, die kontinuierlich Entwicklungskapazität brauchen und eine langfristige Produktstrategie fahren. Für ein einmaliges Projekt ist Inhouse fast immer die teuerste Option.

[IMAGE: Vergleich vier Entwicklungsmodelle als visuelle Matrix - search terms: business comparison matrix four options]

---

Was kostet Softwareentwicklung im Mittelstand wirklich?

Deutsche Agenturen verlangen 2026 zwischen 100 und 180 EUR pro Stunde, Freelancer zwischen 60 und 120 EUR (Marktübersicht 2026, diverse Anbieter). Das klingt abstrakt - konkret bedeutet es: ein MVP mit 300 Entwicklungsstunden kostet bei einer Agentur 30.000-54.000 EUR, bei einem guten Freelancer 18.000-36.000 EUR.

[CHART: Kostenspannen - MVP / Mittlere Geschäftsanwendung / Komplexe Plattform nach Projekttyp und Anbietermodell]

Aber Stundensätze allein sagen wenig. Entscheidend ist, wie viele Stunden gebraucht werden - und das weiß niemand mit Sicherheit, bevor die Anforderungen definiert sind.

Grobe Orientierungsrahmen nach Projekttyp:

Projekttyp	Stundenrahmen	Kostenschätzung
Einfaches MVP / Einzelfunktion	150-400 Std.	15.000-55.000 EUR
Mittlere Geschäftsanwendung	400-900 Std.	35.000-90.000 EUR
Komplexe Plattform mit Integrationen	900+ Std.	100.000 EUR+

[PERSONAL EXPERIENCE] In der Praxis erleben wir regelmäßig Projekte, die mit „wir brauchen eine einfache Lösung" starten und bei der Anforderungsaufnahme merken, dass ERP-Anbindung, Rollen- und Rechtekonzept sowie Reporting gemeinsam drei Mal so viele Stunden bedeuten wie der erste Gedanke. Das ist keine böse Absicht des Entwicklers - das ist schlicht nicht zu Beginn durchgedacht worden.

Was die Kosten nach oben treibt:

• Integrationen mit bestehenden Systemen (ERP, DATEV, CRM) - jede Schnittstelle kostet 3-6 Wochen zusätzlich.
• Mobile-Anforderungen (native App vs. responsive Web-App) - ein echtes Zwei-Plattform-Projekt.
• Compliance-Anforderungen (DSGVO, Datensicherheit, Zugriffsprotokollierung).
• Unklar definierte Anforderungen, die im Projektverlauf angepasst werden - Change Requests sind teuer.

Was die Kosten kontrollierbar hält:

• Klare Anforderungen vor dem ersten Angebot.
• Ein abgegrenztes MVP statt dem „Vollausbau von Anfang an".
• Time & Material mit festen Sprint-Budget-Reviews statt Festpreis bei unklaren Anforderungen.

Mehr Zahlen und Rechenbeispiele: Web-App-Kosten im Mittelstand - was zahlt man wirklich?

[INTERNAL-LINK: Detailkosten → /blog/web-app-kosten-mittelstand]

---

Anforderungen klären bevor man überhaupt einen Entwickler anschreibt

75 % aller Fehlerursachen in IT-Projekten entstehen bereits in der Initialisierungs- und Definitionsphase (Bitkom, 2021). Das bedeutet: wer mit unklaren Anforderungen in ein Entwicklungsprojekt startet, hat die größten Risiken schon erzeugt, bevor die erste Zeile Code geschrieben wurde.

[UNIQUE INSIGHT] Fast alle Artikel über „Softwareentwickler beauftragen" erklären, was der Entwickler tut. Diese Perspektive ist rückwärts. Der entscheidende Hebel liegt beim Auftraggeber - und er sitzt komplett vor dem ersten Gespräch. Ein Auftraggeber, der nicht beschreiben kann, welches Problem gelöst werden soll, wer die Software nutzt und was „fertig" bedeutet, bekommt kein gutes Angebot. Er bekommt ein Angebot, das so breit formuliert ist, dass jede Überraschung im Change Request endet.

Was Sie vor dem ersten Gespräch schriftlich haben sollten:

Das Problem, nicht die Lösung. „Wir brauchen eine App" ist keine Anforderung. „Fünf Außendienstmitarbeiter befüllen täglich Excel-Formulare auf dem Laptop, fotografieren sie ab und schicken sie per E-Mail ins Büro, wo sie jemand manuell ins ERP einträgt" - das ist ein Problem. Aus einem Problem kann ein Entwickler eine Lösung bauen. Aus einer Lösung baut er das, was Sie beschrieben haben - ob es hilft oder nicht.

Die wichtigsten Nutzungsszenarien. Wer macht was in der Software? Ein Mitarbeiter erfasst einen Auftrag, ein Vorgesetzter genehmigt ihn, ein Buchhalter exportiert ihn ins DATEV - das sind drei Nutzergruppen mit drei verschiedenen Anforderungen. Wenn das nicht klar ist, fehlt die Grundlage für jede sinnvolle Aufwandsschätzung.

Technische Rahmenbedingungen. Welche Systeme existieren und müssen angebunden werden? Gibt es eine IT-Richtlinie? Wird auf Windows, Mac, mobil gearbeitet? Muss die Lösung in der Cloud oder on-premise laufen?

Budget-Rahmen und Zeitrahmen. Ein Entwickler, der Ihren Budget-Rahmen nicht kennt, kann kein passendes Angebot machen. Er kann nur eines machen, das auf den maximalen Scope ausgelegt ist. Teilen Sie den Rahmen. Ein guter Partner zeigt Ihnen dann, was er dafür leisten kann - und was nicht.

Was Sie noch nicht brauchen:

Sie brauchen kein Lastenheft für das erste Gespräch. Aber Sie brauchen genug, um zu beurteilen, ob der potenzielle Partner das Problem versteht - oder nur nickt und ein Angebot schickt.

Wie Sie strukturierte Anforderungen formulieren: Software-Anforderungen richtig formulieren - Schritt für Schritt

Und wenn Sie ein formales Lastenheft brauchen: Lastenheft-Vorlage für KMU - kostenlos zum Download

[INTERNAL-LINK: Anforderungen formulieren → /blog/software-anforderungen-formulieren] [INTERNAL-LINK: Lastenheft-Vorlage → /blog/lastenheft-vorlage-kmu]

---

Wie man Angebote vergleicht und den richtigen Partner auswählt

Ein gutes Angebot enthält mehr als eine Zahl. Es enthält eine Beschreibung des Verständnisses - was der Entwickler oder die Agentur als das eigentliche Problem identifiziert hat. Wenn das Angebot nur eine Preisspanne und eine Feature-Liste zurückliefert, haben Sie Ihre Anforderungen hineingebaut - der Anbieter hat sie nicht verstanden.

[IMAGE: Geschäftsführer prüft Angebote am Tisch mit Notizen - search terms: business owner reviewing proposals documents comparison]

Was ein gutes Angebot enthält:

• Eine Zusammenfassung des Problems in eigenen Worten des Anbieters. Wenn das fehlt oder falsch ist, ist das ein Warnsignal.
• Eine klare Beschreibung, was im Scope ist - und was explizit nicht.
• Aufwandsschätzung nach Phasen oder Teilbereichen, nicht nur eine Gesamtzahl.
• Technologiebegründung. Warum diese Technologie? Wenn der Anbieter „das ist unser Standard" sagt ohne Begründung, ist Nachfragen sinnvoll.
• Klarer Kommunikationsprozess: Wer ist Ihr Ansprechpartner? Wie oft gibt es Updates? In welcher Form?

Die drei wichtigsten Fragen im Erstgespräch:

1. „Zeigen Sie mir ein Projekt, das meinem ähnlich ist - und was dabei schief gelaufen ist." Ein guter Anbieter beantwortet das ehrlich. Wer nur Erfolgsgeschichten erzählt, verkauft.
2. „Wer arbeitet konkret an meinem Projekt?" Account Manager und Lead-Entwickler im Erstgespräch, aber am Ende macht ein Junior die Arbeit - das passiert. Fragen Sie explizit.
3. „Was passiert, wenn sich die Anforderungen ändern?" Die Antwort zeigt Ihnen das Vertragsmodell und die Prozessreife des Anbieters.

Warnsignale bei Angeboten:

• Keine Rückfragen nach dem Briefing. Wer ohne Rückfragen ein vollständiges Angebot liefert, hat Ihr Briefing nicht durchdacht.
• Keine Phasenstruktur. Ein Angebot ohne Meilensteine und Abnahmen schützt den Auftragnehmer, nicht Sie.
• „Kein Problem, machen wir alles" ohne Einschränkungen. Jedes Projekt hat Einschränkungen. Wer das nicht anspricht, verschiebt sie in den Projektverlauf.
• Referenzen nur auf Anfrage. Wer solide Arbeit macht, zeigt sie proaktiv.

Für einen kompletten Ablauf eines Softwareprojekts von der Anfrage bis zum Go-Live: Web-App-Entwicklung Ablauf und Phasen erklärt

[INTERNAL-LINK: Projektablauf → /blog/webapp-entwicklung-ablauf-phasen]

---

Vertragsmodelle im Überblick: Festpreis, Time & Material und Hybrid

Festpreis und Time & Material sind keine Geschmacksfrage - sie sind eine Risikoverteilung. Beim Festpreis trägt der Entwickler das Risiko von Mehraufwand; beim Time & Material trägt es der Auftraggeber. Der Trick liegt im Hybrid: Festpreis für den Teil, der klar ist, und Time & Material für den Teil, der es nicht ist.

Festpreis

Der Auftraggeber weiß vorab, was er zahlt. Das klingt sicher - ist es aber nur, wenn die Anforderungen lückenlos definiert sind. In der Praxis sind sie das selten. Was passiert bei Änderungen? Change Requests. Jede Anpassung, die nicht exakt so im Lastenheft stand, kostet extra - oft zu den höchsten Stundensätzen im Angebot.

Festpreis funktioniert gut bei: Standard-Projekten mit klar beschreibbarer Abnahme, wenig Unbekanntem und stabilen Anforderungen.

Festpreis funktioniert schlecht bei: allem, was erkundet werden muss, neu ist oder sich mit dem Nutzungsfeedback weiterentwickeln soll.

Time & Material

Sie zahlen für geleistete Stunden - egal wie viel oder wenig. Das ist ehrlicher als ein Festpreis bei unklaren Anforderungen, aber das Budget kann steigen. Die Kontrolle liegt beim Auftraggeber: klare Sprint-Budgets, regelmäßige Reviews und das Recht, das Projekt zu jedem Zeitpunkt zu stoppen.

Time & Material funktioniert gut bei: agiler Entwicklung, evolvierten Anforderungen und Projekten, bei denen Nutzerfeedback in die Entwicklung einfließt.

Der entscheidende Hebel: Vereinbaren Sie Sprint-Budget-Reviews. Alle zwei Wochen: Was wurde gebaut? Was kostet es bisher? Was ist der Plan für den nächsten Sprint? So bleibt Ihnen die Kontrolle.

Hybrid - die sinnvolle Empfehlung für KMU

[PERSONAL EXPERIENCE] Wir empfehlen fast immer dasselbe Modell: Festpreis für die Konzeptionsphase (Anforderungsaufnahme, Architektur, Wireframes, schriftliche Spezifikation), danach Time & Material mit Sprint-Budget-Reviews für die Umsetzung. So ist die Grundlage klar definiert und bezahlt, bevor die teure Entwicklungsarbeit beginnt. Und Sie wissen vor dem ersten Sprint-Start, ob das Verständnis übereinstimmt.

Eine Konzeptionsphase kostet typischerweise 3.000-8.000 EUR - und spart im Projektverlauf ein Vielfaches.

Ausführlicher Vergleich beider Modelle mit Rechenbeispielen: Festpreis oder Time & Material in der Softwareentwicklung

[INTERNAL-LINK: Festpreis vs. Time & Material → /blog/softwareentwicklung-festpreis-zeitaufwand]

Vertragsklauseln, die den Auftraggeber schützen:

• Quellcode-Übergabe: Stellen Sie sicher, dass Sie den kompletten Quellcode erhalten - nicht nur ein Deployment. Ohne Quellcode sind Sie dauerhaft abhängig vom Anbieter.
• Abnahmebedingungen: Was muss erfüllt sein, damit eine Phase als abgeschlossen gilt? Schriftlich, nicht mündlich.
• Daten-Eigentümerschaft: Alle Daten, die in der Software entstehen, gehören Ihnen. Das klingt selbstverständlich - ist es aber nicht immer vertraglich abgesichert.
• Übergabe-Dokumentation: Technische Dokumentation und Deployment-Anleitung als Liefergegenstand im Vertrag aufführen. Sonst gibt es keine.
• Exit-Regelung: Was passiert, wenn Sie den Vertrag kündigen? Übergabe-Zeitraum, Backup der Daten, Zugänge.

[CHART: Vertragsmodell-Entscheidungsbaum - Festpreis / T&M / Hybrid nach Anforderungsklarheit und Projektgröße]

---

Die größten Fehler beim Beauftragen von Softwareentwicklern - und wie man sie vermeidet

Nur 19 % der IT-Projekte werden innerhalb von Zeit und Budget abgeschlossen (Standish Group CHAOS Report, 2022). Das ist eine drastische Zahl - aber sie hat einen klaren Grund: die häufigsten Fehler passieren nicht bei der Entwicklung, sondern bei der Beauftragung. Und die meisten davon sind vermeidbar.

[IMAGE: Whiteboard mit Projektplan und durchgestrichenen Punkten - search terms: project planning mistakes whiteboard problem solving]

Fehler 1: Anforderungen im Gespräch definieren statt schriftlich vorher.

Das Erstgespräch ist kein Ort für Anforderungsaufnahme. Es ist ein Ort, um zu prüfen, ob der Anbieter das Problem versteht. Wer ins Erstgespräch geht und hofft, dass der Entwickler schon rausfindet was gebraucht wird, gibt die Kontrolle ab. Schreiben Sie vorher auf, was das Problem ist, wer die Nutzer sind und was „fertig" bedeutet.

Fehler 2: Das günstigste Angebot wählen ohne Kontext.

Ein Angebot für dasselbe Projekt kann von 15.000 bis 80.000 EUR variieren - nicht weil manche Anbieter betrügen, sondern weil sie unterschiedliche Scopes verstanden haben. Das günstigste Angebot hat fast immer den engsten Scope - und die breiteste Lücke zu dem, was Sie wirklich brauchen. Diese Lücke zeigt sich als Change Request.

Fehler 3: Kein definiertes Abnahmekriterium.

Was muss die Software können, damit Sie sie als fertig akzeptieren? Diese Frage sollten Sie beantworten können, bevor die Entwicklung beginnt. Wenn die Antwort „na ja, das merken wir dann" ist, gibt es keine Grundlage für eine Abnahme. Und ohne Abnahmekriterium kann ein Projekt theoretisch ewig laufen.

Fehler 4: Quellcode und Dokumentation nicht im Vertrag sichern.

Wer das vergisst, stellt fest: der Anbieter hostet die Software, hat die Zugangsdaten und besitzt faktisch den Code. Ein Anbieterwechsel kostet dann so viel wie eine Neuentwicklung. Quellcode-Übergabe, Deployment-Dokumentation und Zugangsdaten als explizite Liefergegenstände in den Vertrag.

Fehler 5: Kein interner Ansprechpartner für das Projekt.

Softwareprojekte brauchen auf Auftraggeberseite jemanden, der Entscheidungen trifft, Rückfragen beantwortet und das Projekt intern voranbringt. „Einfach machen und mir bescheid geben, wenn es fertig ist" funktioniert nicht. Wer keinen internen Product Owner benennt, bekommt eine Software, die das Entwickler-Verständnis abbildet - nicht das eigene.

Fehler 6: Den MVP-Gedanken überspringen.

Die häufigste Budgetspirale: alle gewünschten Features von Anfang an in den Scope. Dann kostet das Projekt drei Mal so viel wie erwartet, dauert doppelt so lang - und am Ende nutzen die Mitarbeiter 20 % der Funktionen. Ein MVP mit Kernfunktionen, das nach vier Wochen im Einsatz ist und dann auf Basis echter Nutzung erweitert wird, ist fast immer die wirtschaftlichere Entscheidung.

Warum so viele Softwareprojekte scheitern - die strukturellen Gründe: Warum Softwareprojekte scheitern - und wie man es verhindert

[INTERNAL-LINK: Scheiternsgründe → /blog/softwareprojekt-scheitert-gruende]

---

Checkliste: So starten Sie Ihr Softwareprojekt auf einem soliden Fundament

Ein MVP ist bei klar definierten Anforderungen häufig in 8-12 Wochen realisierbar (CodeGuides, 2026). Die Vorbedingung steht in diesem Satz: klar definierte Anforderungen. Diese Checkliste gibt Ihnen die konkreten Schritte, bevor Sie den ersten Entwickler anschreiben.

Phase 1: Vor dem ersten Gespräch

• Problem schriftlich formulieren. Nicht die Lösung, das Problem. Was passiert heute? Wer ist betroffen? Was kostet es?
• Nutzungsszenarien skizzieren. Wer nutzt die Software? Was macht jede Nutzergruppe darin? Mindestens drei typische Abläufe aufschreiben.
• Bestandssysteme auflisten. Was muss angebunden werden? ERP, DATEV, CRM, externe APIs? Welche davon sind Pflicht, welche optional?
• Budget-Rahmen festlegen. Einen realistischen Rahmen - auch wenn er Ihnen zu niedrig erscheint. Ein guter Partner zeigt Ihnen, was dafür möglich ist.
• Zeitrahmen definieren. Gibt es einen harten Deadline-Grund? (Gesetzesänderung, Saisonstart, laufendes System läuft aus?)
• „Fertig" definieren. Was muss die Software mindestens können, damit Sie sie produktiv einsetzen? Das ist Ihr MVP.

Phase 2: Anbieter-Evaluierung

• Mindestens drei Angebote einholen. Nicht um den günstigsten zu nehmen, sondern um zu verstehen, wie verschieden das Problem gesehen wird.
• Referenzprojekte anfragen. Ähnliche Projekte sehen, nicht nur Logos und Testimonials.
• „Was lief schief?" fragen. Die ehrlichste Qualitätsprüfung, die es gibt.
• Ansprechpartner benennen lassen. Wer arbeitet an Ihrem Projekt? Senior oder Junior? Projektleiter intern oder extern?
• Angebote auf Scope-Klarheit prüfen. Was ist explizit ausgeschlossen? Was gehört zu Change Requests?

Phase 3: Vertragsabschluss

• Quellcode-Übergabe als Liefergegenstand ins Vertrag.
• Abnahmekriterien schriftlich definieren. Welche Tests müssen bestanden sein? Welche Funktionen müssen laufen?
• Daten-Eigentümerschaft klären. Alle Daten gehören Ihnen - explizit so formuliert.
• Dokumentation als Liefergegenstand. Technische Dokumentation, Deployment-Anleitung, Benutzerhandbuch (falls relevant).
• Exit-Regelung vereinbaren. Was passiert bei Vertragskündigung? Backup, Übergabe, Zugangsdaten.
• Kommunikationsrituale vereinbaren. Wie oft Updates? In welchem Format? Wer ist der Eskalationsweg?

Phase 4: Projektstart

• Internen Ansprechpartner benennen. Jemand im Haus hat die Product-Owner-Rolle. Diese Person trifft Entscheidungen, keine Kommission.
• Erstes Sprint-Review-Datum festlegen. Nicht warten, bis das Projekt fertig ist. Alle zwei Wochen reviewen.
• Feedback-Prozess für Mitarbeiter klären. Wer testet die Software während der Entwicklung? Wie kommt Feedback zum Entwickler?
• Pilotgruppe definieren. Wer nutzt die Software zuerst, bevor sie für alle ausgerollt wird?

[CHART: Gantt-ähnliche Übersicht - Projektphasen von Anforderungsdefinition bis Go-Live mit typischen Zeiträumen]

Wenn Sie konkret wissen wollen, wie ein Projekt bei stakk abläuft - von der Anfrage bis zum Go-Live: Projekt mit stakk: vom Erstgespräch bis Go-Live

Und wenn Ihr konkreter Bedarf eher im Handwerk liegt: Handwerkersoftware vs. Custom Web-App - was wann sinnvoll ist

[INTERNAL-LINK: Projektablauf stakk → /blog/projekt-mit-stakk-erstgespraech-go-live] [INTERNAL-LINK: Handwerkersoftware → /blog/handwerkersoftware-vs-custom-webapp]

---

Fazit

Einen Softwareentwickler im Mittelstand zu beauftragen ist kein technisches Problem. Es ist ein Einkaufsproblem - mit denselben Grundregeln wie jeder andere Einkauf von Leistungen: Problem klar definieren, Angebote vergleichen, Vertrag schützt den Auftraggeber, und jemand im Haus ist verantwortlich.

Die häufigsten Misserfolge - und es gibt laut Standish Group viele davon - entstehen nicht, weil Entwickler schlecht sind. Sie entstehen, weil das Briefing unklar war, das günstigste Angebot gewählt wurde, Abnahmekriterien fehlten oder kein interner Ansprechpartner existierte.

Wenn Sie die Checkliste aus diesem Artikel abarbeiten, bevor Sie den ersten Entwickler anschreiben, haben Sie die wichtigsten Risiken bereits adressiert. Alles andere - welches Vertragsmodell, welche Technologie, welches Team - ist sekundär gegenüber dieser Vorbereitung.

Wenn Sie ein konkretes Projekt im Kopf haben und schauen wollen, was es kostet und wie es realisierbar ist: Unsere Custom Web-App Entwicklung begleitet KMU und Handwerksbetriebe von der Anforderungsaufnahme bis zum Go-Live - ohne Consultant-Overhead, mit klarer Kostentransparenz.

[INTERNAL-LINK: Custom Web-Apps Leistungsseite → /leistungen/custom-webapps]

---

Quellen: Standish Group CHAOS Report 2022; Bitkom „Heiter Scheitern im Projekt" (2021); Bitkom IT-Fachkräftestudie 2025; Marktübersicht Stundensätze deutsche Agenturen und Freelancer 2026 (diverse Anbieter); CodeGuides MVP-Entwicklungszeiten 2026.