substituir um app retool que o time já superou. substituir um app retool que cresceu demais acontece quando a ferramenta interna em que o time de operações vive para de economizar tempo e passa a custar tempo. o sinal não é a idade do app. é a semana que um engenheiro gasta desembaraçando uma consulta quebrada que ninguém documentou, ou a fatura por licença que cresce mais rápido do que o time que a usa. substituir significa ser dono do código, da autenticação e da trilha de auditoria, em vez de alugá-los.
o time tinha um app retool. ele rodava a operação interna: reembolsos, mudanças de conta, escalonamentos de suporte. ele também passou a fazer três coisas que não fazia no início. quebrava de formas que só um engenheiro entendia. cobrava por licença de pessoas que abriam uma única tela. e cada correção significava editar uma configuração que ninguém queria assumir. o app não falhou. o time o superou.
#como saber se é hora de sair do retool?
não existe um número de usuários que decida isso. observamos quatro sinais. quantas horas de engenharia por semana vão para manter o app vivo. quantas licenças pagas pertencem a pessoas que só leem uma tela. quantas mudanças vão ao ar sem uma trilha de auditoria em que alguém confie. e quanto tempo um novo contratado de operações leva até parar de pedir para um engenheiro fazer a mudança por ele. quando três desses quatro sinais pioram, o gargalo é a ferramenta, não o time.
quando você deve substituir um app retool por uma ferramenta interna própria?
substitua quando manter o app retool custar mais tempo de engenharia do que ele economiza, quando o preço por licença crescer mais rápido do que o time que o usa, ou quando as mudanças forem ao ar sem trilha de auditoria. reconstrua como ferramenta própria, com autenticação, papéis e logs, apenas o um ou dois fluxos de trabalho que já superaram o app. mantenha o resto até doer.
#como foi a substituição na prática?
fizemos isso para um time de produto de saas b2b com cerca de 40 pessoas. o app retool deles já tinha crescido para dezenas de consultas e uma configuração de permissões mantida na marra. não reconstruímos tudo de uma vez. entregamos uma ferramenta interna de operações própria com três coisas incluídas desde o primeiro dia, não adicionadas depois. o time de operações estava totalmente na nova ferramenta em duas semanas após a migração.
- login, para que o acesso seja concedido e revogado em um único lugar (autenticação)
- acesso por papel, para que um representante de suporte e um administrador vejam telas diferentes (rbac)
- um log de auditoria que registra quem mudou o quê, e quando
#por que os engenheiros recuperaram um dia por semana?
o app retool custava ao time cerca de um dia de engenharia por semana. esse tempo ia para consultas quebradas, pedidos de acesso tratados manualmente e mudanças que exigiam um engenheiro porque o time de operações não conseguia fazê-las com segurança. a ferramenta própria transferiu esse trabalho para o time de operações. os engenheiros recuperaram cerca de um dia por semana. publicamos esses registros de construção pública no journal.
o cliente e os números aqui são anonimizados conforme o acordo com o cliente. o dia por semana recuperado e a adoção em duas semanas são números reportados pelo próprio cliente, não projeções.
#isso não é só uma versão maior do mesmo aprisionamento a fornecedor?
we are
definimos o escopo dos fluxos de trabalho que já superaram o retool e os reconstruímos como uma ferramenta interna que você possui, com autenticação, papéis e logs de auditoria entregues como parte da construção, e entregamos o código-fonte a você desde o primeiro dia.
we aren't
não somos mais uma assinatura por licença que você aluga para sempre, e não somos uma reconstrução sob medida de dois trimestres que troca um app que funciona por uma página em branco.
a diferença que mais importava para o time era a propriedade. a assinatura do retool que eles estavam deixando cobrava por licença e mantinha o código na plataforma de outra empresa. a ferramenta que construímos foi entregue como um repositório do qual eles são donos desde o primeiro dia. sem preço por licença. sem plataforma da qual podem ser bloqueados. é assim que a divisão platforms constrói ferramentas internas de operações.
na semana em que paramos de remendar o app antigo, recuperei meus engenheiros. esse era todo o objetivo.
se o seu time vive remendando um app retool que ninguém quer assumir, o ajuste não é mais um remendo. é ser dono da ferramenta, da autenticação e da trilha de auditoria. definimos, em um projeto curto de consultoria, quais fluxos de trabalho valem a pena migrar e quais deixar como estão, e depois construímos só a parte que já superou a ferramenta antiga. conte para nós o que você está construindo.