reemplazar una app de retool que se te quedó pequeña. reemplazar una app de retool que ha crecido demasiado ocurre cuando la herramienta interna en la que vive tu equipo de operaciones deja de ahorrar tiempo y empieza a costarlo. la señal no es la antigüedad de la app. es la semana que un ingeniero pasa desenredando una consulta rota que nadie documentó, o la factura por puesto que crece más rápido que el equipo que la usa. reemplazarla significa ser dueño del código, la autenticación y el registro de auditoría, en lugar de alquilarlos.
el equipo tenía una app de retool. gestionaba sus operaciones internas: reembolsos, cambios de cuenta, escaladas de soporte. también hacía tres cosas que al principio no hacía. se rompía de formas que solo un ingeniero entendía. facturaba por puesto a personas que abrían una sola pantalla. y cada arreglo significaba editar una configuración que nadie quería tener a su cargo. la app no falló. el equipo la superó.
#¿cómo sé que es hora de dejar retool?
no hay un número de usuarios que lo decida. vigilamos cuatro señales. cuántas horas de ingeniería a la semana se van en mantener viva la app. cuántos puestos pagados pertenecen a personas que solo leen una vista. cuántos cambios se despliegan sin un registro de auditoría en el que nadie confía. y cuánto tarda una nueva contratación de operaciones en dejar de pedirle a un ingeniero que haga el cambio por ella. cuando tres de esas cuatro van en la dirección equivocada, la herramienta es el cuello de botella, no el equipo.
¿cuándo deberías reemplazar una app de retool por una herramienta interna propia?
reemplázala cuando mantener la app de retool cueste más tiempo de ingeniería del que ahorra, cuando el precio por puesto supere al tamaño del equipo que la usa, o cuando los cambios se desplieguen sin registro de auditoría. reconstruye, como herramienta propia con autenticación, roles y registros, uno o dos flujos de trabajo que se le quedaron pequeños. mantén el resto hasta que duela.
#¿cómo fue realmente reemplazarla?
hicimos esto para un equipo de producto saas b2b de ~40 personas. su app de retool había crecido hasta decenas de consultas y una configuración de permisos sostenida a mano. no reconstruimos todo de golpe. entregamos una herramienta interna de operaciones propia con tres elementos integrados desde el primer día, no añadidos después. el equipo de operaciones estaba trabajando por completo en la nueva herramienta a las dos semanas del cambio.
- inicio de sesión, para que el acceso se conceda y se revoque en un solo lugar (autenticación)
- acceso basado en roles, para que un representante de soporte y un administrador vean pantallas distintas (rbac)
- un registro de auditoría que deja constancia de quién cambió qué, y cuándo
#¿por qué los ingenieros recuperaron un día a la semana?
la app de retool le costaba al equipo aproximadamente un día de ingeniería por semana. ese tiempo se iba en consultas rotas, solicitudes de acceso gestionadas a mano, y cambios que necesitaban a un ingeniero porque el equipo de operaciones no podía hacerlos con seguridad. la herramienta propia trasladó ese trabajo al equipo de operaciones. los ingenieros recuperaron cerca de un día a la semana. publicamos estas cuentas construidas en público en el journal.
el sujeto y las cifras aquí están anonimizados según el acuerdo con el cliente. el día a la semana recuperado y la adopción en dos semanas son cifras reportadas por el propio cliente, no proyecciones.
#¿no es esto solo una versión más grande del bloqueo con el proveedor?
we are
definimos el alcance de los flujos de trabajo que se le quedaron pequeños a retool y los reconstruimos como una herramienta interna que tú posees, con autenticación, roles y registros de auditoría entregados como parte de la construcción, y te entregamos el código desde el primer día.
we aren't
no somos otra suscripción por puesto que alquilas para siempre, ni una reconstrucción a medida de dos trimestres que cambia una app que funciona por una hoja en blanco.
la diferencia que más le importaba al equipo era la propiedad. la suscripción de retool que dejaban atrás facturaba por puesto y mantenía el código en la plataforma de otra empresa. la herramienta que construimos se entregó como un repositorio del que son dueños desde el primer día. sin precio por puesto. sin ninguna plataforma de la que puedan quedar excluidos. así es como la división de plataformas construye herramientas internas de operaciones.
la semana que dejamos de parchear la app vieja, recuperé a mis ingenieros. ese era todo el objetivo.
si tu equipo sigue parcheando una app de retool que nadie quiere tener a su cargo, el arreglo no es otro parche. es ser dueño de la herramienta, la autenticación y el registro de auditoría. definimos qué flujos de trabajo vale la pena migrar y cuáles dejar en paz mediante un breve proyecto de consultoría, y luego construimos solo la parte que se le quedó pequeña a la herramienta anterior. cuéntanos qué estás construyendo.