Ein System, das für die Arbeitsweise Ihrer Organisation gebaut ist, nicht für den allgemeinen Fall.

Weil wir ihn nicht ehrlich schreiben könnten. Der Aufwand eines maßgeschneiderten Systems ergibt sich aus drei Dingen, die wir vor dem Hinsehen nicht wissen: wie viele externe Systeme erreicht werden müssen und ob eines davon eine API hat, wie viele Geschäftsregeln bereits irgendwo geschrieben sind und wie viele von Menschen ermittelt werden müssen, und wer das System nach der Lieferung am Laufen hält. Eine Zahl vor der Sichtung des Systems ist ein Kostenvoranschlag mit Wahrsagerei. Was wir schnell machen können, ist die erste Etappe — lesen, abgrenzen, die Regeln schreiben —, die korrekt geschätzt wird und nützlich bleibt, auch wenn Sie dort aufhören.

Der speziell für Sie geschriebene Code gehört Ihnen, einschließlich Repository und Historie. Drittbibliotheken bleiben unter ihren jeweiligen Lizenzen — wir können sie Ihnen nicht übertragen, weil sie uns nicht gehören. Unsere wiederverwendbaren Komponenten und unsere bestehenden Produkte werden zur Nutzung lizenziert, nicht übertragen; wenn sich Ihre Arbeit auf eines davon stützt, sagen wir Ihnen das im schriftlichen Angebot vor dem Start, nicht in der letzten Besprechung.

Die Übergabe muss das ohne uns möglich machen, sonst war es keine Übergabe. Deshalb wird das Inbetriebnahmedokument für eine leere Maschine geschrieben und setzt nichts aus unserem Kopf voraus, und die Tests bleiben im Repository, damit das nächste Team weiß, was kaputtgeht, wenn es etwas ändert. Was wir nicht versprechen können, ist, dass ein komplexes System ohne Aufwand übernommen wird — wir können nur versprechen, dass ihm nichts fehlt, was für die Übernahme nötig ist.

Teilweise, und es ist richtig zu sagen, wo das endet. Für Kunden gebaute Systeme gehören nicht uns, damit wir sie vorzeigen können, und interne Systeme enthalten reale Geschäftsdaten. Was wir vor Ihnen auf dem Bildschirm machen können, ist etwas anderes: Wir öffnen das Repository, zeigen Ihnen die in Textform geschriebenen Regeln des Fachgebiets, führen die Testsuiten aus — 38 in einer halben Sekunde auf einem, 81 in etwas mehr als einer Sekunde auf einem anderen, 44 auf dem dritten — und lesen gemeinsam den Code, der die Aussage trägt, die Sie in Zweifel ziehen. Diese Seite ist ihrerseits ein eigenes System, das von außen inspiziert werden kann.

Normalerweise ja, aber mit offengelegtem Risiko. Die Reihenfolge ist: Zuerst fragen wir, ob der Anbieter eine offizielle API hat, die er einfach nur nicht öffentlich dokumentiert hat — das passiert oft. Wenn nicht, kann über programmatische Authentifizierung gearbeitet werden, genau wie ein Benutzer, mit automatisch erneuerter Sitzung; so haben wir ein System gebaut, das zwei B2B-Portale abfragt. Dann schreiben wir Ihnen klar, dass es sich im Verhältnis zu den Nutzungsbedingungen des Anbieters um eine Grauzone handelt und dass bei großem Volumen die nachhaltige Lösung darin besteht, die offizielle API anzufordern. Die Entscheidung bleibt bei Ihnen, aber informiert.

Ja, und das verbergen wir nicht. Entscheidend sind die Regeln, unter denen es geschieht: Jedes Arbeitspaket wird mit laufenden Tests, Typprüfung und einer Differenzprüfung vor dem Commit abgeschlossen, und die Grenzen sind im Repository festgehalten — keine Veröffentlichungen in die Produktion aus der Arbeit heraus, keine Änderungen in externen Konten, Adapter für Anbieter nur mit Simulationsvariante. Schnell geschriebener und unbewiesener Code ist teurer als langsam geschriebener. Wofür das steht, ist Geschwindigkeit auf der langweiligen Seite, nicht das Fehlen von Prüfung.

Wir sagen es. In einem eigenen Engineering-Projekt kamen wir nach der Bewertung zu einer zweiten, völlig anderen Architektur für dasselbe Problem und haben sie als dokumentierte Alternative geschrieben, mit den Gates, die vor jeder Bestellung zu passieren sind, statt auf der ersten zu bleiben, nur weil sie bereits begonnen war. Die Kosten einer Richtungsänderung in der Mitte sind geringer als die eines in der falschen Form gelieferten Systems, und die Differenz zahlt in beiden Fällen der Auftraggeber.

An einem Ende ein System mit drei Anwendungen und zwölf gemeinsamen Paketen in einem einzigen Repository, 486 TypeScript-Dateien, 68 Testdateien und 151 Commits, mit relationaler Datenbank, separater flüchtiger Koordination von der Quelle der Wahrheit und gemeinsamen Verträgen zwischen Anwendungen. Am anderen Ende ein System mit einem einzigen Prozess und zwanzig Einstiegspunkten, genau so viel wie nötig. Umfang ist kein Versprechen über jede Größe — es ist die Feststellung, dass wir an beiden Enden gearbeitet haben.

Ja, aber als separate Vereinbarung, nicht als unausgesprochene Annahme. Ein maßgeschneidertes System braucht Sicherheitsaktualisierungen, die Verfolgung von Änderungen bei externen Anbietern und jemanden, der in die Protokolle schaut. Wenn Sie das lieber mit Ihrem Team machen, ist die Übergabe so aufgebaut, dass es möglich ist. Wenn Sie es lieber von uns machen lassen, wird festgelegt, was es abdeckt und was nicht — einschließlich dessen, was „dringend“ bedeutet, denn ohne Definition bedeutet dieses Wort nichts.