Wem gehört der Code? Über Eigentum und das Recht zu gehen

Lock-in entsteht selten aus böser Absicht. Er entsteht, wenn niemand früh genug fragt, wem am Ende was gehört. Dann liegt der Code auf einem Server, zu dem nur das Studio Zugriff hat. Die Domain läuft über deren Konto. Und das Wissen, wie das Ganze funktioniert, steckt in einem Kopf, den du nicht angestellt hast. Das passiert schleichend, und es lässt sich genauso schleichend verhindern.

Drei Dinge, die dir gehören müssen

"Eigentum" ist bei Software kein einzelnes Ding, sondern drei. Wer sie auseinanderhält, sieht sofort, wo ein Lock-in lauert.

Erstens der Code: die Logik deiner Software, alles, was wir für dich schreiben. Zweitens die Zugänge: Domains, Server und Datenbanken, die Konten, auf denen dein Produkt läuft. Drittens das Wissen: wie man das Ding startet, deployt und im Notfall repariert. Fehlt dir auch nur eins davon, gehört dir das Produkt nur auf dem Papier.

Der Code: deiner, ab Zeile eins

Bei uns liegt der Code von Tag eins in deinem Repository, unter deinem Konto. Nicht auf unserem Rechner, von dem du am Schluss ein Zip bekommst. Wir arbeiten darin als eingeladene Mitwirkende, nicht als Besitzer. Gehen wir, entziehst du uns den Zugang und es bricht nichts.

Genauso wichtig ist, womit gebaut wird. Wir nehmen bewusst einen langweiligen, verbreiteten Tech-Stack. Keine exotische Eigenkonstruktion, die nur wir verstehen. Der Reiz, etwas Cleveres zu bauen, das dich an uns bindet, ist real. Wir geben ihm nicht nach. Dein Vorteil ist, dass jede halbwegs erfahrene Entwicklerin die Sache übernehmen kann.

Ein Lock-in entsteht selten böswillig. Er entsteht, wenn niemand die Frage stellt, wem am Ende was gehört.

"Aber versteht den KI-Code überhaupt noch jemand?"

Diese Sorge kommt neu dazu, seit wir mit Agentic Coding bauen, und sie ist berechtigt. Eine Maschine, die in Minuten tausende Zeilen ausspuckt, kann eine Blackbox hinterlassen, die niemand mehr durchschaut. Auch wir nicht.

Darf sie aber nicht. Unsere Regel ist simpel: Code geht erst in Produktion, wenn ein Mensch ihn gelesen hat und ein fremdes Team ihn übernehmen könnte. Lesbar, getestet, dokumentiert, mit ruhigen Mustern statt cleveren Tricks. Das ist genau die Stelle, an der unsere Guardrails greifen. Der Übergabe-Test ist dabei kein Schlussakt, sondern die ganze Zeit unser Massstab: Könnte das hier jemand anders weiterführen, ohne uns anzurufen?

Der Übergabe-Test

Gute Software erkennt man daran, dass ein fremdes Team sie weiterbauen könnte, ohne dich zurück zu uns zu zwingen. Genau daran messen wir, was die Maschine liefert: Liest es sich? Ist es getestet? Versteht es jemand in einem Jahr noch? Wenn nicht, ist es nicht fertig.

Zugänge und Schlüssel: du bist Eigentümer, wir sind Gäste

Der sauberste Code nützt dir nichts, wenn der Schlüssel zur Haustür bei uns liegt. Darum laufen Domain, Cloud-Konto, Datenbank und Deployment auf deinen Konten, nicht auf unseren. Wir bekommen Zugriff als Mitarbeitende, befristet auf die Zusammenarbeit.

Der Unterschied wird am Tag der Trennung sichtbar. Im einen Fall klickst du uns aus der Zugriffsliste, und alles läuft weiter. Im anderen hängt dein ganzes Produkt an einem Konto, das jemand anderem gehört, und du verhandelst plötzlich nicht mehr über das nächste Feature, sondern über deine eigene Software.

Das Wissen: damit du nicht an einem Anruf hängst

Bleibt das Unsichtbarste, und oft das, was wirklich bindet: das Wissen, wie der Laden läuft. Steckt das nur in unseren Köpfen, gehört dir der Code, aber nicht die Kontrolle.

Deshalb schreiben wir es auf. Wie man das Projekt lokal startet, wie ein Release rausgeht, warum eine Entscheidung so und nicht anders gefallen ist. Keine dicke Bürokratie, sondern die Handvoll Dokumente, die ein neues Team in Tagen statt Wochen produktiv machen. Dokumentation ist hier kein Selbstzweck. Sie ist deine Unabhängigkeit, schriftlich.

Warum wir das freiwillig machen

Ehrlich gesagt wäre es kurzfristig bequemer, dich ein bisschen abhängig zu halten. Genau das ist der Grund, es nicht zu tun. Eine Partnerschaft, die einen Lock-in braucht, um zu überleben, ist eine schlechte Partnerschaft.

Wir wollen, dass du bleibst, weil die Zusammenarbeit funktioniert, nicht weil du nicht weg kannst. Das Recht zu gehen ist das, was Bleiben zu einer Entscheidung macht und nicht zu einer Falle. Und es schärft unsere eigene Arbeit: Wer jederzeit ersetzbar bleiben will, baut von selbst sauberer.

Software, die dir gehört. Auch an dem Tag, an dem wir nicht mehr im Boot sind. Erzähl uns von deinem Projekt.