Web, Mobile, KI, SaaS, Cloud und Produktarbeit

Die Phasen überlappen absichtlich. Design beginnt, sobald der erste Slice klar ist. Der Build wartet nicht auf eine perfekte Datei. Scale ist schon im Blick, während wir die erste Version ausliefern — wir überbauen sie nur nicht am ersten Tag.

1. 01

   Discover

   Wir schreiben die Aufgabe auf, bevor jemand einen Code-Editor öffnet.

   Die ersten Gespräche drehen sich um das Produkt, nicht um einen Stack. Für wen es ist, was schon da ist, was nicht kaputtgehen darf und wie „fertig“ tatsächlich aussieht. Wenn das Briefing unordentlich ist, ist das normal — wir fragen, bis es konkret genug ist, um dagegen zu bauen.

   Sie bekommen eine schriftliche Form der Arbeit: was drin ist, was draußen, ein erster Slice, Risiken und eine Arbeitsweise. Sie können sie annehmen oder lassen. Wir hören lieber hier auf, als einen Build zu starten, an den niemand glaubt.

   Was Sie mitnehmen

   • Einen kurzen schriftlichen Scope und Erfolgskriterien
   • Was drin ist, was draußen und was warten kann
   • Einen ersten Slice, den Sie ausliefern und daraus lernen können
   • Wie wir sprechen, Demos machen und entscheiden
   
2. 02

   Design

   Sie können mit dem Produkt streiten, solange Änderungen noch günstig sind.

   Wir machen aus dem Scope etwas, das Sie anklicken können: Flows, Screens und die wenigen Komponenten, die sich wiederholen. Es geht nicht um eine hübsche Datei. Es geht darum, die unbequemen Stellen zu finden — Leerzustände, Berechtigungen, den dritten Tap, an den niemand gedacht hat — bevor sie Tickets werden.

   Reicht ein statischer Prototyp nicht, spiken wir ihn im echten Stack. Sie reviewen mit den Leuten, die es nutzen, nicht nur mit denen, die es beauftragt haben. Wenn wir uns einig sind, ist diese Datei das, was wir bauen. Sie verschwindet nicht ins Leere.

   Was Sie mitnehmen

   • Klickbare Flows und die Kern-Screens
   • Ein kleines Design System, kein 200-Komponenten-Kit
   • Offene Fragen benannt, nicht in Kommentaren versteckt
   • Eine Build-Reihenfolge, die zum ersten Slice passt
   
3. 03

   Build

   Jede Woche lauffähige Software. Sie sehen sie, Sie testen sie, wir passen an.

   Die Leute im Kickoff sind die Leute, die den Code schreiben. Sie bekommen ein Repo unter Ihrer Kontrolle, eine wöchentliche Demo von etwas, das Sie anklicken können, und einen Ort für Entscheidungen. War die Woche dünn, sagen wir das. Status ohne lauffähige Software ist kein Fortschrittsbericht.

   Tests, Logging und ein Weg zum Shippen kommen unterwegs dazu — nicht als Aufräumen am Ende. Wenn etwas nicht stimmt, fangen wir es, solange es noch klein ist. Der Scope kann sich ändern; wir schreiben den Trade-off auf, damit die Rechnung nicht die Überraschung wird.

   Was Sie mitnehmen

   • Ein Repo, Umgebungen und einen Release-Pfad, die Ihnen gehören
   • Wöchentliche Demos lauffähiger Software
   • Schriftliche Entscheidungen, keine Chat-Historie, die niemand findet
   • Qualität und Monitoring im Produkt, nicht als späteres Projekt
   
4. 04

   Scale

   Der Launch ist nicht das Ende der Beziehung.

   Mit dem Go-live beginnen die echten Fragen: ein Bug in Produktion, eine Änderung im Geschäft, eine neue Person in Ihrem Team, die den Code verstehen muss. Wir härten, was schon läuft, messen, was zählt, und liefern den nächsten Slice weiter, wenn Sie uns dafür wollen.

   Sie sollten das Produkt intern übernehmen können. Architektur, Tests und Notizen bleiben bei Ihnen. Wenn Sie uns dabeihaben wollen, bleiben wir. Wenn nicht, sollten Sie sich nicht gefangen fühlen.

   Was Sie mitnehmen

   • Ein Produktionssystem, das Sie betreiben können
   • Übergabenotizen, denen Ihre Ingenieure folgen können
   • Den nächsten Slice im Scope, wenn Sie weitermachen wollen
   • Support, der antwortet, kein Ticket-Loch