Autonomie ist eine Architektur, kein Versprechen

Jeder Anbieter kann einen Absatz darüber schreiben, wie sehr er Ihre Daten respektiert. Das kostet nichts und schützt nichts. Die einzige Version dieser Aussage, die etwas wert ist, ist strukturell: das Produkt so bauen, dass der Anbieter Ihre Daten technisch gar nicht halten kann. Diese Einschränkung hat jede Entscheidung geprägt, die unten steht.

Drei Dinge, die wir früh entschieden haben

01

Eine Produktlinie, niemals ein Fork. Sobald die Installation jedes Kunden auseinanderdriftet, haben Sie eine Beratung, die so tut, als wäre sie ein Produkt – und der Kunde mit der ältesten Umgebung bekommt still keine Fixes mehr. Jedes Konto fährt dasselbe getestete Release. Unterschiedlich ist die Konfiguration: Region, Domain, Integrationen, Feature Flags. Nie der Code.

02

Managed muss auch managed heißen. Jemandem ein Repository zu übergeben und das Souveränität zu nennen, schiebt die Betriebsrechnung zum Kunden. Die Pipeline bleibt bei uns: Releases, Schema-Migrationen, Rotation von Secrets, Monitoring, Upgrades. Ihre Entwickler sollten Geschäftslogik schreiben, keine Plattform betreiben.

03

Der Ausstieg muss echt sein, sonst zählt er nicht. Ein Migrationsweg, der nur funktioniert, solange die Beziehung gut ist, ist kein Migrationsweg. Wenn wir morgen verschwinden, läuft die Infrastruktur weiter, nimmt die Datenbank weiter Schreibvorgänge an und löst Ihre Domain weiter auf – weil nichts davon je uns gehört hat.

Das Produkt aus der Nähe

Eigentum ist der Unterbau. Das hier ist der Teil, den Ihr Team jeden Morgen öffnet – identisch, in welchem Cloud-Konto er auch gerade läuft.

Ein Ort, an dem der Kontext liegt

Pipelines, Datensätze, Inhalte und Zuständigkeiten in einer Ansicht statt einer Tabelle, die gegen fünf Browser-Tabs abgeglichen wird. Führungskräfte lesen den Stand ab, ohne danach zu fragen. Mitarbeitende sehen, was als Nächstes ansteht, ohne dass es ihnen jemand sagt.

Struktur, die den Kontakt mit der Realität übersteht

Ihr Datenmodell am ersten Tag ist eine Vermutung. Tabellen, Filter und Beziehungen sind hier dafür gemacht, bearbeitet zu werden, sobald die Vermutung besser wird. Dieselben Datensätze speisen jede CRM-Ansicht, jede Aufgabe und jeden Workflow in der Anwendung – die Form einmal ändern heißt, sie überall zu ändern.

Zahlen, wo immer Sie sind

Echtes Reporting auf dem Smartphone zwischen zwei Terminen, berechnet aus denselben Definitionen, auf die sich Finanzen und Betrieb am Desktop längst geeinigt haben. Aktuelle Werte statt einer Tabelle, die jemand am Dienstag exportiert hat.

Ein Board, wenn Phasen wichtiger sind als Zeilen

Dieselben Datensätze in eine Kanban-Ansicht kippen, wenn die Frage lautet, in welcher Phase etwas steckt. Deals, Aufgaben und Inhalte in einer Pipeline. Damit endet die Diskussion darüber, wessen Export der finale war.

Verdrahtet mit dem, was Sie schon betreiben

Abrechnung, CRMs, Produktivitätstools, KI-Dienste. Daten fließen automatisch in beide Richtungen. Das entfernt die Copy-Paste-Schicht und den zähen Widerspruch zwischen zwei Systemen, die sich beide für die Quelle der Wahrheit halten.

Wie es gebaut ist

Die interessante Technik in einem Bring-your-own-Cloud-Produkt sind nicht die Funktionen. Es ist, jede Woche dasselbe Release in Dutzende Konten auszuliefern, die einem nicht gehören, ohne eines davon kaputt zu machen.

  • Zwei Backends, eine Plattform

    postgraph auf Django und PostgreSQL für relationale und analytische Arbeit. nodegraph auf Node und RethinkDB für Live-Daten und Events. Beide erfüllen denselben Vertrag, also kann ein Kunde eines von beiden oder beide betreiben, ohne dass das Frontend den Unterschied merkt.

  • Infrastruktur als Artefakt

    Der gesamte Fußabdruck – Netzwerk, Datenbank, Container, Load Balancing, CDN, Zertifikate, DNS, Secrets, Konfiguration – ist Terraform. Er steht mit einem Befehl und verschwindet mit einem. Genau das macht den Ausstieg glaubwürdig.

  • Streng geordnete Deployments

    Zuerst die Infrastruktur, dann die Backends parallel, mit Migrationen als vorgelagerter Einmal-Task, bevor ein neues Image live geht. Scheitert eine Migration, erreicht das neue Image den laufenden Dienst nie.

  • Belege statt Zusicherungen

    „Was läuft in Produktion?“ löst sich auf in eine feste Version, einen Image-Digest und eine Deployment-Historie, die Ihr Plattform-Team einem Prüfer vorlegen kann. Jede Umgebung fährt im Release-Zug mit, in dem Tempo, das Sie wählen.

Wohin das führt

Wir bauen auf eine ziemlich konkrete Wette über die nächsten Jahre hin.

KI hat die Eigentumsfrage von akademisch zu dringend gemacht. Damit ein Modell nützlich ist, muss es die echten Datensätze lesen: die Deals, die Dokumente, die Historie. Jedes Team wird gerade feststellen, dass der Preis für nützliche KI in der heutigen Architektur darin besteht, die gesamte Betriebsgeschichte an einen Dritten zu schicken. Das Modell dort laufen zu lassen, wo die Daten ohnehin liegen, ist die einzige Variante davon, die eine ernsthafte Sicherheitsprüfung übersteht.

Die Roadmap zielt deshalb darauf, Ihr Konto zum besten Ort für diese Arbeit zu machen: Modellwahl unter Ihrer Kontrolle, Retrieval, das Ihre Grenze nie verlässt, und Agenten, die über dieselben Berechtigungen und dasselbe Audit-Log auf Ihre Daten zugreifen wie ein menschlicher Nutzer. Ihre Daten, Ihre Rechenleistung, Ihre Regeln.

Das größere Ziel ist langweiliger und wichtiger. Wir wollen unaufgeregte, gut betriebene Software, die ein reguliertes Team ohne sechsmonatigen juristischen Umweg einführen kann – und wir wollen der Grund sein, warum ein Gründer Datenresidenz nicht länger für das hält, was den Abschluss blockiert.

Wenn Sie eine vollständig betriebene Plattform wollen, die Ihre Daten nie in Obhut nimmt, sprechen wir.