sostituire un'app retool che hai superato. sostituire un'app retool cresciuta troppo succede quando lo strumento interno in cui vive il tuo team ops smette di far risparmiare tempo e comincia a costarlo. il segnale non è l'età dell'app. è la settimana che un ingegnere passa a districare una query rotta che nessuno ha documentato, o la fattura per postazione che cresce più in fretta del team che la usa. sostituirla significa possedere il codice, l'autenticazione e l'audit trail, invece di affittarli.
il team aveva un'app retool. gestiva le sue operations interne: rimborsi, modifiche agli account, escalation di supporto. faceva anche tre cose che all'inizio non faceva. si rompeva in modi che solo un ingegnere capiva. fatturava per postazione anche per chi apriva una sola schermata. e ogni correzione significava modificare una configurazione che nessuno voleva avere in carico. l'app non ha fallito. il team l'ha superata.
#come faccio a sapere che è il momento di lasciare retool?
non è un numero di utenti a deciderlo. osserviamo quattro segnali. quante ore-ingegnere a settimana servono per tenere in vita l'app. quante postazioni a pagamento appartengono a persone che leggono una sola schermata. quante modifiche vanno in produzione senza un audit trail di cui qualcuno si fidi. e quanto tempo impiega un nuovo assunto ops prima di smettere di chiedere a un ingegnere di fare la modifica al posto suo. quando tre di questi quattro vanno nella direzione sbagliata, è lo strumento il collo di bottiglia, non il team.
quando conviene sostituire un'app retool con uno strumento interno di proprietà?
sostituiscila quando mantenere l'app retool costa più tempo ingegneristico di quanto ne faccia risparmiare, quando il prezzo per postazione cresce più in fretta del team che la usa, o quando le modifiche vanno in produzione senza audit trail. ricostruisci come strumento di proprietà, con autenticazione, ruoli e log, solo il workflow o i due workflow che l'hanno superata. tieni il resto finché non fa male.
#com'è stata davvero la sostituzione?
lo abbiamo fatto per un team di prodotto saas b2b di circa 40 persone. la loro app retool era cresciuta fino a decine di query e un sistema di permessi tenuto insieme a mano. non abbiamo ricostruito tutto in una volta. abbiamo consegnato uno strumento ops interno di proprietà con tre elementi integrati fin dal primo giorno, non aggiunti dopo. il team ops era completamente sul nuovo strumento entro due settimane dal passaggio.
- login, così l'accesso viene concesso e revocato in un unico posto (autenticazione)
- accesso basato sui ruoli, così un addetto al supporto e un amministratore vedono schermate diverse (rbac)
- un audit log che registra chi ha cambiato cosa, e quando
#perché gli ingegneri hanno recuperato una giornata a settimana?
l'app retool costava al team circa una giornata-ingegnere ogni settimana. quel tempo andava in query rotte, richieste di accesso gestite a mano e modifiche che richiedevano un ingegnere perché il team ops non poteva farle in sicurezza. lo strumento di proprietà ha spostato quel lavoro sul team ops. gli ingegneri hanno recuperato circa una giornata a settimana. pubblichiamo queste prove build-in-public nel journal.
il soggetto e i numeri qui riportati sono anonimizzati secondo l'accordo col cliente. la giornata a settimana recuperata e l'adozione in due settimane sono i numeri riportati dal cliente stesso, non proiezioni.
#non è solo una versione più grande del vendor lock-in?
we are
definiamo l'ambito dei workflow che hanno superato retool e li ricostruiamo come strumento interno di tua proprietà, con autenticazione, ruoli e audit log consegnati come parte della build, e ti consegniamo la codebase dal primo giorno.
we aren't
non siamo un altro abbonamento per postazione che affitti per sempre, e non siamo una ricostruzione custom di due trimestri che scambia un'app funzionante con una tabula rasa.
la differenza a cui il team teneva di più era la proprietà. l'abbonamento retool che stavano lasciando fatturava per postazione e teneva il codice sulla piattaforma di qualcun altro. lo strumento che abbiamo costruito è arrivato come repository di loro proprietà dal primo giorno. nessun prezzo per postazione. nessuna piattaforma da cui poter essere esclusi. è così che la divisione platforms costruisce strumenti ops interni.
la settimana in cui abbiamo smesso di rattoppare la vecchia app, ho riavuto indietro i miei ingegneri. era tutto qui il punto.
se il tuo team continua a rattoppare un'app retool che nessuno vuole avere in carico, la soluzione non è un'altra toppa. è possedere lo strumento, l'autenticazione e l'audit trail. definiamo quali workflow vale la pena spostare e quali lasciare stare attraverso un breve engagement di consulenza, poi costruiamo solo la parte che ha superato il vecchio strumento. raccontaci cosa stai costruendo.