Eine retool-app ersetzen, der man entwachsen ist. Ein illustratives praxisbeispiel, kein kundenergebnis: team und zahlen sind annahmen. Eine überwucherte retool-app zu ersetzen lohnt sich zu prüfen, wenn das interne tool, in dem dein ops-team lebt, keine zeit mehr spart, sondern kostet. Das zeichen ist die woche, die ein engineer mit einer kaputten, undokumentierten abfrage verbringt, oder eine lizenzrechnung, die schneller wächst als das team, das das tool nutzt. Ersetzen heißt, code, auth und audit-trail zu besitzen, statt sie zu mieten.
Angenommen, das team hat eine retool-app, die seine internen abläufe trägt: erstattungen, kontoänderungen, support-eskalationen. Sie tut außerdem drei dinge, die sie anfangs nicht tat. Sie geht auf arten kaputt, die nur ein engineer versteht. Sie berechnet menschen, die eine einzige ansicht öffnen. Und jede korrektur heißt, eine konfiguration zu ändern, die keiner besitzen will. Die app ist nicht gescheitert. Das team ist ihr entwachsen.
#Woran erkenne ich, dass es zeit ist, von retool wegzuziehen?
Es gibt keine nutzerzahl, die das entscheidet. Wir beobachten vier signale. Wie viele engineer-stunden pro woche fließen dorthin, die app am leben zu halten. Wie viele bezahlte sitzplätze gehören leuten, die nur eine ansicht lesen. Wie viele änderungen gehen live, ohne dass jemand dem audit-trail traut. Und wie lange braucht eine neue ops-einstellung, bis sie aufhört, einen engineer zu bitten, die änderung für sie zu machen. Wenn drei dieser vier signale sich in die falsche richtung entwickeln, ist das tool der engpass, nicht das team.
Wann sollte man eine retool-app durch ein eigenes internes tool ersetzen?
Ersetze sie, wenn die wartung der retool-app mehr engineering-zeit kostet, als sie spart, wenn die lizenzkosten schneller wachsen als das team, das sie nutzt, oder wenn änderungen ohne belastbaren audit-trail live gehen. Baue die ein oder zwei workflows, denen sie entwachsen sind, als eigenes tool mit auth, rollen und logs neu. Den rest lässt du, bis es wehtut.
#Wie sieht das ersetzen aus?
Nimm als annahme ein b2b-saas-produktteam mit etwa 40 personen. Seine retool-app ist auf dutzende abfragen und ein von hand zusammengehaltenes berechtigungssystem angewachsen. Das design baut nicht alles auf einmal neu. Es ist ein eigenes internes ops-tool mit drei dingen, die von anfang an eingebaut sind, nicht nachträglich drangeflanscht, und das ops-team zieht workflow für workflow um.
- Login, sodass zugriff an einer stelle vergeben und entzogen wird (auth)
- Rollenbasierter zugriff, sodass ein support-mitarbeiter und ein admin unterschiedliche screens sehen (rbac)
- Ein audit-log, das protokolliert, wer was geändert hat, und wann
#Woher kommt die engineering-zeit zurück?
Eine solche retool-app kostet jede woche engineering-zeit. Sie geht in kaputte abfragen, von hand bearbeitete zugangsanfragen und änderungen, die einen engineer brauchen, weil das ops-team sie nicht sicher machen kann. Das eigene tool verlagert diese arbeit ins ops-team. Die zahl, die man misst, sind engineer-stunden pro woche am ops-tool, vorher und nachher. Solche praxisbeispiele schreiben wir im journal auf.
das ist ein praxisbeispiel. Das team und jede zahl sind annahmen, kein kundenergebnis. Hier wird kein echtes projekt berichtet.
#Ist das nicht nur eine größere version des vendor-lock-in?
We are
Wir grenzen die workflows ab, die retool überwachsen haben, und bauen sie als internes tool neu, das dir gehört, mit auth, rollen und audit-logs von anfang an, und du besitzt die codebase von beginn an.
We aren't
Wir sind keine weitere plattform, die du für immer mietest, und kein kompletter custom-rebuild, der eine funktionierende app gegen ein leeres blatt tauscht.
Der unterschied, der einem solchen team am wichtigsten ist, ist eigentum. Eine gehostete plattform hält den code auf der seite eines anderen. Ein so gebautes tool kommt als repository, das dir von anfang an gehört, ohne plattform, aus der man ausgesperrt werden kann. So geht unsere arbeit in ai-implementierung interne ops-tools an.
Der test: in der woche, in der du aufhörst, die alte app zu flicken, bekommst du deine engineers zurück. Genau darum geht es.
Wenn dein team immer wieder eine retool-app flickt, die keiner besitzen will, ist die lösung nicht noch ein flicken. Sie heißt, das tool, die auth und den audit-trail zu besitzen. Welche workflows sich lohnen und welche man in ruhe lässt, klären wir über ai-beratung, und dann bauen wir nur den teil, der dem alten tool entwachsen ist. sag uns, was du baust.
