Skip to content

Blog

Was eine App betriebsreif macht

„Die App läuft“ heißt noch nicht, dass ein Team sich auf sie verlassen kann. Acht Kriterien, an denen wir Betriebsreife festmachen.

„Die App läuft.“ Diesen Satz hört man oft, kurz nachdem jemand mit einem KI-Tool etwas gebaut hat. Und er stimmt ja. Man klickt, es passiert etwas, die Daten erscheinen. Nur heißt „läuft“ auf dem eigenen Bildschirm etwas anderes als „läuft im Betrieb“.

Betriebsreif ist eine App, wenn sich ein Team auch dann auf sie verlassen kann, wenn die Person, die sie gebaut hat, gerade im Urlaub ist. Wenn sich etwas ändert. Wenn jemand das Unternehmen verlässt. Wenn jemand fragt, wer wann was geändert hat.

Wir haben aufgeschrieben, woran wir das festmachen. Die Liste gilt unabhängig davon, womit eine App gebaut wurde.

1. Sie kennt die Menschen im Unternehmen

Eine betriebsreife App hat keine eigene Benutzerverwaltung mit eigenen Passwörtern. Die Menschen melden sich mit den Konten an, die sie ohnehin haben. Wer das Unternehmen verlässt und aus dem Workspace entfernt wird, verliert auch den Zugang zur App, ohne dass jemand daran denken muss.

In Openbase.one meldet man sich mit Google Workspace, Microsoft Entra ID, einem E-Mail-Code oder einem Passwort an. Admins können Passwörter für den ganzen Workspace abschalten.

2. Rechte gelten bei jedem Zugriff

Ein ausgeblendeter Button ist kein Rechtekonzept. Wenn eine Führungskraft keine Gehälter sehen soll, dürfen die Gehälter gar nicht erst bei ihr ankommen, egal auf welchem Weg sie fragt.

Deshalb schreiben Apps in Openbase.one kein SQL. Jeder Datenzugriff läuft über das SDK und ein Gateway, das jeden Aufruf gegen Workspace, App und Rechte prüft. Workspaces sind auf Datenbankebene voneinander getrennt.

3. Jede Version wird geprüft, nicht nur die erste

Die erste Version einer App wird meist sorgfältig angesehen. Die fünfte Änderung nicht mehr. Genau dort passieren die unangenehmen Fehler: Eine kleine Anpassung an einer Liste macht nebenbei eine Spalte sichtbar, die verborgen sein sollte.

In Openbase.one werden bei jeder Version Datenmodell und Zugriffsregeln geprüft und Datensätze klassifiziert: intern, personenbezogen, sensibel, steuerlich. Dann wird jede Seite im echten Browser als jede Testperson geöffnet. „Als Führungskraft: kein Gehalt sichtbar.“ „Als HR: alle Gehälter sichtbar.“ Live geht eine Version erst, wenn die Prüfung bestanden ist. Scheitert der Build oder die Prüfung, bleibt die bisherige Version live.

4. Sie läuft abgeschottet

Eine App, die mit Firmendaten arbeitet, sollte nicht beliebig ins Internet funken können. Nicht, weil jeder Code böse ist, sondern weil sich bei generiertem Code niemand jede Zeile ansieht.

App-Code in Openbase.one läuft in einer isolierten Laufzeit ohne Netzwerkzugang. Er erreicht weder das Internet noch andere Workspaces. Was eine App mit Daten tun darf, entscheidet nicht ihr Code, sondern die Prüfung jedes einzelnen Aufrufs.

5. Es gibt einen Weg zurück

Fehler passieren. Entscheidend ist, wie schnell man sie wieder los ist. Eine betriebsreife App hat Versionen, und die vorherige ist schnell wieder live, ohne dass jemand abends etwas rekonstruieren muss.

In Openbase.one bleibt jede Version erhalten. Die vorherige Live-Version ist mit einem Klick wiederhergestellt. Danach beschreibt ihr in Ruhe, was sich ändern soll.

6. Updates kommen nach euren Regeln

Bei Apps, die ein Team installiert statt selbst baut, stellt sich eine eigene Frage: Wer entscheidet, wann sich etwas ändert? In manchen Bereichen sind automatische Updates genau richtig. In anderen, etwa beim Lohn, will man vorher sehen, was neu ist.

Installierte Apps aktualisieren sich in Openbase.one automatisch oder erst nach Zustimmung, festgelegt pro App. Wer eine installierte App anpasst, bekommt eine eigene Kopie und verändert nicht die Version anderer.

7. Code und Daten gehören dem Unternehmen

Eine App, die nur auf einem Account existiert, gehört faktisch diesem Account. Betriebsreif heißt auch: Das Unternehmen kann die App mitnehmen.

Der Code jeder eigenen App liegt als Git-Repository im Workspace, die Daten sind exportierbar. Ein Audit-Log hält fest, wer was geändert hat, und lässt sich ebenfalls exportieren.

8. Jemand ist fachlich verantwortlich

Der letzte Punkt ist kein technischer. Für jede App braucht es ein Team, das fachlich für sie geradesteht: das entscheidet, was die App tun soll, und Änderungen freigibt. Eine Prüfung kann zeigen, dass Rechte eingehalten werden. Ob eine Urlaubsregel oder eine Freigabegrenze fachlich richtig ist, kann keine Prüfung beantworten.

Diese Aufteilung halten wir für ehrlich. Openbase.one verantwortet die Umgebung: Isolation, Rechte, Prüfung und Versionen. Das Team verantwortet den Inhalt. Admins sehen jede App im Workspace.

Was betriebsreif nicht heißt

Betriebsreif heißt nicht, dass nie etwas schiefgeht. Keine Umgebung macht aus einer unklaren Anforderung eine richtige App. Es heißt, dass Fehler früh auffallen, wenig Schaden anrichten und schnell wieder weg sind.

Und es heißt, dass niemand allein dasteht. Plattform-Support ist in jedem Tarif enthalten. Mit einem Support-Vertrag helfen wir bei euren eigenen Apps; im Premium-Vertrag prüfen wir neue Apps auch vor dem Livegang. Wer eine App lieber gemeinsam mit uns bauen möchte, kann das als einmaliges Paket buchen.

Ausprobieren

Ihr könnt eure erste App kostenlos bauen, mit 15 € KI-Guthaben und ohne Kreditkarte. Tarife und Support-Verträge findet ihr auf der Preisseite.

Beschreibt eure erste App und seht, wie sie geprüft live geht.

Kostenlos starten

Baut die App, die euch fehlt.
Sicher ab der ersten Version.

In 30 Sekunden angemeldet, per E-Mail, Google oder Microsoft. Der Workspace ist sofort bereit, ohne Setup und ohne Kreditkarte.

Testphase mit 15 € KI-Guthaben. Keine Kreditkarte nötig.