Software-Consultancy vs. Software-Agentur: Welches Modell passt zu deinem Vorhaben?
"Wir suchen eine Agentur." "Kannst du eine gute Consultancy empfehlen?" In Vertriebsgesprächen beschreiben beide Sätze meist dieselbe Anfrage, und die meisten Käufer kämen ins Schwimmen, wenn man sie nach dem Unterschied fragte. Das ist ein Problem, denn Software-Consultancy vs. Agentur ist keine Frage des Namensgeschmacks. Die beiden Wörter beschreiben unterschiedliche Engagement-Modelle, mit unterschiedlichen Verträgen, unterschiedlicher Preisgestaltung und unterschiedlichen Antworten auf die Frage, wem deine Technikentscheidungen gehören. Wähl das falsche Modell, und der Mismatch zeigt sich typischerweise nach drei oder vier Monaten, wenn die Anzahlung längst bezahlt ist.
Dieser Beitrag erklärt beide Modelle in klarer Sprache, vergleicht sie an den Punkten, die in der Praxis zählen, und gibt dir einen Weg an die Hand, zu entscheiden, welches zu deiner Situation passt.
Was eine Software-Agentur verkauft
Eine Agentur nimmt ein Briefing und macht daraus ein fertiges Produkt. Du beschreibst, was du willst, etwa eine Marketing-Website, ein MVP oder ein Bündel Features. Die Agentur schätzt den Aufwand, nennt Preis und Termin und liefert das Ergebnis. Sobald du die Lieferung abnimmst, ist das Engagement vorbei. Willst du mehr, schreibst du ein neues Briefing und startest ein neues Projekt.
Das Modell hat echte Stärken. Der Preis steht fest, bevor die Arbeit beginnt. Der Scope ist schriftlich fixiert. Die Verantwortung ist klar: Passt die Lieferung nicht zum Briefing, ist das das Problem der Agentur. Für ein sauber definiertes Projekt mit stabilen Anforderungen ist das genau das Richtige, und es gibt keinen Grund, für mehr zu bezahlen.
Die Schwäche des Modells ist dieselbe wie seine Stärke: Das Briefing ist eine Mauer. Alles, was die Agentur über dein Produkt, deine Nutzer und deine Codebasis lernt, bleibt auf ihrer Seite der Mauer. Endet das Projekt, geht dieses Wissen mit zur Tür hinaus. Und weil der Preis gegen das Briefing fixiert wurde, ist jede Änderung, die du nach der Unterschrift anfragst, eine Verhandlung, kein Gespräch.
Was eine Software-Consultancy verkauft
Eine Consultancy bettet sich in deine Organisation ein. Statt Arbeit mitzunehmen und mit einem Ergebnis zurückzukommen, arbeiten Consultants Seite an Seite mit deinem Team: Sie beraten, sie bauen, und sie geben dabei Wissen weiter. Der Scope steht am Anfang nicht fest, denn genau darum geht es: Er entwickelt sich. Was du in Monat zwei lernst, ändert, was du in Monat vier tun solltest, und das Engagement ist so strukturiert, dass es das zulässt.
Auch der Output eines Consultancy-Engagements ist ein anderer. Ja, Code wird ausgeliefert. Aber der dauerhaftere Output ist, dass dein Team am Ende fähiger ist als am Anfang: Deine Entwickler verstehen die Architektur, weil sie sie mitentschieden haben, deine Prozesse haben sich verbessert, weil jemand mit Erfahrung in ihnen gearbeitet hat, und die Begründung hinter jeder größeren Entscheidung ist dort dokumentiert, wo dein Team sie findet.
Dieses Modell kostet pro Monat mehr als ein vergleichbares Agenturprojekt, und es verlangt dir mehr ab. Eine Consultancy kann sich nicht in ein Team einbetten, das sich keine Zeit dafür nimmt. Wenn auf deiner Seite niemand an den Architekturdiskussionen teilnimmt, bezahlst du Consultancy-Sätze für Agenturarbeit.
Software-Consultancy vs. Agentur: die praktischen Unterschiede
Die Tabelle fasst zusammen, wie sich die beiden Modelle an den Punkten unterscheiden, die Käufer während eines Engagements tatsächlich spüren.
| Dimension | Software-Agentur | Software-Consultancy |
|---|---|---|
| Scope | Fixiert gegen ein Briefing | Entwickelt sich mit dem Engagement |
| Beziehung | Transaktional, endet mit der Lieferung | Laufend, oft über mehrere Jahre |
| Primärer Output | Eine fertige Lieferung | Ein fähigeres Team plus funktionierende Software |
| Wissen | Bleibt bei der Agentur | Wird gezielt an dein Team übertragen |
| Typische Preisgestaltung | Festpreis pro Projekt | Time-and-Materials-Retainer |
| Technikentscheidungen | Fallen innerhalb der Agentur | Fallen gemeinsam mit dir und werden erklärt |
| Change Requests | Nachverhandlung | Teil des normalen Rhythmus |
Keine dieser Zeilen macht ein Modell besser als das andere. Sie machen jedes Modell besser für eine bestimmte Situation, weshalb der Abschnitt zur Preisgestaltung wichtiger ist, als die meisten Käufer erwarten.
Die Preismodelle dahinter, und was sie dir verraten
Der Festpreis ist das natürliche Zuhause von Agenturarbeit. Er funktioniert nur, wenn der Scope wirklich stabil ist, denn die Agentur preist für jede Unklarheit in deinem Briefing einen Risikopuffer ein. Ein vages Briefing zum Festpreis ist entweder teuer (der Puffer ist groß) oder ein Streit mit Ansage (der Puffer war zu klein, und die Agentur verteidigt jetzt jede Zeile der Spezifikation).
Time and Materials, meist als monatlicher Retainer strukturiert, ist das natürliche Zuhause von Consultancy-Arbeit. Du bezahlst für Kapazität und Richtung statt für eine Lieferung. Das klingt riskanter für den Käufer, und das ist es auch, außer die Consultancy macht transparent, was sie mit der Zeit anfängt. Frag jede Consultancy, wie du Fortschritt sehen wirst. Ist die Antwort ein monatliches Foliendeck statt Commits, Demos und Decision Records, such weiter.
Outcome-basierte Preise, bei denen das Honorar an ein messbares Ergebnis geknüpft ist, gibt es in beiden Welten, aber seltener, als die Verkaufsseiten suggerieren. Sie funktionieren, wenn das Ergebnis wirklich messbar ist und überwiegend in der Hand des Partners liegt. Seitenladezeit, der Abschluss einer Migration oder die Testabdeckung eines definierten Moduls können das erfüllen. Umsatzziele meist nicht, denn zu viel des Ergebnisses hängt an Entscheidungen, die der Partner nicht trifft.
Das Preismodell, auf das ein Partner am stärksten drängt, verrät dir, wie er das Engagement sieht. Eine Firma, die für ein unscharfes, sich entwickelndes Problem auf einem Festpreis besteht, sagt dir damit, dass sie den Scope kontrollieren will, statt ihn mit dir zu erkunden.
Wem die Technikentscheidungen gehören
Das ist der Unterschied, den Käufer am stärksten unterschätzen, und wir behandeln ihn ausführlicher in unserem Leitfaden dazu, worauf du bei einem Custom-Software-Partner achten solltest.
Im Agenturmodell fallen Technikentscheidungen innerhalb der Agentur. Welches Framework, welche Datenbank, wie das Deployment funktioniert: Das sind Mittel zum Zweck, und der Zweck ist die Lieferung, die du spezifiziert hast. Das ist legitim. Aber es bedeutet, dass dir das Ergebnis gehört, ohne dass dir die Begründung gehört. Zwei Jahre später, wenn die Agentur weg ist und sich etwas ändern muss, erbt dein Team eine Architektur, die niemand im Haus erklären kann. Ein großer Teil der Codebasen, die wir in der Legacy-Code-Optimierung sehen, hat genau so angefangen.
Im Consultancy-Modell werden Entscheidungen gemeinsam mit dir getroffen und festgehalten. Eine gute Consultancy wird für ihre Empfehlung argumentieren, manchmal hartnäckig, aber die Entscheidung gehört deiner Organisation, und die Begründung bleibt da, wenn die Consultants gehen. Hast du gar kein internes Team, zählt dieser Unterschied heute weniger, und an dem Tag, an dem du deinen ersten Entwickler einstellst, umso mehr.
Warnzeichen, dass eine Agentur wie eine Fabrik arbeitet
Manche Agenturen leisten ausgezeichnete Arbeit. Andere arbeiten wie Fabriken, und die Zeichen sind schon vor der Unterschrift sichtbar. Die Leute, die dich im Vertriebsprozess beeindruckt haben, verschwinden nach dem Vertrag, ersetzt durch eine wechselnde Besetzung aus Junioren. Niemand stellt Fragen zu deinem Geschäft, denn das Briefing gilt als vollständig, sobald es nicht mehr verhandelbar ist. Zugriff auf das Repository bekommst du erst zur Endabnahme, wenn überhaupt. Change Requests kommen so schnell mit einem Preisschild zurück, dass du zu ahnen beginnst, dass sie das eigentliche Geschäftsmodell sind. Und wenn du fragst, warum eine technische Entscheidung so getroffen wurde, lautet die Antwort "das ist unser Standard-Stack" statt einer Erklärung, die an deiner Situation hängt.
Eines dieser Zeichen allein kann eine harmlose Erklärung haben. Mehrere zusammen bedeuten, dass die Lieferung auf die Marge der Agentur optimiert wird, nicht auf dein Produkt.
Wann welches Modell die richtige Wahl ist
Wähle eine Agentur, wenn das Projekt sauber definiert ist, die Anforderungen stabil sind und du das Wissen danach nicht brauchst. Eine Kampagnen-Site, eine klar spezifizierte Integration, ein Prototyp, der weggeworfen werden soll: fester Scope, fester Preis, saubere Übergabe. Gut gemacht, ist das für alle Beteiligten effizient.
Wähle eine Consultancy, wenn die Arbeit verändern soll, wie deine Organisation Software baut, über das Abarbeiten einer Feature-Liste hinaus. Internes Engineering aufbauen, Architekturschulden abtragen, ein mehrjähriges Custom-Software-Vorhaben steuern oder Stack-Entscheidungen treffen, mit denen dein Team ein Jahrzehnt leben wird: Das braucht einen Partner, der engagiert bleibt, während sich das Bild ändert. Dasselbe gilt, wenn du bereits Entwickler hast und willst, dass sie durch das Engagement wachsen, statt von außen zuzusehen. Unsere Engagements zu Tech-Stack-Strategie und Code Quality Consulting sind auf genau dieser Annahme aufgebaut.
Ein nützlicher Test: Stell dir vor, das Engagement endet morgen. Läge alles Wertvolle in der Lieferung, passt eine Agentur. Sollte ein guter Teil des Werts in den Köpfen und Gewohnheiten deines Teams liegen, willst du eine Consultancy.
Wie Wolf-Tech Engagements strukturiert
Wolf-Tech ist eine Consultancy, ganz bewusst. Wir arbeiten in deinem Repository, nicht in einer Kopie davon. Entscheidungen fallen in Diskussionen, an denen dein Team teilnimmt, und werden dort festgehalten, wo dein Team sie später wiederfindet. Wenn ein Engagement endet, ist das Ziel, dass du uns weniger brauchst als am Anfang. Das klingt nach einem seltsamen Geschäftsmodell, bis du bemerkst, dass Organisationen, die diesen Punkt erreichen, mit größeren Fragen zurückkommen.
Wenn du die beiden Modelle für ein konkretes Projekt abwägst und eine zweite Meinung dazu willst, welches passt, schreib an hello@wolf-tech.io oder sieh dich auf wolf-tech.io um. Deine Situation in drei Sätzen zu beschreiben reicht für den Anfang.
FAQ
Ist eine Software-Consultancy teurer als eine Agentur?
Pro Monat meistens ja. Über die Lebensdauer eines Systems oft nein. Agenturprojekte tragen Folgekosten, die im Vergleich selten auftauchen: Change Requests, das erneute Briefen neuer Partner und der Wiederaufbau von Wissen, das mit der Agentur gegangen ist.
Kann ein Unternehmen beides sein, Consultancy und Agentur?
Ja, und viele sind es. Entscheidend ist, welches Modell für dein Engagement gilt. Frag, wie Scope-Änderungen gehandhabt werden und wer an Architekturentscheidungen teilnimmt. Die Antworten ordnen das Engagement der einen oder der anderen Seite zu, egal wie sich das Unternehmen nennt.
Wir haben keine internen Entwickler. Ergibt das Consultancy-Modell trotzdem Sinn?
Es kann, wenn du planst, ein Team aufzubauen, denn die Consultancy kann dir beim Einstellen helfen und neue Leute in eine Codebasis einarbeiten, die sie kennt. Wenn du nie Entwickler beschäftigen willst, ist eine Agenturbeziehung mit einem soliden Wartungsvertrag oft die praktischere Wahl.