IT-Beratungspartner auswählen: Was Sie fragen sollten, was Sie vermeiden sollten und wie gute Arbeit wirklich aussieht

Die Wahl des falschen Technologiepartners ist einer der kostspieligsten Fehler, den ein Unternehmen machen kann. Nicht wegen des hohen Stundensatzes, sondern weil die Kosten eines gescheiterten Projekts — verlorene Zeit, versunkene Investitionen und technische Schulden, die Jahre brauchen, um sie abzubauen — die Kosten überwiegen, es beim ersten Mal richtig zu machen.

Dieser Leitfaden ist von der anderen Seite dieses Gesprächs geschrieben. Wir waren der Partner, der kaputte Systeme geerbt hat, die von der falschen Firma gebaut wurden, und wir waren der Partner, der es beim ersten Mal richtig gemacht hat. Die Muster sind konsistent. Hier ist, was wirklich zählt, wenn man einen Technologiepartner auswählt.

Die Richtige Frage Lautet Nicht "Wer Ist am Günstigsten?"

Die meisten Unternehmen gehen die Auswahl von Technologiepartnern so an, als würden sie eine Ware kaufen. Sie holen drei Angebote ein, vergleichen die Zahlen und wählen das mittlere. Das ist eine zuverlässige Methode, um mittelmäßige Ergebnisse zu erzielen.

Die richtige Frage lautet: Wem vertraue ich, dieses spezifische Problem zu lösen, und haben sie die Beweise, die das belegen?

Beweise sind echte Projekte mit ähnlichem Umfang und ähnlicher Komplexität. Das sind Kundenreferenzen, die tatsächlich ans Telefon gehen und Ihnen sagen, wie es war, mit der Firma zu arbeiten. Das sind Portfolios, die technische Entscheidungsfindung zeigen, nicht nur schöne Screenshots.

Die günstigste Firma ist günstig aus einem Grund. Oft liegt der Grund darin, dass sie allem zustimmen, genau das bauen, was Sie spezifizieren, und es Ihnen übergeben, wenn es nicht so funktioniert, wie Sie es erwartet haben, weil Sie nicht wussten, was Sie spezifizieren sollten.

Was Technische Tiefe Wirklich Bedeutet

Technologieprojekte scheitern am häufigsten an den Grenzen — wo ein System auf ein anderes trifft, wo Sicherheit auf Benutzerfreundlichkeit trifft, wo Leistung auf Kosten trifft. Das sind die Stellen, wo ein enger Spezialist das Problem an Sie zurückgibt.

Ein lohnender Technologiepartner deckt den gesamten Stack ab: Anwendungsdesign, Infrastruktur, Sicherheit, Performance, Daten und Integration. Nicht weil jedes Projekt all das benötigt, sondern weil ein Partner, der all das versteht, in jeder einzelnen Schicht bessere Entscheidungen treffen wird.

Fragen Sie jede Firma, die Sie bewerten: Wer übernimmt die Sicherheit? Wenn die Antwort "wir bringen dafür einen Spezialisten hinzu" lautet, haben Sie eine Firma, die Sicherheit als nachträglichen Gedanken behandelt. Fragen Sie: Wer übernimmt die Infrastruktur? Wenn die Antwort "wir bauen die App und übergeben sie Ihrem Team zum Deployment" lautet, haben Sie eine Firma, die Ihnen ein Deployment-Problem hinterlässt.

Die besten Partner haben diese Übergaben nicht, weil sie sie nicht brauchen.

Wie Man ein Portfolio Liest

Ein Portfolio zeigt Ihnen, was eine Firma gebaut hat. Was Sie wirklich wissen müssen, ist, wie sie bauen und was passiert, wenn etwas schiefgeht.

Suchen Sie nach:

• Vielfalt der Problemtypen. Nicht nur Web-Apps, oder nur KI-Tools, oder nur E-Commerce. Eine Firma, die verschiedene Problemtypen gelöst hat, hat ein Mustererkennen angesammelt, das engen Spezialisten fehlt.
• Quantifizierte Ergebnisse. "Wir haben eine Website für ein Gesundheitsunternehmen gebaut" sagt nichts. "Wir haben die Ladezeit um 60% reduziert, was die Patientenrezeptionen um 23% erhöhte" zeigt, dass sie messen, was wichtig ist.
• Projekte, die den Scope geändert haben. Jedes echte Projekt begegnet unerwarteter Komplexität. Wie eine Firma mit Scope-Änderungen umgeht — transparent oder ausweichend — zeigt, wie es ist, unter Druck mit ihnen zu arbeiten.

Was ein Portfolio fast nie zeigt: wie die Kundenbeziehung wirklich war. Deshalb sind Referenzen wichtiger als Portfolios.

Der Referenzanruf Ist der Wichtigste Schritt

Die meisten Unternehmen fordern Referenzen an und rufen dann nicht an, oder sie rufen an und stellen Fragen, die nutzlose Antworten produzieren ("Waren sie professionell?" "Ja." "Würden Sie sie empfehlen?" "Ja.").

Die Fragen, die nützliche Antworten produzieren:

"Was ist schiefgegangen, und wie haben sie es gehandhabt?" Jedes Projekt hat Probleme. Eine Referenz, die sagt, nichts ist schiefgegangen, lügt entweder oder beschreibt ein trivial einfaches Projekt. Was Sie hören wollen: "Es gab ein Problem mit X, sie haben es uns sofort mitgeteilt, hier ist, was sie dagegen getan haben."

"Haben sie Ihre Entscheidungen hinterfragt? Geben Sie mir ein Beispiel." Eine Firma, die allem zustimmt, wird das Falsche bauen, wenn Sie sie in die falsche Richtung zeigen. Sie wollen einen Partner, der Ihnen sagt, wenn Sie falsch liegen.

"Wer hat wirklich an Ihrem Projekt gearbeitet? Waren es dieselben Leute, die präsentiert haben?" Der klassische Köder-und-Tausch: Senior-Partner verkaufen das Projekt, Junior-Mitarbeiter liefern es. Finden Sie heraus, ob das Team, dem Sie begegnet sind, das Team ist, das Sie bekommen.

"Was würden Sie anders machen, wenn Sie sie nochmals beauftragen?" Die Antwort darauf ist das Wertvollste, was Sie hören werden.

Discovery: Die Phase, die Alles Vorhersagt

Der einzelne größte Prädiktor für Projekterfolg ist die Qualität der Discovery-Phase — die Arbeit, die vor dem Schreiben von Code geleistet wird, um zu verstehen, was Sie wirklich brauchen, warum Sie es brauchen und wie es richtig gebaut wird.

Eine Firma, die sofort mit dem Bauen beginnen will, wird das Falsche schnell bauen. Eine Firma, die Zeit damit verbringt, Ihr Unternehmen, Ihre Nutzer, Ihre bestehenden Systeme und Ihre Einschränkungen zu verstehen, bevor sie eine Lösung vorschlägt, wird das Richtige bauen.

Wie gutes Discovery aussieht:

• Interviews mit den Personen, die das System tatsächlich nutzen werden, nicht nur mit der Person, die es beauftragt
• Architekturdesign vor dem Implementierungsdesign
• Schriftliche Dokumentation dessen, was gebaut wird, was nicht gebaut wird und was passiert, wenn Randfälle auftreten
• Explizite Definition von "fertig": nicht "wir bauen ein Dashboard", sondern "wir bauen ein Dashboard, das die Metriken X, Y, Z anzeigt, in unter 2 Sekunden lädt und keine manuelle Dateneingabe erfordert"

Wenn eine Firma Discovery überspringt oder es als Formalität behandelt, wird das Projekt zeitlich, budgetmäßig oder beides überschreiten.

Sicherheit Ist Keine Funktion — Sie Ist Das Fundament

Im Jahr 2026 sind Datenverletzungen und regulatorische Sanktionen keine hypothetischen Risiken. DSGVO-Bußgelder können 4% des globalen Jahresumsatzes erreichen. Ein unsicheres System ist eine Haftung, die Ihr Unternehmen jahrelang verfolgt.

Fragen Sie jede Firma, die Sie bewerten: "Wie passt Sicherheit in Ihren Prozess?" Die Antwort zeigt sofort, ob sie Sicherheit als Fundament oder als Feature behandeln.

Wie Gutes aussieht:

• OWASP-Best-Practices als Standard befolgt, nicht optional
• DSGVO und Datenschutz von der Architekturphase an berücksichtigt, nicht am Ende hinzugefügt
• Authentifizierung, Autorisierung und Datenverschlüsselung von Tag eins an eingebaut
• Regelmäßige Abhängigkeitsaudits und Update-Prozesse
• Klare Datenhandhabungsdokumentation — welche Daten wo gespeichert werden und wer Zugang hat

Wie Schlechtes aussieht: "Wir machen ein Sicherheitsreview vor dem Launch." Am Ende überprüfte Sicherheit ist Sicherheit, die scheitert. Die Entscheidungen, die bestimmen, ob ein System sicher ist, werden in der ersten Architekturwoche getroffen, nicht in der letzten Testwoche.

Engagement-Modelle: Die Richtige Struktur Wählen

Wie Sie das Engagement strukturieren, ist fast so wichtig wie wen Sie wählen. Die drei Hauptmodelle haben klare Anwendungsfälle.

Projektbasiert. Fester Scope, fester Zeitplan, fester Preis. Funktioniert am besten für klar definierte Probleme mit stabilen Anforderungen — eine neue Website, eine spezifische Integration, eine definierte Automatisierung. Erfordert exzellentes Discovery im Voraus. Risiken: Scope-Creep wenn Anforderungen nicht gesperrt sind, und reduzierte Flexibilität wenn sich das Problem entwickelt.

Retainer. Monatliche Zuweisung von Stunden oder Kapazität. Funktioniert am besten für laufende Entwicklung, Produktiteration und kontinuierliche Verbesserung, bei der sich Prioritäten regelmäßig verschieben. Erfordert Vertrauen und konsistente Kommunikation. Risiken: kann ohne klare Quartalsziele fokuslos werden.

Teamerweiterung. Die Ingenieure des Partners arbeiten als eingebettete Mitglieder Ihres Teams. Funktioniert am besten für Organisationen mit starker interner Produktausrichtung, die zusätzliche technische Kapazität benötigen. Risiken: erfordert internen Management-Overhead.

Die meisten Beziehungen beginnen mit einem Projektengagement und entwickeln sich mit zunehmendem Vertrauen zu einem Retainer. Die schlechteste Struktur ist ein großes, offenendiges Projekt ohne definierte Deliverables und ohne Ausstiegsklauseln.

Das Preisgespräch

IT-Beratung hat eine große Preisvariation, weil sie ein enormes Spektrum an Fähigkeitsstufen abdeckt. Ein Freelance-Entwickler, der ein Shopify-Theme baut, und ein Senior-Team, das eine Healthcare-Datenplattform entwickelt, sind beide "IT-Beratung", aber sie sind nicht vergleichbar.

Nützliche Preisreferenzen für Deutschland:

• Unabhängiger Berater, Senior-Level: 500–1.000 € pro Tag
• Agentur, Senior-Ingenieure: 700–1.500 € pro Tag
• Fokussierter Projektbuild (ein Workflow, eine Integration): 4.000–15.000 €
• Mittelkomplexe Plattform (Auth, Datenbank, Integrationen, UI): 15.000–60.000 €
• Enterprise-Plattform: 60.000–250.000 €+
• Monatlicher Retainer, laufende Entwicklung: 2.500–8.000 €

Die Fragen, die mehr zählen als der Satz:

• Wie handhaben Sie Scope-Änderungen? (Stündlich? Feste Change-Orders?)
• Was ist inklusive versus abrechnungsfähig? (Support, Bug-Fixes, Dokumentation?)
• Wer absorbiert Kostenüberschreitungen, wenn die Schätzung falsch war?

Ein Partner, der Ihnen einen Festpreis gibt und dann für jede kleine Änderung Geld berechnet, ist teurer als einer, dessen Tagessatz höher aussieht. Halten Sie die kommerziellen Bedingungen vor dem Start schriftlich fest.

Warnsignale, vor Denen Man Sich Fernhalten Sollte

Dies sind die Muster, die zuverlässig ein schlechtes Ergebnis vorhersagen:

Sie stimmen allem zu. Ein Partner, der keine Meinungen zu Ihrem Ansatz hat, hat nicht genug Erfahrung, um zu widersprechen. Sie bekommen, was Sie gefragt haben, nicht was Sie brauchten.

Vage Angebote. "Wir bauen eine Plattform, die Ihre Systeme integriert" ist kein Angebot. Ein Angebot spezifiziert, was gebaut wird, was nicht gebaut wird, wie es getestet wird und wie "fertig" aussieht.

Junior-Team hinter Senior-Präsentatoren verborgen. Fragen Sie explizit: "Wer wird täglich an diesem Projekt arbeiten?" Wenn der Senior-Partner keine spezifischen Personen nennen kann, werden die Personen, denen Sie begegnet sind, nicht die Personen sein, die Sie bekommen.

Keine Erwähnung von Sicherheit oder Compliance. Wenn DSGVO, Datenhandhabung oder Sicherheit im ersten Gespräch nicht aufkommen, sind sie nicht in den Prozess der Firma eingebaut.

Lock-in-Verträge ohne Ausstieg. Eine Firma, die sicher in ihrer Arbeit ist, muss Sie nicht 18 Monate lang binden. Bestehen Sie von Anfang an auf klaren Ausstiegsklauseln und Datenportabilitätsbestimmungen.

Können technische Entscheidungen nicht klar erklären. Wenn eine Firma nicht in einer für Sie verständlichen Sprache erklären kann, warum sie eine bestimmte Architektur gewählt hat, wissen sie entweder nicht warum oder respektieren Sie nicht genug, um es zu erklären. Beides ist nicht akzeptabel.

Wie Gutes Wirklich Aussieht

Nach 20 Jahren Technologieentwicklung sind die Merkmale der besten Arbeitsbeziehungen konsistent:

Sie teilen schlechte Neuigkeiten früh mit. Wenn etwas schiefgeht — und etwas geht immer schief — sagt ein guter Partner es Ihnen sofort, erklärt was passiert ist und präsentiert einen Plan, es zu beheben. Ein schlechter Partner verbirgt Probleme, bis sie zu Krisen werden.

Sie behandeln Ihr Budget als ihre Einschränkung. Ein guter Partner optimiert für das Ergebnis, das Sie brauchen, mit dem Budget, das Sie haben. Ein schlechter Partner baut nach seinem bevorzugten Scope und sagt Ihnen, das Budget war nicht ausreichend.

Ihre Schätzung liegt nahe am Ergebnis. Nicht identisch — echte Projekte begegnen unerwarteter Komplexität. Aber ein Partner, der konsequent beim Doppelten seiner Schätzung landet, hat ein Schätzungs- oder Kommunikationsproblem, und beides wird Ihnen Geld kosten.

Sie kümmern sich darum, was nach dem Launch passiert. Der echte Test eines Technologiepartners ist, was sechs Monate nach dem Go-live passiert — wenn der Traffic steigt, wenn der Randfall auftritt, wenn sich die Geschäftsanforderung ändert. Ein guter Partner ist noch da. Ein Anbieter ist weitergezogen.

Wie Man Es Richtig Macht

Wenn Sie eine Technologiesuche starten, ist der Prozess unkompliziert:

1. Definieren Sie das Problem präzise, bevor Sie mit jemandem sprechen. Nicht "wir brauchen eine bessere Website", sondern "wir brauchen eine Website, die 15% mehr eingehende Anfragen in Discovery-Calls konvertiert, unter 2 Sekunden Ladezeit auf Mobilgeräten hat und mit unserem CRM integriert ist."

2. Sprechen Sie mit mindestens drei Firmen. Nicht um drei Angebote zu bekommen, sondern um drei verschiedene Ansätze zu Ihrem Problem zu verstehen. Die Firma, die vor dem Vorschlag die meisten Fragen stellt, ist normalerweise die beste Firma.

3. Rufen Sie die Referenzen an. Rufen Sie sie wirklich an. Stellen Sie die oben aufgelisteten schwierigen Fragen.

4. Führen Sie zuerst einen Discovery-Sprint durch. Bevor Sie sich auf ein vollständiges Projekt festlegen, beauftragen Sie eine Discovery-Phase. Eine bezahlte Discovery-Phase (typischerweise 1.500–4.000 €) sagt Ihnen genau, was Sie bekommen, zwingt die Firma, Ihr Problem richtig zu verstehen, und gibt Ihnen eine Grundlage für ein Festpreisangebot, das wirklich genau ist.

5. Halten Sie die kommerziellen Bedingungen schriftlich fest. Scope, Zeitplan, Zahlungsmeilensteine, was passiert wenn sich der Scope ändert, wem das geistige Eigentum gehört und wie Sie die Beziehung verlassen, wenn sie nicht funktioniert.

Wir haben Technologie für Unternehmen im Einzelhandel, Gesundheitswesen, Immobilien, Migration und professionellen Dienstleistungen seit 2004 gebaut. Die Projekte, die gut laufen, sehen gleich aus: klare Problemdefinition, gründliches Discovery, regelmäßige Kommunikation und ein Partner, der Ihnen die Wahrheit sagt. Die, die nicht gut laufen, sehen auch gleich aus. Wählen Sie entsprechend.

---

Weiterführende Lektüre:

• KI-Agenten für Unternehmen: der komplette Leitfaden
• Unternehmensautomatisierung: der komplette Leitfaden
• 5 Geschäftsprozesse, die jedes KMU automatisieren sollte
• Warum Ihr Unternehmen KI-bereit sein muss