Software entwickeln lassen ohne Technik-Wissen: So wirst du nicht über den Tisch gezogen

“Ich nicke im Meeting und verstehe die Hälfte nicht.” Diesen Satz hören wir öfter, als man denken würde. Meistens leise gesagt. Meistens erst beim zweiten Termin, wenn das Projekt schon läuft.

Software entwickeln lassen ohne Technikwissen ist eine unangenehme Position. Du gibst einen fünf- oder sechsstelligen Betrag für etwas aus, das du selbst nicht bewerten kannst. Du siehst keinen Code. Du kannst nicht beurteilen, ob “wir müssen da noch die Architektur refactoren” eine ehrliche Auskunft ist oder die höfliche Umschreibung für drei verlorene Wochen.

Und ja, das wird ausgenutzt. Nicht von allen, aber häufiger, als die Branche zugibt.

Software entwickeln lassen ohne Technikwissen ist ein Vertrauensproblem, kein Wissensproblem

Du wirst kein Entwickler mehr. Musst du auch nicht. Fast alles, was in einem Softwareprojekt schiefgeht, kannst du ohne eine einzige Zeile Code erkennen. Du musst nur wissen, worauf du schaust.

Warum so viele Mittelständler hier auflaufen, hat einen strukturellen Grund: Es fehlt der eigene Fachmann, der gegenlesen könnte. Laut Bitkom fehlen in Deutschland rund 109.000 IT-Fachkräfte, und eine offene IT-Stelle bleibt im Schnitt 7,7 Monate unbesetzt. Immerhin ein Rückgang, zwei Jahre zuvor waren es noch 149.000. In der aktuellen Bitkom-Befragung von 604 Unternehmen ab 20 Beschäftigten nennen 70 Prozent den Fachkräftemangel als Hemmnis der Digitalisierung. Der Wert schwankt über die Jahre zwischen 70 und 78 Prozent. Die Richtung bleibt dieselbe.

Du sitzt also einem Anbieter gegenüber, der alles weiß, und hast niemanden im Haus, der mitliest. Diese Schieflage ist bei manchen Dienstleistern kein Zufall, sondern Teil des Geschäftsmodells. Abbauen wollen die sie nicht, die pflegen sie. Wer dir bei jeder Rückfrage das Gefühl gibt, du hättest sie besser nicht gestellt, ist der falsche Partner. Punkt.

Sieben Prüffragen, die du ohne eine Zeile Code stellen kannst

Stell diese Fragen vor der Unterschrift. Interessant ist nicht nur die Antwort, sondern auch, wie schnell und wie ruhig sie kommt.

1. Werkvertrag oder Dienstvertrag? Beim Werkvertrag nach Paragraf 631 BGB schuldet dir der Anbieter einen Erfolg, also die fertige, funktionierende Software. Beim Dienstvertrag nach Paragraf 611 BGB schuldet er nur die Tätigkeit. Er arbeitet, du zahlst, ob am Ende etwas Brauchbares rauskommt, ist rechtlich sein geringeres Problem. Individuell entwickelte Software wird üblicherweise als Werkvertrag eingeordnet. Wenn ein Anbieter auf Dienstvertrag besteht, ist das kein Skandal, aber er sollte dir erklären können, warum.
2. Wem gehört der Quellcode am Ende? Hier wird es teuer. Der Bundesgerichtshof hat 2003 im Verfahren X ZR 129/01 entschieden, dass es keinen automatischen Anspruch auf Herausgabe des Quellcodes gibt. Der Code ist nur geschuldet, wenn es vereinbart wurde oder sich klar aus den Umständen ergibt. Steht nichts im Vertrag, kannst du die Software am Ende bezahlt haben und trotzdem nicht damit weiterarbeiten.
3. Welche Nutzungsrechte bekomme ich, und darf ich sie bearbeiten? Das Urheberrechtsgesetz kennt einfache und ausschließliche Nutzungsrechte. Paragraf 31 Absatz 5 UrhG regelt außerdem: Wenn im Vertrag nicht steht, welche Rechte übergehen, bekommst du im Zweifel nur so viele, wie der Vertragszweck zwingend erfordert. Das Recht, den Code zu ändern oder von jemand anderem ändern zu lassen, gehört oft nicht dazu.
4. Wie läuft die Abnahme ab? Paragraf 640 BGB regelt sie. Absatz 2 ist der, den kaum jemand kennt: Setzt dir der Auftragnehmer eine angemessene Frist zur Abnahme und du reagierst nicht mit der Benennung mindestens eines Mangels, gilt das Werk als abgenommen. Eine E-Mail, die du im Urlaub übersiehst, kann dich also Gewährleistungsrechte kosten. Lass dir den Abnahmeprozess vor dem Start schriftlich beschreiben.
5. Bekomme ich alle zwei Wochen etwas Lauffähiges zu sehen? Das ist die wichtigste Frage der ganzen Liste. Ein Statusbericht ist Prosa. Eine Demo ist ein Beweis. Wer dir alle vierzehn Tage etwas zeigen kann, das du selbst anklicken darfst, kann dich schwer über Monate hinhalten.
6. Kriege ich Zugang zum Repository und zu einer Testumgebung? Du musst den Code nicht lesen können. Aber du musst sehen können, dass er existiert, dass regelmäßig daran gearbeitet wird und dass er dir gehört. Ein Anbieter, der dir keinen Lesezugriff auf dein eigenes Projekt gibt, hat dafür selten einen guten Grund.
7. Was passiert, wenn ihr morgen ausfallt? Frag nach Dokumentation, nach Übergabefähigkeit, nach der Zahl der Leute, die dein Projekt kennen. Wenn die Antwort auf einen einzigen Entwickler hinausläuft, hängt dein Unternehmen an einer Person.

Ein Hinweis, der hier hingehört: Wir sind Entwickler, keine Anwälte. Was hier zu Verträgen und Urheberrecht steht, ist Praxiswissen aus Projekten und ersetzt keine Rechtsberatung. Bei einem sechsstelligen Projekt lohnt sich ein IT-Anwalt für zwei Stunden Vertragsprüfung fast immer.

Warnsignale, bei denen du hellhörig werden solltest

Manche Dinge merkst du erst im Projekt. Diese hier sind zuverlässig.

• Es gibt nie etwas zu sehen. Vier Wochen, acht Wochen, zwölf Wochen, und du hast nichts angeklickt. Die Erklärungen klingen plausibel und wechseln jedes Mal.
• Jede Rückfrage wird zum Fachvortrag. Ein guter Entwickler kann dir in zwei Sätzen erklären, woran er gerade arbeitet. Wer stattdessen Vokabeln auffährt, will meistens nicht erklären, sondern beenden.
• Der Festpreis kommt ohne Konzept. Ein Anbieter, der dir nach einem Telefonat einen Festpreis nennt, hat ihn geraten. Entweder ist er zu hoch, dann zahlst du zu viel. Oder er ist zu niedrig, dann kommt die Rechnung über Nachträge. Wie sich Aufwand und Preis seriös herleiten lassen, haben wir in unserem Überblick zu den Kosten der Softwareentwicklung aufgeschlüsselt.
• Auf Kritik folgt sofort ein Angebot. Du meldest einen Fehler, und die Antwort ist ein Zusatzaufwand. Bei echten Mängeln am vereinbarten Werk greift die Gewährleistung, da zahlst du nicht nochmal.
• Der Vertrag schweigt zu Code, Rechten und Abnahme. Kein böser Wille nötig, um daraus ein Problem zu machen. Es reicht, dass ihr euch irgendwann uneinig seid.
• Du hast keinen festen Ansprechpartner. Wechselnde Namen im Ticketsystem bedeuten, dass niemand dein Projekt wirklich im Kopf hat.

Die drei Fehler, die Auftraggeber selbst machen

Ehrlich gesagt sitzt ein guter Teil des Problems nicht beim Dienstleister.

Du nimmst das billigste Angebot. Wenn vier Anbieter zwischen 40.000 € und 90.000 € liegen, ist der Günstigste selten der Effizienteste. Meistens hat er am wenigsten verstanden. Die Differenz taucht später als Nachtrag wieder auf, nur dann ohne Wettbewerb.

Du willst einen Festpreis auf Basis einer halben Seite Briefing. Festpreis ist gut, wenn der Umfang steht. Ohne sauberes Konzept ist ein Festpreis eine Wette, und der Anbieter kalkuliert seinen Puffer ein, den du mitbezahlst. Wer vorne in ein Lastenheft investiert, kauft sich damit die Grundlage für ein belastbares Angebot. Wie das konkret aussieht, steht in unserem Beitrag zu Lastenheft und Pflichtenheft.

Du benennst keinen Entscheider. Wenn Freigaben durch drei Abteilungen wandern, verlierst du Wochen, und zwar aus eigener Kraft. Der Dienstleister wird dir das nicht ankreiden, er stellt einfach die Wartezeit in Rechnung oder schiebt den Termin.

Was diese Prüffragen nicht leisten: Einen technischen Reviewer machen sie aus dir nicht. Ob eine Architektur in drei Jahren noch trägt, ob der Code sauber getestet ist, ob die Datenbank die richtige Wahl war, das siehst du auch mit der besten Checkliste nicht. Wenn du diese Sicherheit brauchst, hol dir für ein oder zwei Tage einen unabhängigen Gutachter dazu. Bei einem großen Projekt sind das die am besten investierten Kosten der ganzen Rechnung.

Was du jetzt tun kannst

Nimm die sieben Fragen mit ins nächste Gespräch und stell sie genau so. Du musst kein einziges Fachwort verstehen, um zu merken, ob jemand ausweicht. Ein guter Dienstleister freut sich über diese Fragen, weil sie zeigen, dass du das Projekt ernst nimmst. Ein schlechter wird ungeduldig. Das ist der ganze Test.

Und dann sorge dafür, dass das Projekt sichtbar bleibt: alle zwei Wochen etwas Lauffähiges, Zugang zum Repository, ein Ansprechpartner mit Namen. Wer diese drei Dinge hat, wird selten böse überrascht.

Wir arbeiten so, weil wir kein Interesse an Kunden haben, die uns nicht verstehen. Wenn du wissen willst, wie wir Software entwickeln, oder dein aktuelles Projekt einmal von außen einsortiert haben willst, buch dir eine Fokus-Session. Kein Verkaufsgespräch, sondern eine Stunde, in der wir ehrlich draufschauen. Auch wenn das Ergebnis lautet, dass dein jetziger Anbieter alles richtig macht.