Ein Angebot kann detailliert sein und die wichtigste Entscheidung trotzdem verbergen. Wir sahen ein Projekt, in dem Screens und Integrationen genau beschrieben waren, aber niemand geklärt hatte, wem Source Code, Production Accounts und Deployment Keys gehören. Die Unklarheit blieb, bis Procurement fragte, weil alle früheren Gespräche nur Features betrafen.
Ein Technologiepartner sollte Unsicherheit vor der Unterschrift reduzieren, auch wenn das den Verkauf erschwert. Nützlich sind Fragen, die Grenzen sichtbar machen.
Nach den Annahmen fragen
Jedes Angebot beruht auf Annahmen zu Datenqualität, Entscheidungsgeschwindigkeit, fertigen Inhalten, Integrationszugriff, Traffic, Compliance sowie Browsern und Geräten. Diese Annahmen gehören in eine schriftliche Liste. Danach folgt die Frage, welche falsche Annahme Preis oder Zeitplan am stärksten verändert.
Die Antwort alles ist enthalten ist beunruhigend. Komplexe Arbeit hat immer Ränder. Ebenso problematisch ist ein fixes Versprechen für Systeme, die der Partner nicht untersucht hat. Selbstbewusstsein ohne Dependency Liste bedeutet häufig, dass Risiko im Preis versteckt oder in spätere Change Requests verschoben wurde.
Eine starke Antwort trennt bekannten Scope, Discovery Fragen und Ausschlüsse. Sie nennt zudem den Beleg, mit dem jede Unbekannte geschlossen wird.
Den Owner jedes operativen Assets fragen
Der Kunde muss wissen, wem Repositories, Cloud Accounts, Domains, Analytics, Modellkonten, App Store Einträge, Designquellen und Vendor Verträge gehören. Production Credentials leben in kundengesteuerter Infrastruktur oder haben einen dokumentierten Übergabeweg. Studiozugriff muss ohne Neubau des Produkts entfernbar sein.
Gefragt wird, was am Tag nach Ende der Beziehung geschieht. Kann ein anderes Team deployen, Secrets rotieren, Daten wiederherstellen und offene Incidents verstehen? Welche Dokumentation und Übergabe sind enthalten? Hängt Kontinuität von gutem Willen oder dem Laptop eines Mitarbeiters ab, besteht das Risiko bereits.
Ownership ist nicht Maintainability. Source Code kann rechtlich übertragen und ohne Environments, Runbooks und Entscheidungshistorie praktisch unbrauchbar sein.
Fragen, wie Scheitern erkannt wird
Ein Partner nennt Erfolgsmessung und Stop Bedingungen vor der Umsetzung. Für ein AI Feature gehören Eval Fälle, unzulässige Fehler und ein Plan für schwache Ergebnisse dazu. Commerce braucht operative Szenarien jenseits des Checkouts, Performancearbeit Feldmetriken und Testbedingungen.
Vorsicht bei der Antwort Feedback wird es zeigen. Feedback ist wertvoll, ersetzt aber keine Schwelle für Go, No-go oder Redesign. Defects, Scope Änderungen und Incidents müssen vertraglich getrennt sein. Wird jedes unerwartete Ergebnis neuer Scope, liegt das gesamte Delivery Risiko beim Käufer.
Genau hören, wozu es ein Nein gibt
Bei Clodron gehört Nein zur Arbeit. Wir lehnen Native Apps ab, wenn ein Webprodukt reicht. Wir lehnen AI Automation ohne Owner für Ausnahmen ab. Production Agenten mit breiten Credentials und Modellwechsel ohne Evals lehnen wir ebenfalls ab. Wir empfehlen kein Web3, wenn eine gewöhnliche Datenbank das Vertrauensmodell löst. Für eine kleine Oberfläche bauen wir kein Design System, nur damit sie reif wirkt.
Das sind keine universellen Verbote. Sie zeigen, wie ein Partner das Projekt vor eindrucksvollen, unnötigen Builds schützt. Ein Studio ohne Nein optimiert möglicherweise den anfänglichen Scope statt das laufende Produkt. Eine gute Frage lautet, welche aktuelle Empfehlung die eigene Rechnung des Partners reduziert hat.
Die Antworten diese Woche in die Vereinbarung bringen
Vor der Unterschrift entsteht ein kurzes Decision Sheet zu Annahmen, Ausschlüssen, Abnahme, Ownership, Environments, Security, Drittgebühren, Change Control, Support und Exit. Jedes wichtige Versprechen wird mit Vertrag oder Statement of Work verknüpft.
Nicht nur Sales, auch der Delivery Lead prüft es. Antworten wie normalerweise, später oder kommt darauf an werden zu benanntem Owner und Entscheidungszeitpunkt. Ebenso steht fest, was der Partner wann vom Kunden braucht.
Das Ziel ist kein Vertrag, der jedes Ereignis vorhersagt. Es ist eine Zusammenarbeit, in der schlechte Nachrichten einen Ort haben. Was ein Partner vor der Unterschrift sagt, ist nützlich. Was er schriftlich festhält, ist das stärkere Signal.