eine retool-app ersetzen, die ihr überwachsen habt. eine überwachsene retool-app zu ersetzen passiert, wenn das interne tool, in dem euer ops-team lebt, aufhört, zeit zu sparen, und anfängt, sie zu kosten. das erkennungsmerkmal ist nicht das alter der app. es ist die woche, die ein engineer damit verbringt, eine kaputte query zu entwirren, die niemand dokumentiert hat, oder die per-seat-rechnung, die schneller wächst als das team, das sie nutzt. sie zu ersetzen bedeutet, den code, die auth und den audit-trail zu besitzen, statt sie zu mieten.
das team hatte eine retool-app. sie steuerte den internen betrieb: rückerstattungen, kontoänderungen, support-eskalationen. sie tat außerdem drei dinge, die sie anfangs nicht tat. sie brach auf arten, die nur ein einziger engineer verstand. sie berechnete pro sitzplatz für leute, die nur einen einzigen screen öffneten. und jede korrektur bedeutete, eine config zu bearbeiten, die niemand besitzen wollte. die app ist nicht gescheitert. das team ist über sie hinausgewachsen.
#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 solltet ihr eine retool-app durch ein selbst besessenes internes tool ersetzen?
ersetzt sie, wenn die pflege der retool-app mehr engineering-zeit kostet, als sie spart, wenn per-seat-preise schneller wachsen als das team, das sie nutzt, oder wenn änderungen ohne audit-trail live gehen. baut den einen oder die zwei workflows, die die app überwachsen haben, als selbst besessenes tool mit auth, rollen und logs neu. behaltet den rest, bis es wehtut.
#wie sah das ersetzen tatsächlich aus?
wir haben das für ein ~40-köpfiges b2b-saas-produktteam gemacht. ihre retool-app war auf dutzende queries und ein von hand zusammengehaltenes berechtigungssystem angewachsen. wir haben nicht alles auf einmal neu gebaut. wir haben ein selbst besessenes internes ops-tool ausgeliefert, mit drei dingen von tag eins an eingebaut, nicht später angeschraubt. das ops-team war innerhalb von zwei wochen nach der umstellung vollständig auf dem neuen tool.
- 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
#warum bekamen engineers einen tag pro woche zurück?
die retool-app kostete das team etwa einen engineer-tag pro woche. diese zeit ging in kaputte queries, von hand bearbeitete zugriffsanfragen und änderungen, die einen engineer brauchten, weil das ops-team sie nicht sicher selbst machen konnte. das selbst besessene tool verlagerte diese arbeit zum ops-team. engineers bekamen etwa einen tag pro woche zurück. wir veröffentlichen diese build-in-public-belege im journal.
der auftraggeber und die zahlen hier sind gemäß kundenvereinbarung anonymisiert. der zurückgewonnene tag pro woche und die zweiwöchige einführung sind die eigenen gemeldeten zahlen des kunden, keine prognosen.
#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 euch gehört, mit auth, rollen und audit-logs als teil des builds, und wir übergeben euch die codebase am ersten tag.
we aren't
wir sind kein weiteres per-seat-abo, das ihr für immer mietet, und wir sind kein zwei-quartale-custom-rebuild, der eine funktionierende app gegen ein leeres blatt tauscht.
der unterschied, der dem team am wichtigsten war, war eigentum. das retool-abo, das sie verließen, berechnete pro sitzplatz und hielt den code auf der plattform eines anderen. das tool, das wir gebaut haben, kam als repository, das ihnen von tag eins an gehört. keine per-seat-preise. keine plattform, aus der man ausgesperrt werden kann. so baut die division platforms interne ops-tools.
in der woche, in der wir aufgehört haben, die alte app zu flicken, habe ich meine engineers zurückbekommen. genau darum ging es.
wenn euer team ständig eine retool-app flickt, die niemand besitzen will, hilft nicht noch ein patch. es hilft, das tool, die auth und den audit-trail zu besitzen. wir grenzen in einem kurzen consultancy-engagement ab, welche workflows es wert sind, umgezogen zu werden, und welche man in ruhe lässt, und bauen dann nur den teil, der die alte app überwachsen hat. sagt uns, was ihr baut.