HANDWERK
TRIFFT
CLOUD

Fragen, die vor der ersten Mail kommen

Vertriebs-FAQ — Kurz beantwortet, samt der Stellen, an denen wir nicht die Richtigen sind.

• Für welche Unternehmensgröße arbeitet ihr?

  Der typische Zuschnitt ist ein Engineering-Team mit 10 bis 80 Entwicklerinnen und Entwicklern, meist in einem Unternehmen mit 50 bis 1.000 Mitarbeitenden. Groß genug, dass Plattform- und Architekturentscheidungen richtig Geld kosten, klein genug, dass eine Entscheidung noch durchkommt, ohne ein Gremium zu passieren. Die Zahlen sind eine Orientierung, keine Hürde — meldet euch auch, wenn ihr knapp daneben liegt.

  Entscheidend ist etwas anderes: Es muss ein eigenes Engineering-Team geben, das die Plattform danach betreibt. Ohne das wird aus Wissenstransfer dauerhaftes Outsourcing, und dafür sind wir die Falschen.

• Wir brauchen Umsetzung, keine Beratung. Ist das euer Modell?

  Der größte Teil der Arbeit ist Umsetzung: Cluster, Pipelines, Infrastructure as Code, Backends. Was davor liegt, ist keine Beratungsphase, sondern das Minimum, um nicht am falschen Problem zu bauen — in Tagen gemessen, nicht in Wochen. Ergebnisse liegen in euren Repositories, nicht in einem Dokument, das niemand wieder öffnet.

  Wenn Umsetzung heißt, dauerhaft Tickets abzuarbeiten und den Betrieb zu übernehmen, sind wir falsch. Wir bauen und übergeben; betrieben wird von eurem Team.

• Wir haben bereits ein Plattform-Team. Was bringt ihr dann noch?

  Wir ersetzen euer Plattform-Team nicht und übernehmen es nicht. Wir kommen für eine abgegrenzte Frage: eine Architekturentscheidung, bei der das Team gespalten ist, ein Cluster-Upgrade, das seit Quartalen verschoben wird, ein Golden Path, den im Alltag niemand benutzt. Gearbeitet wird mit dem Team — Pairing, Reviews, Entscheidungen schriftlich im Repository — nicht daran vorbei. Ohne ein Team, das das Wissen aufnimmt, wäre die Übergabe am Ende wertlos.

  Wenn euer Team die Antwort kennt und nur keine Stunden frei hat, braucht ihr Kapazität. Die verkaufen wir nicht: Wir stellen niemanden für eine offene Rolle ab. Dafür sind Freelancer oder eine Personalvermittlung der ehrlichere Weg.

• Wir brauchen eigentlich nur eine zusätzliche Entwicklerin oder einen Entwickler. Passt das?

  Eine zusätzliche Person löst ein Mengenproblem. Wir kommen, wenn der Engpass an einer Entscheidung oder an fehlender Erfahrung hängt — Kubernetes in Produktion, eine Migration, die zweimal gescheitert ist, eine Pipeline, die niemand mehr anfassen will. Solche Engpässe verschwinden nicht durch mehr Hände, sondern durch eine Entscheidung, die jemand schon einmal getroffen hat. Danach macht euer Team weiter, ohne dass wir bleiben.

  Für eine dauerhaft besetzte Rolle — Regelbetrieb, Rufbereitschaft, laufende Tickets — sind eine Festanstellung oder Freelancer günstiger und passender. Wir sind keine Personalvermittlung und übernehmen keinen Betrieb.

• Was passiert, wenn die eine Person ausfällt?

  Wir reden das Risiko nicht klein: Es gibt keine Bank, die einspringt. Deshalb entsteht alles bei euch — Code in euren Repositories, Infrastruktur als Code, Entscheidungen als schriftliche Architekturentscheidung im Projekt statt als Foliensatz auf unserem Rechner. Gearbeitet wird in abgegrenzten Blöcken mit einem eigenen Ergebnis am Ende jedes Blocks, nicht in einem Programm über viele Monate. Ein Abbruch lässt euch damit mit einem nutzbaren Zwischenstand zurück, nicht mit einer Baustelle.

  Vertraglich zugesicherte Verfügbarkeit — Vertretungsregelung, Reaktionszeiten, Rufbereitschaft — können wir nicht zusagen. Wer das braucht, braucht einen Dienstleister mit Team und Service-Level-Vereinbarung.

• Wir wissen den endgültigen Umfang noch nicht. Wie fangt ihr trotzdem an?

  Ein Festpreis für einen ungeprüften Bestand ist geraten, nicht kalkuliert — deshalb machen wir das nicht. Der erste Block ist klein und hat ein eigenes Ergebnis: Ist-Aufnahme, priorisierte Engpässe, ein Umsetzungsplan mit Aufwandsschätzung. Danach entscheidet ihr, ob es weitergeht — mit uns, mit eigenen Leuten oder gar nicht. Der Plan gehört euch in jedem Fall.

  Wenn euer Einkauf einen Festpreis für die gesamte Transformation vor jeder Analyse verlangt, passt das nicht zusammen. Wir nennen keine Zahl für etwas, das wir nicht gesehen haben.

• Wir brauchen sofort jemanden. Wie schnell könnt ihr anfangen?

  Ein erstes Gespräch geht kurzfristig. Ein Projektstart hängt an der laufenden Auslastung — und wir sagen, ab wann Kapazität frei ist, statt euch hinzuhalten. Wenn es akut ist, bekommt ihr schnell eine Zusage oder eine Absage, damit ihr parallel weitersuchen könnt. Eine Reaktionszeit sagen wir nicht zu, weil wir sie nicht garantieren können.

  Für einen Notfall im laufenden Betrieb sind wir der falsche Anruf: keine Rufbereitschaft, keine garantierten Reaktionszeiten, keine Vertretung. Wer heute jemanden im System braucht, ist bei einem Dienstleister mit Bereitschaft besser aufgehoben.

• Wir können keinen Produktionszugang geben. Geht das trotzdem?

  Analyse, Architektur und Arbeit an Infrastructure as Code laufen ohne Produktionszugang: Repositories, Konfiguration, Metriken, Kostenreports und Gespräche mit dem Team ergeben ein belastbares Bild. Wo ein Eingriff in Produktion nötig wäre, arbeiten wir über euer Team — geteilter Bildschirm, ihr führt aus, wir sitzen daneben. Vertraulichkeitsvereinbarung und Auftragsverarbeitungsvertrag klären wir vorher, nicht nebenbei.

  Ohne Produktionszugang und ohne Zugang zu Menschen, die ihn haben, lässt sich eine Ursache nicht finden. Für einen akuten Ausfall reicht das nicht — dann bleibt nur eine Einschätzung auf Basis dessen, was ihr zeigen könnt.

• Wir brauchen Unterstützung vor Ort. Ist das möglich?

  Wir arbeiten remote-first. Vor-Ort-Termine in Nordrhein-Westfalen sind unkompliziert, im übrigen DACH-Raum als geplante Blöcke: Workshops, Architektur-Sessions, Kickoffs, Übergaben — die Termine, bei denen Anwesenheit tatsächlich etwas ändert. Der Rest läuft remote, weil tägliche Anreise Zeit verbrennt, die im Projekt fehlt.

  Dauerhafte Anwesenheit an allen Wochentagen oder ein fester Arbeitsplatz bei euch ist nicht möglich, außerhalb von Nordrhein-Westfalen erst recht nicht. Wenn euer Modell das verlangt, passt es nicht — daran ändert auch ein guter Projektzuschnitt nichts.