Todo el mundo mira la curva de DAU. Casi nadie mira el log de crashes.
Pregúntale a un comprador qué revisó antes de adquirir un negocio de app móvil, y te dará un repaso seguro de MRR, ARPU, retención a día 30 y tendencia de instalaciones. Pregúntale cómo estaba la tasa de sesiones sin fallos en las últimas dos versiones, y la mayoría se quedará callada. Nadie lo puso en la hoja de cálculo, porque nadie se lo pidió al vendedor.
Ese es un vacío real, y distinto al de un sitio web. Un sitio lento te cuesta conversiones. Una app inestable puede costarte visibilidad en la tienda — tanto Google Play como la App Store usan señales de estabilidad técnica como parte de cómo (y si) una app se muestra a los usuarios. Comprar una app con una tasa de fallos que sube poco a poco no es solo heredar un backlog de bugs. Es heredar un problema de posicionamiento que las capturas del vendedor nunca mostraron.
La due diligence técnica de una app merece su propio análisis, distinto de la checklist genérica de código que harías para un sitio web o un SaaS. La due diligence financiera te dice lo que ganó la app. La revisión de salud técnica te dice si va a seguir ganando.
Por qué la estabilidad es un problema de visibilidad en la tienda, no solo de experiencia de usuario
Las tiendas de apps no son tuberías neutrales. Ambas plataformas rastrean la estabilidad como parte de la calidad continua de la app: la propia documentación de "vitals" de Android señala que una tasa de fallos por encima de aproximadamente el uno por ciento de los usuarios activos diarios es un "mal comportamiento" que puede reducir la visibilidad y la elegibilidad para ser destacada. Apple aplica señales de calidad equivalentes en los analíticos de App Store Connect, con comparativas frente a apps similares.
Eso significa que una app técnicamente frágil no solo molesta a sus usuarios actuales — puede estar ya perdiendo silenciosamente el descubrimiento orgánico que alimenta las nuevas instalaciones, mucho antes de que los ingresos muestren el daño. Para cuando una caída de instalaciones aparece en una captura de pantalla, el problema de estabilidad de fondo suele llevar meses activo.
Las cinco cifras que hay que sacar antes de hacer una oferta
| Métrica | Qué te dice | Dónde encontrarla |
|---|---|---|
| % de sesiones sin fallos | Estabilidad general en todos los usuarios | Play Console, App Store Connect, o una herramienta de reporte de fallos (p. ej. Crashlytics) |
| % de usuarios sin fallos | Si la inestabilidad es puntual o generalizada | Los mismos dashboards |
| Tasa de ANR (solo Android) | Congelamientos e interfaz que deja de responder, distinto de un fallo duro | Vitals de Android en Play Console |
| Tendencia de calificación por versión | Si una versión concreta introdujo una regresión | Reseñas de la tienda ordenadas por fecha, cruzadas con las notas de versión |
| SDK objetivo / versión mínima de SO | Cuánto se ha quedado atrás la app respecto a los requisitos actuales de plataforma | Ficha de la tienda frente a requisitos SDK actuales de Android/iOS |
Ninguna de estas cifras aparece en una cuenta de resultados. Todas aparecen en tu bandeja de soporte y en tu embudo de instalación-a-ingreso dentro del trimestre siguiente a asumir el negocio.
Cómo se ve realmente un "buen" número
Los benchmarks varían un poco según la categoría, pero la tendencia general se mantiene en las apps de consumo: una tasa de sesiones sin fallos cómodamente por encima del 99,5% es una base razonable, 99,9%+ es lo que suelen alcanzar los equipos que vigilan activamente su estabilidad, y los más disciplinados apuntan al 99,99%. En el otro extremo, las apps que bajan de aproximadamente el 99,9% de sesiones sin fallos tienen notablemente más probabilidades de quedar por debajo de una media de 3 estrellas — estabilidad y calificación están muy correlacionadas, porque un usuario que sufre fallos repetidos tiene muchas más probabilidades de dejar una reseña que uno que no los sufre.
Trata esto como una referencia orientativa, no como un criterio de aprobado/suspenso. Una app al 99,7% con una causa clara y corregible no es automáticamente un mal negocio — es un argumento de negociación, igual que un mes de ingresos flojo.
Cómo conseguir realmente estos datos como comprador
- 1. Pide capturas de dashboard con fecha de las últimas dos semanas, no una exportación histórica de hace meses. La tasa de fallos puede cambiar rápido tras una sola versión problemática.
- 2. Solicita acceso de solo lectura a Play Console o App Store Connect durante la due diligence si el tamaño del deal lo justifica. Un vendedor que se resiste en un deal de tamaño medio o mayor merece una conversación directa sobre el motivo.
- 3. Ordena las reseñas de la tienda por fecha reciente y busca lenguaje repetido — "se cierra al abrir", "se congela", "no carga" — agrupado en torno a una fecha concreta. Esa fecha es la regresión sobre la que preguntar.
- 4. Cruza el requisito mínimo de SO de la app con las versiones de plataforma actuales. Una brecha grande es un indicador de cuánto tiempo lleva sin mantenimiento serio el código.
- 5. Pregunta qué herramienta de reporte de fallos está integrada, y si alguien realmente la revisa. Una herramienta instalada pero sin supervisión te dice tanto como no tener ninguna.
- 6. Descarga la app tú mismo y úsala durante quince minutos en los flujos principales. Es el paso de verificación más barato de toda esta lista, y los compradores lo saltan constantemente.
Deuda técnica escondida detrás de una cifra de ingresos limpia
Una app que parece estable puede seguir cargando deuda que no se nota hasta que eres el propietario. Vigila los SDK de terceros — redes publicitarias, proveedores de pago, servicios de notificaciones push — sin actualizar desde hace un año o más; las plataformas imponen periódicamente subidas del SDK objetivo mínimo, y una app construida sobre dependencias desactualizadas puede enfrentarse a una carrera contrarreloj (o a una suspensión en la tienda) cuando llega ese plazo. Vigila también un código que depende de la configuración local o de la cuenta de desarrollador personal de una sola persona para poder publicar una actualización. No es una métrica de estabilidad, pero es el mismo tipo de riesgo: invisible en las cifras hasta el día en que lo necesitas y ya no está.
Señales de alerta que merece la pena revisar
| Señal | Por qué importa |
|---|---|
| Sesiones sin fallos a la baja en las últimas 2-3 versiones | Inestabilidad activa que empeora, no un incidente aislado |
| Reseñas de una estrella que mencionan fallos agrupadas justo después de una versión concreta | Indica una regresión que quizá aún no está corregida |
| La app apunta a una versión de SDK varias generaciones por detrás de la actual | Riesgo real de plazo forzado de la tienda o retirada, y señala un código desactualizado |
| El vendedor no puede aportar acceso reciente al dashboard ni capturas | Estás valorando el deal con la única métrica que no puedes verificar de forma independiente |
| SDK principales sin mantener desde hace 12+ meses sin plan de migración | Coste de reconstrucción escondido detrás de una ficha por lo demás limpia |
Ninguna de estas señales debería tumbar un deal automáticamente por sí sola. Son elementos de precio y negociación — un negocio con deuda técnica real puede seguir siendo una adquisición justa al precio correcto, con un plan y un presupuesto claros tras el cierre para arreglar lo que falla.
Dónde encaja esto en tu calendario de due diligence
Haz la versión rápida — capturas de dashboard más quince minutos usando la app — antes de enviar una LOI. Si algo no cuadra, convierte el acceso de solo lectura al dashboard en una condición explícita de la due diligence más profunda, y deja que tus hallazgos se reflejen en el precio o en una retención de garantía en lugar de confiar en una tranquilidad verbal.
Nada de esto es asesoramiento legal ni financiero — trátalo como una checklist de partida y consulta con un profesional técnico o legal cualificado antes de apoyarte en ella para estructurar una oferta. Pero la estabilidad de una app es una afirmación sobre el negocio exactamente igual que una cifra de ingresos, y merece el mismo nivel de escrutinio antes de ir a ver deals.Preguntas frecuentes
¿Necesito ser desarrollador para hacer esta comprobación?No. Cada métrica anterior vive en un dashboard (Play Console, App Store Connect, o una herramienta de reporte de fallos) que un comprador sin perfil técnico puede leer en cuanto alguien le da acceso o comparte una captura.
¿Una calificación baja siempre es un problema técnico?No siempre — muchas calificaciones bajas tienen que ver con el precio, decisiones de UX o funciones que faltan. Pero cuando las reseñas negativas mencionan específicamente cierres inesperados, congelamientos o que la app no abre, es una señal de estabilidad que conviene verificar en los dashboards, no solo una cuestión de gustos.
¿Y si el vendedor no quiere compartir el acceso al dashboard de fallos?Es una petición razonable para cualquier deal por encima de un tamaño pequeño. Si no cede, dale más peso a la evidencia de las reseñas de la tienda e incorpora la incertidumbre al precio en lugar de fiarte de su palabra.
¿Debo abandonar un deal con una tasa de fallos alta?No automáticamente. Trátalo como cualquier otro hallazgo de due diligence: incorpóralo al precio, negocia una retención de garantía, o consigue un compromiso firme de corrección antes del cierre, según la gravedad y la antigüedad de la inestabilidad.
La tasa de fallos y los datos de "vitals" de la tienda son de las comprobaciones más baratas de toda la due diligence — una captura de dashboard y quince minutos con la app — y saltárselas es la forma en que muchos compradores terminan heredando un problema de posicionamiento que no sabían que habían comprado. Añádelo a tu checklist antes de revisar las ofertas en Flippa, y crea una alerta de deals para tener tiempo de hacer esta auditoría con calma en vez de precipitarla bajo la presión de un anuncio.