Un rescate es el proyecto que empieza por los síntomas en lugar de por una lista de funcionalidades. La app ya existe, está en producción, y algo en ella está fallando: se pierden frames, se desconectan sesiones, los crashes suben, cada versión tarda más en salir que la anterior, o el equipo que la construyó ha dejado de responder. El trabajo de rescate se acota contra esos síntomas, se secuencia por severidad y se entrega en un producto que permanece en producción todo el tiempo.

Es un trabajo distinto de construir una app, y la evidencia que importa es distinta. Cualquiera puede prometer una reconstrucción; un rescate se juzga por si aquello concreto que estaba fallando deja de fallar, de forma medible, sin romper lo que todavía funciona. Por eso cada rescate que llevamos empieza con una auditoría y un plan por escrito; y por eso, cuando el plan dice dos semanas de arreglos en lugar de una reescritura, lo decimos.

Las llamadas que atendemos

  • Rendimiento: tirones al hacer scroll, animaciones que tartamudean, arranques lentos, listas que se ahogan con volúmenes de datos reales
  • Estabilidad: tasas de crashes en aumento, sesiones caídas, fugas de memoria que solo afloran tras minutos de uso real
  • Relevos abandonados: la agencia desapareció, el repositorio es confuso y nadie sabe con certeza dónde están las claves de firma
  • Bases de código generadas con IA: un prototipo generado que encontró usuarios reales y ahora necesita sobrevivirlos; la auditoría de código IA es la puerta de entrada para estos casos
  • Hojas de ruta atascadas: una arquitectura donde cada funcionalidad sale más despacio que la anterior, un síntoma tan real como un crash

Los rescates detrás de esta página

Un producto de telesalud en marcha, estabilizado en producción

YouMi es un servicio de consulta psicológica en línea cuya app Flutter estaba publicada en ambas tiendas y fallaba precisamente en aquello para lo que existía: las sesiones se caían, los mensajes del chat no se entregaban y la pila de navegación tenía fugas de memoria suficientes para provocar crashes al cambiar de pantalla. En dos semanas reconstruimos la capa de con un ciclo de vida de conexión real —reconexión automática, cola de mensajes durante los cambios de red—, añadimos seguimiento completo de estados de entrega y reescribimos la arquitectura de navegación sobre las API de enrutamiento modernas de Flutter. La app no salió de las tiendas mientras tanto. En telesalud la conexión es el producto, y por eso ese proyecto encabeza esta página: un rescate se mide contra aquello para lo que el producto existe.

Rendimiento probado en el extremo irrazonable

Arreglar un renderizado lento exige haber construido renderizados rápidos. Arcana sostiene un chat de miles de mensajes de markdown en streaming a 60 fps; ExtraETF mantiene su frame rate bajo datos de mercado en streaming. Esos techos importan para el trabajo de rescate porque calibran el diagnóstico: cuando perfilamos tu app, sabemos distinguir entre «Flutter no puede con esto» —rara vez cierto— y «esta tormenta de rebuilds se puede acotar», que suele ser el hallazgo real.

Cómo se desarrolla un rescate

1. Auditoría

Revisamos la base de código —arquitectura, gestión de estado, cobertura de pruebas, salud de las dependencias— contra los síntomas concretos que motivaron la llamada, y perfilamos la app en dispositivos reales en lugar de fiarnos del simulador. Recibes un informe de hallazgos por escrito y un plan secuenciado. A veces ese plan son dos semanas de arreglos; a veces es un refactor por etapas; ocasionalmente es una recomendación honesta de reconstruir, con el razonamiento adjunto.

2. Estabilizar

Los síntomas de mayor severidad se arreglan primero y se publican mediante despliegues escalonados, para que el alivio llegue a los usuarios en las primeras versiones y no al final del proyecto. La app mantiene su cadencia de publicación: congelarla sería sumar la caída de la hoja de ruta a la caída que ya tienes.

3. Blindar

Los arreglos se rodean de pruebas para que el fallo no pueda volver en silencio, la CI las ejecuta en cada cambio, y la monitorización de crashes y rendimiento queda cableada para cazar regresiones antes de que lo hagan las reseñas. Esta es la diferencia entre un rescate y una cita recurrente.

4. Entregar

El proyecto termina con la base de código en un estado del que un equipo pueda hacerse cargo: el tuyo, o el nuestro bajo ampliación de equipo si quieres que la capacidad se quede. El informe de hallazgos, el plan y la monitorización son tuyos en cualquier caso.

Las disciplinas de las que se nutre un rescate

Trabajo de frame rate

Los problemas de rendimiento se perfilan antes de arreglarse: en hardware de gama media, con datos reales, con la línea de tiempo abierta. Los hallazgos habituales son rebuilds sin acotar que se propagan en cascada por el árbol de widgets, listas que reconstruyen filas que deberían reciclar y trabajo hecho durante el build que debería estar en otra parte. El rendimiento es una propiedad de la ingeniería, no del framework: la misma disciplina que mantiene un chat en streaming a 60 fps es la que quita el tartamudeo de una pantalla de producto.

Refactors de gestión de estado

Muchas apps que fallan, fallan estructuralmente: estado disperso entre pantallas, dependencias implícitas, un cambio que desemboca en cinco regresiones. Refactorizamos la de forma incremental —pantalla a pantalla, detrás de pruebas, mientras la app sigue publicando— en lugar de declarar una reescritura. El objetivo es una arquitectura donde la próxima funcionalidad salga más barata que la anterior: la señal de que el síntoma de la hoja de ruta empieza a revertirse.

Fiabilidad en tiempo real

Las sesiones caídas y los mensajes sin entregar son bugs de ciclo de vida: conexiones sin política de reconexión, mensajes sin estados de entrega, sockets que mueren en silencio cuando cambia la red. El arreglo es un ciclo de vida de conexión real, construido una vez y con dueño: la disciplina que demuestra el proyecto de YouMi y la razón de que llevara dos semanas y no un trimestre.

Memoria y navegación

Las fugas que tumban una app tras diez minutos de uso se esconden en pantallas retenidas, listeners que sobreviven a sus widgets y pilas de navegación que nunca liberan lo que apilan. Reescribimos la navegación sobre las API de enrutamiento modernas de Flutter donde la arquitectura lo exige —la de YouMi lo exigía— y verificamos el arreglo con perfiles de memoria, no con optimismo.

Relevos de agencias desaparecidas

Una toma de relevo empieza con arqueología: accesos al repositorio, claves de firma, cuentas de las tiendas, contratos con el backend que nadie documentó. Hemos hecho esta recuperación antes y conocemos sus trampas —claves que solo existen en el portátil de un excontratista, fichas de tienda a nombre de la cuenta equivocada— y el primer entregable de la auditoría en estos casos es, simplemente, un inventario de lo que realmente controlas. Es un trabajo poco glamuroso que tiene que hacerse antes de que ninguna labor de ingeniería importe.

Cuando de verdad es una reescritura

Algunas apps llegan en un estado en el que repararlas ya no es rentable: una arquitectura que pelea contra el framework, dependencias con años de retraso, sin pruebas contra las que refactorizar. Cuando la auditoría dice eso, lo decimos, con el razonamiento por escrito, y la conversación se convierte en una reconstrucción acotada informada por todo lo que la auditoría encontró. Lo que no haremos es facturar un rescate contra una base de código que ya sabemos que es un derribo.

Cuánto cuesta un rescate

La auditoría es un encargo de alcance cerrado: 4-12 mil €, el mismo nivel de auditoría completa publicado en la página de auditoría de código IA; la maquinaria es idéntica tanto si el código lo escribió una agencia como si lo escribió un equipo interno o un modelo. El trabajo de estabilización se acota después a partir del plan secuenciado de la auditoría, síntoma a síntoma, de modo que apruebas el trabajo por tramos en lugar de comprometerte a ciegas. Si quieres que la capacidad se quede después, se aplica la tarifa publicada de ampliación de equipo: 8-11,2 mil € por ingeniero senior al mes.

No damos precios de estabilización antes de la auditoría: una cifra producida sin ver la base de código sería una conjetura vestida de traje, y la mayoría de los equipos que llegan a un rescate ya se han quemado una vez precisamente con un presupuesto de ese tipo.

Preguntas frecuentes

Dudas habituales de los equipos cuya app Flutter está fallando en producción.

Sí: parte de nuestro trabajo mejor documentado empezó exactamente así, incluido un producto de telesalud que estabilizamos mientras seguía en producción. Una toma de relevo empieza con una auditoría de la base de código y un inventario de lo que realmente controlas: accesos al repositorio, claves de firma, cuentas de las tiendas, documentación del backend. Recibes un informe de hallazgos por escrito y un plan secuenciado antes de cualquier conversación sobre reconstruir, porque a veces la respuesta son dos semanas de arreglos en lugar de una reescritura; y cuando es así, lo decimos.
Perfilando antes de cambiar nada: en hardware de gama media, con volúmenes de datos reales, con la línea de tiempo de rendimiento abierta. Las causas habituales son rebuilds de widgets sin acotar que se propagan por el árbol, listas que reconstruyen filas que deberían reciclar y trabajo pesado ejecutándose durante el build. El propio Flutter rara vez es el techo: el framework sostiene 60 fotogramas por segundo en pantallas con streaming y densas en animaciones cuando el renderizado es disciplinado, así que el arreglo casi siempre consiste en acotar bien el trabajo, no en pelear contra el framework.
Normalmente no, y la auditoría es lo que lo responde con honestidad. La mayoría de las apps que fallan tienen causas concretas y arreglables —un ciclo de vida de conexión ausente, estado disperso, navegación con fugas— que un refactor secuenciado resuelve mientras la app sigue publicando. Ocasionalmente una base de código llega de verdad a un punto en el que repararla ya no es rentable, y entonces la auditoría lo dice por escrito, con razonamiento, y la conversación se convierte en una reconstrucción acotada. Lo que no deberías aceptar de nadie es una recomendación de reescritura hecha antes de leer el código.
Acceso al repositorio, una build que arranque y lo que exista de cuentas de tiendas, claves de firma y documentación del backend, más los síntomas tal y como los vivís, en lenguaje llano. Que falten piezas es normal en situaciones de rescate; parte de la auditoría en los casos de relevo es establecer qué controlas realmente y recuperar lo que se pueda. Una build de producción actual y acceso al sistema de crash reporting, si lo tenéis, acortan considerablemente el diagnóstico.
Sí: es una restricción de diseño del proyecto, no una esperanza. Los arreglos se publican mediante despliegues escalonados por orden de severidad, para que los usuarios sientan el alivio en las primeras versiones, y la app mantiene su cadencia normal de publicación todo el tiempo. Así estabilizamos un producto de telesalud sin que saliera de las tiendas. Un rescate que exige apagar el producto es una reconstrucción con el nombre equivocado, y te lo diríamos en la fase de auditoría.
Sí, y es una llamada cada vez más frecuente: un prototipo generado encuentra usuarios reales y entonces se topa con producción, donde los agujeros de seguridad, los costes de API desbocados y los atajos de arquitectura afloran rápido. Nuestra auditoría de código IA existe precisamente para este perfil de base de código y funciona igual que cualquier auditoría de rescate: informe de hallazgos, plan secuenciado por severidad y después los arreglos. El código generado no es irreparable; simplemente falla en patrones que hemos aprendido a buscar primero.

Lee el caso de estudio de YouMi para el rescate sobre el que se construye esta página, la página de auditoría de código IA para la maquinaria de auditoría, o empieza por el pilar de desarrollo de apps con Flutter.