Wie man eine Softwareentwicklungsfirma in Deutschland auswählt: Die Fragen, die echte Qualität zeigen
Alle paar Wochen schreibt mir jemand nach einer schlechten Erfahrung mit einer Softwareentwicklungsfirma in Deutschland. Das Muster ist immer ähnlich. Die Verkaufsgespräche liefen glatt, das Angebot sah professionell aus, der Preis lag im mittleren Marktsegment, und neun Monate später haben sie eine Codebasis, die niemand anfassen will, und einen Dienstleister, der jede Änderungsanfrage in Rechnung stellt.
Der deutsche Markt hat viele Agenturen. Die Qualitätsunterschiede zwischen ihnen sind enorm, und der Preis verrät dir fast nichts darüber, mit wem du es zu tun hast. Ein Stundensatz von 140 Euro kann dir einen Senior-Entwickler in Leipzig einbringen oder einen Junior in einem Berliner Coworking-Space, dessen Rechnung den Namen eines Seniors trägt.
Dieser Beitrag ist der Bewertungsprozess, den ich als Käufer nutzen würde. Ich wende dieselben Prüfungen in die andere Richtung an, wenn ich entscheide, ob ein Kunde zu Wolf-Tech passt, also ist nichts davon Theorie.
Beim Portfolio anfangen, es aber anders lesen
Die meisten Käufer überfliegen ein Portfolio nach wiedererkennbaren Logos und einer Technologieliste. Beides ist fast wertlos. Awards und "Top-10-Agentur"-Badges sind meist Pay-to-play, und eine Wand voller Framework-Logos zeigt dir, was das Marketingteam für beeindruckend hält, nicht was die Entwickler tatsächlich ausgeliefert haben.
Was du in einer Case Study stattdessen lesen solltest:
Ist sie aktuell? Ein Portfolio, dessen neuester Eintrag aus 2022 stammt, bedeutet entweder, dass die Firma seither nichts Interessantes gemacht hat, oder dass sie keine Erlaubnis bekommt, darüber zu sprechen. Beides ist eine Nachfrage wert.
Nennt sie den Kunden? NDAs sind real, und manche Kunden können nicht genannt werden. Aber eine Agentur, bei der jede einzelne Case Study sich hinter "ein führendes Logistikunternehmen" versteckt, hat entweder keinen Kunden, der für sie bürgt, oder gar keinen echten Kunden. Ein oder zwei namentlich genannte Referenzen mit einem Kontakt, den du tatsächlich anschreiben kannst, sind mehr wert als zwanzig anonyme.
Können sie die Ausgangssituation beschreiben? Eine gute Case Study erklärt, was das Problem des Kunden vor dem Projekt war. "Wir haben eine Plattform für X gebaut" ist ein Satz, den jeder schreiben kann. "Der Kunde hatte einen PHP-7.2-Monolithen mit 40-minütigen Deployments und einem Bestellprozess, der unter Last Transaktionen verlor" ist ein Satz, den nur schreiben kann, wer dabei war.
Nennt sie technische Details oder nur Ergebnisse? "Conversion um 30 Prozent gesteigert" ist ein Marketing-Ergebnis. "Checkout auf eine asynchrone Queue umgestellt und die p95-Latenz von 4,1 Sekunden auf 600 Millisekunden gesenkt" ist Engineering. Du willst einen Dienstleister, der in der zweiten Sprache denkt, denn das ist die Sprache, in der deine künftigen Incidents geschrieben werden.
Die Interviewfragen, die Seniorität von Selbstbewusstsein trennen
Jede Agentur wird eine Senior-Person ins Verkaufsgespräch schicken. Deine Aufgabe ist herauszufinden, ob diese Person auch an deinem Projekt arbeiten wird, und ob die Leute, die tatsächlich daran arbeiten, wirklich Senior sind.
Bitte darum, mit dem Entwickler zu sprechen, der die Arbeit leiten würde, nicht mit dem Account Manager. Wenn sie das ablehnen, ist das die Antwort.
Stell dann Fragen, bei denen eine generische Antwort ein Ausschlusskriterium ist. Ein paar, die gut funktionieren:
Wie handhabt ihr Datenbank-Migrationen in Produktion? Ein Senior-Entwickler wird über rückwärtskompatible Schemaänderungen sprechen, über Expand-and-Contract-Muster, darüber, Migrationen getrennt von Deployments laufen zu lassen, und was bei einem Rollback passiert. Ein Junior sagt "wir nutzen Doctrine Migrations" und hört auf. Wenn du das Detailniveau sehen willst, das eine Senior-Antwort enthalten sollte, ist mein Playbook für Zero-Downtime-Migrationen ungefähr das, was ich erwarten würde zu hören.
Wie verwaltet ihr Secrets? Achte auf einen Secrets-Manager oder zumindest Environment-Injection zur Deploy-Zeit, Rotation und eine klare Aussage, dass Secrets nie im Repository landen. Wenn die Antwort eine .env-Datei beinhaltet, die "in ein privates Repo" committet wird, geh weg.
Was passiert, wenn eine von euch ausgelieferte Abhängigkeit eine Sicherheitslücke bekommt? Diese Frage zeigt, ob es einen operativen Prozess gibt oder nur eine Build-Pipeline. Gute Antworten erwähnen automatisiertes Dependency-Scanning, eine definierte Reaktionszeit und wer bei der Agentur nach Projektübergabe verantwortlich ist. Vage Antworten ("wir halten die Dinge aktuell") bedeuten, dass niemand es besitzt.
Wie entscheidet ihr, was einen Test bekommt? Nicht "schreibt ihr Tests", das bejaht jeder. Die gute Antwort erklärt, wo Tests sich auszahlen (Domänenlogik, Geld, Berechtigungen, Integrationen) und wo nicht. Wer 100 Prozent Coverage auf jedem Projekt behauptet, lügt entweder oder verschwendet dein Budget.
Zeig mir ein Pull-Request-Review aus einem aktuellen Projekt. Anonymisiert ist in Ordnung. Wonach du suchst, ist, ob Reviews Substanz haben (Sicherheit, Datenintegrität, Kopplung) oder nur Formatierungs-Nitpicks und "LGTM". Ich habe aufgeschrieben, was ein gutes Senior-Code-Review tatsächlich findet, falls du einen Vergleichsmaßstab willst.
Ausweichende oder generische Antworten auf eine dieser Fragen sind ein Ausschlussgrund. Ein Senior-Entwickler genießt diese Fragen; sie sind der interessante Teil des Jobs.
Vertrags-Warnsignale, die deutsche Agenturen routinemäßig verstecken
Der Vertrag ist der Ort, an dem gute und mittelmäßige Agenturen an der Oberfläche am ähnlichsten aussehen, also lies ihn richtig. Idealerweise mit einem Anwalt, aber zumindest selbst, und gezielt auf diese Punkte.
IP-Eigentum. Nach deutschem Urheberrecht behält der Entwickler die Urheberschaft, und du erhältst Nutzungsrechte. Das ist normal. Entscheidend ist, ob diese Rechte exklusiv, uneingeschränkt, übertragbar sind und alle Nutzungsformen abdecken, und ob sie mit Zahlung jeder Rechnung übergehen oder erst nach der letzten. Manche Agenturen platzieren eine Klausel tief in den AGB, die Rechte bis zur "vollständigen Begleichung aller Forderungen" bei ihnen belässt, was ihnen bei einem späteren Streit Hebelwirkung verschafft. Bitte darum, die IP-Klausel in den Hauptvertrag zu ziehen, wo du sie lesen kannst.
Kein Source-Code-Escrow oder Repository-Zugriff. Du solltest von Tag eins an Admin-Zugriff auf das Repository haben, möglichst in deiner eigenen GitHub- oder GitLab-Organisation. Wenn die Agentur darauf besteht, den Code in ihrem eigenen Account zu hosten und "am Ende zu übergeben", hast du keinen Schutz, falls die Beziehung schiefgeht oder die Firma schließt. Escrow ist die formale Version davon; für die meisten mittelgroßen Projekte reicht es, das Repository selbst zu besitzen.
Undefinierter Änderungsprozess. Ein Festpreisvertrag ohne definierte Prozedur für Änderungen ist ein Festpreisvertrag, der nicht fest bleibt. Du musst wissen, wer Änderungen genehmigt, wie sie geschätzt werden, wie hoch der Stundensatz für Arbeit außerhalb des Scopes ist, und wie Streitigkeiten darüber gelöst werden, ob etwas "im Scope" ist. Schweigt der Vertrag dazu, entscheidet die Agentur, und sie entscheidet zu ihren eigenen Gunsten.
Staffing-Klauseln. Achte darauf, ob der Vertrag die Personen oder zumindest die Seniorität-Level nennt, die zugewiesen werden, und ob die Agentur sie ohne deine Zustimmung austauschen kann. Der Bait-and-Switch vom Senior im Pitch zum Junior im Projekt ist die mit Abstand häufigste Beschwerde, die ich höre.
Gewährleistung und Mängelbehandlung. Ein Werkvertrag gibt dir Mängelrechte; Agenturen bevorzugen oft einen Dienstvertrag, bei dem sie Aufwand statt Ergebnis schulden. Keines von beidem ist falsch, aber wisse, welches du unterschreibst.
Eine Discovery-Phase einem Festpreis für ein unspezifiziertes Produkt vorziehen
Ein Festpreis für ein Produkt, das nicht im Detail spezifiziert ist, ist ein als Zusage verkleideter Ratewert. Die Agentur weiß das. Sie schützt sich entweder, indem sie den Preis stark aufschlägt, oder indem sie niedrig kalkuliert und die Marge später über Änderungsanfragen wieder hereinholt. Im ersten Fall zahlst du zu viel. Im zweiten Fall bekommst du den Neun-Monate-Albtraum vom Anfang dieses Beitrags.
Die Alternative ist eine bezahlte Discovery-Phase: zwei bis vier Wochen, in denen die Agentur mit dir eine echte Spezifikation, einen Architekturvorschlag, ein priorisiertes Backlog und eine realistische Schätzung mit ausgesprochenen Annahmen erarbeitet. Du bezahlst für diese Arbeit. Am Ende besitzt du das Ergebnis und kannst es zu jedem Dienstleister mitnehmen, auch zu einem anderen.
Agenturen, die von ihrer Qualität überzeugt sind, mögen dieses Modell meist, weil es ihnen erlaubt, ihre Arbeit zu zeigen, bevor sich jemand auf eine große Summe festlegt. Agenturen, die sich dagegen wehren und direkt auf einen unterschriebenen Festpreis drängen, sind meiner Erfahrung nach diejenigen, deren Schätzungen du am wenigsten vertrauen solltest. Wie das Engagement nach der Discovery aussehen sollte, habe ich in wie man einen Sprint mit einem externen Entwicklungspartner durchführt beschrieben.
Wenn du noch zwischen einer größeren Agentur und einer kleineren Beratung schwankst, deckt der Vergleich Beratung versus Agentur die Abwägungen ab.
Was man frühere Kunden fragen sollte
Referenzen werden zufriedene Kunden sein, denn so funktionieren Referenzen. Trotzdem bekommst du echte Informationen aus ihnen heraus, mit Fragen, auf die sie nicht vorbereitet wurden.
Frag, was schiefgelaufen ist. Jedes Projekt hat etwas. Eine Referenz, die "nichts" sagt, ist entweder nicht ehrlich oder war nicht nah genug an der Arbeit dran, um es zu wissen. Eine Referenz, die sagt "die erste Schätzung lag um etwa 30 Prozent daneben, aber sie haben es früh gesagt und wir haben umpriorisiert", erzählt dir etwas Nützliches darüber, wie die Agentur unter Druck reagiert.
Frag, wer die Arbeit tatsächlich gemacht hat und ob diese Leute noch bei der Agentur sind. Die Fluktuation bei Agenturen ist hoch. Die Entwickler, die das Referenzprojekt gebaut haben, sind vielleicht schon vor zwei Jahren gegangen.
Frag, was nach der Übergabe passiert ist. Blieb die Agentur erreichbar? Hat der Kunde Probleme im Code gefunden, nachdem das eigene Team übernommen hat? Hat ein anderer Dienstleister den Code später begutachtet, und was hat er gesagt? Hier liegen die ehrlichsten Antworten.
Frag, ob sie sie für ein anderes Projekt wieder beauftragen würden. Die Formulierung ist wichtig. "Würdest du sie empfehlen" bekommt ein reflexhaftes Ja. "Würdest du sie für ein Greenfield-SaaS-Projekt beauftragen, wenn das Referenzprojekt eine Website war" zwingt die Referenz, über die tatsächliche Bandbreite der Agentur nachzudenken.
Wie Wolf-Tech die Passung von der anderen Seite bewertet
Zur Einordnung: Das sind die Fragen, die ich mir stelle, bevor ich einen Kunden annehme, denn eine schlechte Passung kostet beide Seiten.
Hat der Kunde einen technischen Entscheider, mit dem ich direkt sprechen kann, oder läuft alles über einen Projektmanager, der nicht bewerten kann, was ich sage? Projekte ohne technisches Gegenüber driften.
Ist der Scope genau genug spezifiziert, um zu schätzen, oder fragen sie nach einem Festpreis für eine Idee? Im letzteren Fall schlage ich zuerst Discovery vor, und wenn sie ablehnen, lehne ich meist ab.
Sind sie bereit, mir Repository- und Infrastrukturzugriff unter ihren eigenen Accounts zu geben? Kunden, die wollen, dass ich in einer Blackbox arbeite und am Ende einen Zip-Ordner übergebe, verlangen genau das Setup, vor dem ich oben gewarnt habe.
Hatten sie einen früheren Dienstleister, und können sie erklären, was schiefgelaufen ist, ohne alles dem Dienstleister anzulasten? Ein Kunde, der bei drei Dienstleister-Beziehungen nie selbst schuld war, wird mit einem vierten dieselbe Erfahrung machen.
Brauchen sie einen individuellen Software-Build, ein Review von bestehendem Code, oder Hilfe bei der Modernisierung eines Legacy-Systems? Das sind unterschiedliche Engagements, und ein Kunde, der sich nicht sicher ist, welches er braucht, profitiert meist von einem kurzen Audit vorab.
Eine kurze Checkliste für das erste Gespräch
Bevor du mit einer Softwareentwicklungsfirma in Deutschland etwas unterschreibst, solltest du jede dieser Fragen mit Ja beantworten können: Du hast mit dem Entwickler gesprochen, der die Arbeit leiten wird, du hast eine aktuelle Case Study gesehen, die den Kunden nennt und den technischen Ausgangspunkt beschreibt, du weißt, wie sie Migrationen, Secrets und verwundbare Abhängigkeiten handhaben, du hast die IP- und Änderungsklauseln selbst gelesen, du wirst das Repository ab dem ersten Commit besitzen, und du hast mindestens eine Referenz gefragt, was schiefgelaufen ist.
Wenn eine davon ein Nein ist, weißt du noch nicht genug, um zu unterschreiben.
Wenn du eine zweite Meinung zu einem Angebot willst, das du bekommen hast, oder eine unabhängige Begutachtung einer Codebasis, die ein früherer Dienstleister hinterlassen hat, schreib an hello@wolf-tech.io oder schau dir an, was ich unter wolf-tech.io mache. Ich sage dir gerne, ob ein Angebot angemessen aussieht, auch wenn die Arbeit an jemand anderen geht.