App de terapia ABA: 0.7★ → 4.4★ en 18 meses
App en React Native usada por terapeutas para flujos diarios. Pausamos el roadmap de funcionalidades, arreglamos lo que estaba roto, y montamos un ritual quincenal de triage de crashes que el equipo sigue ejecutando hoy.
0.7★ → 4.4★ · 500+ clientes · 3s → <0.5s arranque en frío
La situación
Una startup de salud conductual tenía una app en React Native que los terapeutas debían usar para sus flujos ABA diarios. El equipo tenía sesgo hacia enviar funcionalidades nuevas, pero el conjunto de funcionalidades existente era el verdadero problema.
Los usuarios chocaban con dolores constantes. La app no era confiable. La calificación en la App Store lo reflejaba: 0.7 estrellas al inicio del proyecto. Los crashes llegaban a cientos por causante principal por ciclo. El arranque en frío superaba los 3 segundos. Las licencias se estancaban alrededor de 500.
Qué hicimos
Primero, hicimos una mini-auditoría y demostramos a la organización que las funcionalidades existentes (no las faltantes) eran el dolor del usuario. Estaban renuentes pero aceptaron pausar el trabajo de funcionalidades nuevas.
Segundo, hicimos un refactor mayor en varios archivos para asegurar que la app escribiera correctamente a la base de datos local (WatermelonDB), luego leyera de vuelta y actualizara el store de Redux en orden coherente. Surgió una victoria colateral en la capa de Redux: empezamos a usar el store como señal de detección de cambios para suprimir re-renders innecesarios. Eso desbloqueó la mejora de arranque en frío.
Tercero, montamos un proceso quincenal de triage de crashes con Firebase Crashlytics. Cada dos semanas el equipo toma los 2–3 crashes principales, los prioriza para el siguiente ciclo y notifica proactivamente a los clientes afectados para que los ciclos de retroalimentación sobre los arreglos se mantengan ajustados. La cadencia sigue corriendo hoy.
Los números
En 18 meses, con Chris al frente: la calificación de App Store subió de 0.7 a 4.4. La cantidad de clientes creció de ~100 organizaciones a 500+. La cantidad de licencias (aproximadamente 5 por cliente) pasó de ~500 a 2,500+. El arranque en frío bajó de 3 segundos a menos de 0.5. El volumen de crashes en los principales causantes bajó de 500–1000 por ciclo a 50–100.
Números confirmados por Chris. Sin redondeo. Estos son resultados de un proyecto específico, no afirmaciones generalizadas sobre el desempeño del portafolio de la compañía.
Qué dice esto sobre Rescue
La lección más grande de este proyecto: no puedes rescatar un producto enviando más funcionalidades sobre una base rota. El trabajo de la auditoría es revelar eso, y el trabajo del rescate es convencer a todos de que la estabilidad es la funcionalidad. Por eso /rescue en CAM Software es auditoría primero y por qué reescopeamos trabajo más grande como Build o Partner antes que estirar un Rescue más allá de 8 semanas.
¿Quieres una lectura honesta de la tuya?
Reserva una llamada introductoria de 30 minutos. Si un Technical Audit encaja, lo definimos en la llamada. Si no encaja, te lo decimos.
Reserva una llamada introductoria de 30 minutos