Umsetzung · 30 Tage
Dreißig Tage. Ein System.
Ein Use Case, klar abgegrenzt, lauffähig auf Ihren Daten. Der Code gehört Ihnen, die Architektur ist dokumentiert, und Ihr Team betreibt das System ohne mich weiter.
- 30 Tagebis zum produktiven System
- 1 Use Caseeiner, dafür richtig
- Angebot vorabverbindlich, nach Scoping
- Ihr Codegehört vollständig Ihnen
Passt das?
Ein Use Case. Richtig gebaut.
Ein sauber gebauter Use Case schlägt fünf halbfertige. Der Build konzentriert sich auf einen, bringt ihn produktiv und übergibt ihn so, dass er ohne mich weiterläuft.
Die meisten KI-Projekte enden als Demo. Sie sehen im Termin gut aus, laufen auf aufgeräumten Beispieldaten und scheitern, sobald die echten Daten kommen. Der Build dreht das um: Ihre Daten zuerst, der Showcase später.
Am Ende steht ein System, das in Ihren Abläufen funktioniert. Der Code liegt bei Ihnen, die Architektur ist dokumentiert, und die Governance hält einer Prüfung stand.
Passt, wenn
- der Use Case steht, aus einem Sprint oder weil er bei Ihnen klar ist.
- Sie ein produktives System wollen, keinen Prototyp für die Schublade.
- Code und Wissen am Ende bei Ihnen liegen sollen.
- Sie im regulierten Umfeld arbeiten und Datenschutz von Anfang an mitlaufen muss.
Eher nicht, wenn
- noch unklar ist, welcher Use Case sich lohnt. Dann erst der Sprint.
- Sie zehn Dinge gleichzeitig automatisieren wollen.
- Sie ein Team zum Mitprogrammieren suchen statt ein fertiges System.
Ablauf
Dreißig Tage, vom Zugang zur Übergabe.
Früh lauffähig, dann gehärtet. Sie sehen nach wenigen Tagen einen ersten Durchstich, statt vier Wochen auf ein großes Reveal zu warten.
-
Tag 1–5 · Lösen
Setup und Datenanbindung
Zugänge, eine sichere Umgebung in der EU, Anbindung an Ihre Datenquellen. Unspektakulär, aber das Fundament für alles, was DSGVO und AI Act später prüfen.
-
Tag 6–12
Durchstich, die erste lauffähige Version
Der schmale Pfad von Anfang bis Ende steht: rein, verarbeiten, raus. Noch roh, aber echt. Ab hier reden wir über ein laufendes System statt über Folien.
-
Tag 13–22
Iteration auf Ihren echten Daten
Qualität und die Randfälle, die in der Theorie niemand bedacht hat. Hier entscheidet sich, ob ein System im Alltag benutzbar ist oder nur in der Demo.
-
Tag 23–28 · Liefern
Härtung, Integration, Governance
Einbindung in Ihre Systeme, Monitoring und die Dokumentation, die eine Prüfung übersteht: Betriebskonzept, Architekturentscheidungen, Datenflüsse. Alles aufgeschrieben, nicht in meinem Kopf.
-
Tag 29–30 · Übergabe
Code, Doku, Einweisung
Ihr Team bekommt Quellcode, Dokumentation und eine Einweisung. Danach betreiben Sie das System selbst. Auf Wunsch begleite ich den Betrieb, als Option und nicht als Abhängigkeit.
Ergebnis
Was Sie behalten.
Nicht eine Rechnung und ein Login zu meinem System. Vier Dinge, die nach der Übergabe Ihnen gehören.
-
1
Das lauffähige System
Produktiv auf Ihren Daten, in der EU gehostet. Ein System, das Ihre Leute morgen benutzen können.
-
2
Der Quellcode
Vollständig bei Ihnen. Kein Lizenzmodell, kein Lock-in. Sie könnten morgen jemand anderen damit weiterarbeiten lassen.
-
3
Dokumentierte Architektur
Diagramme, Betriebskonzept, die Entscheidungen und das Warum dahinter. Damit Ihr Team versteht, was es betreibt.
-
4
Übergabe und Governance
Einweisung für Ihr Team plus die Governance-Dokumentation für DSGVO und AI Act.
Abgrenzung
Klar, was Sie bekommen.
Der Build ist Umsetzung, kein Dauerzustand. Und er setzt eine durchgerechnete Grundlage voraus, sonst bauen wir ins Blaue.
Der Build ist
- ein produktiv lauffähiger Use Case auf Ihren Daten.
- Code und Architektur, die Ihnen gehören.
- ein System, das Ihr Team ohne mich weiterbetreibt.
- Governance-Doku, die einer Prüfung standhält.
Der Build ist nicht
- eine Bastel-Demo oder ein Prototyp ohne Betrieb.
- eine Plattform für zehn Use Cases auf einmal.
- ein Dauer-Retainer.
- eine Blackbox, die nur mit mir läuft.
Was ich von Ihnen brauche
- einen klar abgegrenzten Use Case, aus einem Sprint oder bei Ihnen definiert.
- Zugang zu den relevanten Daten und Systemen.
- einen fachlichen Ansprechpartner, der Fragen beantwortet.
Angebot
Eine Zahl, nicht ein Tagessatz.
Sie bekommen die Zahl, bevor wir starten, und keine Rechnung, die mit jeder Stunde wächst. Der Preis hängt an Datenlage und Integrationstiefe. Ich lege ihn im Sprint oder in einem kurzen Scoping fest und halte ihn schriftlich fest.
Kommen Sie aus dem Sprint, rechne ich ihn voll an.
Fragen
Bevor Sie fragen.
Wovon hängt der Preis ab?
Von Datenlage und Integrationstiefe, nicht von Tagessätzen. Das verbindliche Angebot steht nach dem Sprint oder einem kurzen Scoping, bevor wir anfangen.
Kann ich den Build ohne Sprint buchen?
Ja, wenn der Use Case klar abgegrenzt ist und ich Zugang zu den Daten bekomme. Fehlt diese Grundlage, machen wir vorab ein kurzes Scoping oder den Sprint. Ohne klaren Use Case zu bauen heißt, ins Blaue zu bauen. Das mache ich nicht.
Gehört uns der Code wirklich?
Ja, vollständig. Kein Lizenzmodell, kein Lock-in, keine Abhängigkeit von mir. Ich baue bewusst so, dass Ihr Team das System ohne mich weiterbetreibt. Das ist der Punkt, kein Nebeneffekt.
Was passiert nach den 30 Tagen?
Sie betreiben das System. Auf Wunsch begleite ich den Betrieb, als Option und nicht als Pflicht. Der Normalfall ist Übergabe, Einweisung, fertig.
Wie steht es um Datenschutz und AI Act?
EU-Hosting, DSGVO-konform, mit einer Governance-Doku, die einer Prüfung standhält. PSD2, XS2A, EU AI Act und DSGVO sind mein täglicher Arbeitskontext im Open Banking, kein Zusatzpaket.
Die Grundlage
Noch kein klarer Use Case? Der Sprint findet ihn.
Der Build setzt auf eine durchgerechnete Grundlage. Die liefert der Sprint in zehn Tagen, samt Angebot für genau diesen Build.
Erstgespräch
Use Case im Kopf?
Erzählen Sie mir davon. Im Erstgespräch sage ich Ihnen ehrlich, ob er in 30 Tagen produktiv steht oder ob vorher etwas fehlt.