Auditoría técnica · Código generado con IA · Due diligence
Auditoría técnica de tu app: sabe exactamente qué tienes antes de decidir qué hacer
Análisis completo de arquitectura, seguridad, rendimiento y proceso, hecho por ingenieros senior leyendo el código. Con evidencia por hallazgo, para decidir antes de refactorizar, migrar o vender, y para saber qué hay dentro de lo que generó un modelo.
Empresas que ya confían en Dribba
Respuesta directa
Auditoría técnica de apps móviles: análisis completo de arquitectura, seguridad OWASP MASVS, rendimiento y proceso, con severidad y evidencia por hallazgo. Lo hace un ingeniero senior leyendo el código, no un escáner: 15 años revisando apps en producción. Entregable en 2-3 semanas con informe ejecutivo + informe técnico detallado, desde 4.100 €. Uno de los encargos que más entra hoy es revisar código generado con IA antes de ponerlo delante de usuarios; también sirve para due diligence M&A y validación pre-inversión.
15+
Años revisando código en producción
+100
Apps auditadas
2-3 sem
Informe completo
4.100 €
Desde
Código generado con IA
Generarlo es rápido. Saber qué generaste, no.
Cuatro cosas que aparecen casi siempre cuando el código lo escribió un modelo y no lo revisó nadie. Ninguna impide que la app funcione. Todas se pagan más tarde.
Dependencias que el modelo dio por buenas
Librerías abandonadas, versiones que no existen o paquetes con el nombre casi igual al que tocaba. Es el hallazgo más repetido, y el más rápido de explotar desde fuera.
Credenciales dentro del binario
Claves de API y tokens escritos en el código porque así funcionaba en la primera prueba. En una app móvil el binario es público: cualquiera lo descomprime.
Cuatro maneras de hacer lo mismo
Cada sesión con el modelo resolvió el mismo problema a su manera. Funciona, y a los seis meses nadie sabe cuál de las cuatro es la que hay que tocar.
Cobertura de pruebas que no cubre nada
Tests generados junto al código, que comprueban que el código hace lo que hace. Pasan siempre, y no detectan una regresión ni por casualidad.
Metodología
Cuatro dimensiones, y un senior leyendo el código en las cuatro.
Un escáner encuentra lo que sabe buscar. Lo que hunde una app, como un límite de arquitectura que nadie respeta o un flujo crítico sin pruebas, hay que leerlo. 15 años revisando apps en producción es lo que separa una cosa de la otra.
Arquitectura y deuda
Lectura del código módulo a módulo, no un escáner: acoplamientos, límites que nadie respeta y dependencias que se pueden quitar.
Revisión manual · análisis de dependencias
Seguridad
Las ocho categorías de OWASP MASVS, una por una: almacenamiento, red, autenticación, privacidad, criptografía, plataforma, código y resistencia.
OWASP MASVS
Rendimiento
Medición en dispositivo real, no en simulador. CPU, memoria y red, y los cuellos de botella que más se notan en la experiencia.
Xcode Instruments · Android Profiler · Dart DevTools
Proceso
Cómo se integra, cómo se despliega, qué cubren las pruebas de verdad y qué riesgo trae cada dependencia externa.
CI/CD · cobertura · Lighthouse
Qué se audita
Seis auditorías distintas. Casi nadie necesita las seis.
En la primera llamada se decide cuál de ellas responde a la decisión que tenéis encima de la mesa.
Auditoría de deuda técnica
Mapeado completo de la deuda técnica existente: código sin tests, arquitecturas frágiles, dependencias obsoletas y antipatrones que ralentizan el equipo.
Auditoría de seguridad OWASP MASVS
Revisión completa frente al estándar OWASP para apps móviles. Almacenamiento seguro, autenticación, comunicaciones, criptografía y resiliencia de la app.
Auditoría de rendimiento y UX técnica
Profiling de CPU, memoria y red. Identificación de los cuellos de botella con mayor impacto en la experiencia de usuario y las métricas de stores.
Due diligence técnica M&A
Evaluación del activo tecnológico para procesos de inversión, adquisición o fusión. Informe ejecutivo para inversores y técnico para el equipo comprador.
Evaluación de arquitectura y escalabilidad
Revisión de la arquitectura de la app y el backend para identificar si puede soportar el crecimiento previsto sin una refactorización mayor.
Auditoría pre-migración a Flutter
Análisis del estado de la app actual para planificar la migración a Flutter: módulos prioritarios, riesgos, estimación de esfuerzo y estrategia de migración incremental.
Qué cuesta y qué tarda
Un diagnóstico se compra por lo que permite decidir.
Cada pieza dice a quién le habla. Un CTO y un responsable de negocio no compran lo mismo.
Severidad, esfuerzo y euros. No un PDF de doscientas páginas.
Cada hallazgo lleva su severidad, su esfuerzo estimado de remediación y si podemos ejecutarlo nosotros. El diagnóstico sin plan de acción no sirve para decidir nada.
4.100 €
Desde, app de consumo
Enterprise con integraciones múltiples o requisitos de fintech y salud: entre 5.900 € y 9.400 €.
2-3 sem
Hasta el informe completo
El ejecutivo para el comité llega antes que el técnico. Apps enterprise complejas, 4-6 semanas.
8 cat.
Categorías de OWASP MASVS
Almacenamiento, red, autenticación, privacidad, criptografía, plataforma, código y resistencia.
Cualquier stack, no solo Flutter
Nativo iOS y Android, React Native, Flutter e híbridas. Y el backend que da servicio a la app.
Qué te llevas
El expediente es el producto.
No se compra una revisión: se compra esta carpeta. Un fichero por dimensión analizada, con severidad y esfuerzo en cada hallazgo.
Está pensada para que podáis decidir con ella delante: qué se arregla primero, qué cuesta, y qué pasa si no se arregla.
01-informes/
ejecutivo.pdfNegocioEl corto, para el comité o el inversor: estado del activo, riesgo y qué se hace con él.tecnico-detallado.pdfCTOLa versión larga, hallazgo por hallazgo y con su severidad: crítico, alto, medio o bajo.plan-remediacion.mdCTOQué se arregla primero, cuánto esfuerzo lleva cada cosa y si podemos ejecutarlo nosotros.
02-hallazgos/
deuda-por-modulo.mdCTOLa deuda técnica repartida por módulo, con estimación de remediación en días. No un adjetivo.owasp-masvs.mdCTOLas ocho categorías del estándar, una por una, con lo que cumple y lo que no.rendimiento.mdCTOProfiling de CPU, memoria y red, y los tres a cinco cuellos de botella que más se notan.
03-proceso/
ci-cd-y-tests.mdCTOCómo se integra, cómo se despliega y qué cobertura de pruebas hay de verdad.dependencias.mdCTOQué librerías están obsoletas, cuáles ya no tienen mantenimiento y qué riesgo trae cada una.
04-decision/
mantener-refactor-migrar.mdNegocioLa recomendación, con el argumento técnico y económico de cada una de las tres opciones.
legal/
nda.pdfLegalFirmado antes de tocar el repositorio. No hace falta acceso a producción ni a datos de usuarios.
Lo que preguntan antes de firmar
Las seis frases que salen en la primera llamada.
Y qué respondemos. Cuatro las dice quien lleva la técnica y dos quien lleva el negocio.
«Esto va a ser un informe de doscientas páginas que nadie lee.»
Cada hallazgo lleva severidad, esfuerzo estimado de remediación y si Dribba puede ejecutarlo. Y el informe ejecutivo va aparte del técnico, para que el comité lea cuatro páginas y no cuarenta. No es consultoría de cajón.
«No os voy a dar acceso a producción ni a los datos de usuarios.»
No hacen falta. Con el repositorio, las builds de test o las apps en store, las credenciales de staging y la documentación que haya, es suficiente. Y el NDA se firma antes de cualquier acceso.
«La app funciona. No sé qué vais a auditar.»
Una app puede funcionar perfectamente para el usuario y tener una arquitectura que hace que cada función nueva tarde el triple. Las señales son conocidas: módulos que nadie quiere tocar, cambios pequeños que mueven cientos de líneas, semanas de onboarding.
«Nuestra app no es Flutter, así que no aplica.»
Auditamos nativo iOS (Swift y Objective-C), Android (Kotlin y Java), React Native, Flutter e híbridas con Ionic o Capacitor. Y el backend que da servicio a la app, si hace falta.
«Necesito algo que pueda poner delante de un inversor.»
Es de los encargos más frecuentes: due diligence técnica pre-M&A o pre-ronda, con el estado real del activo y la deuda técnica estimada en euros de remediación. Informe ejecutivo para quien decide y técnico para quien lo hereda.
«Y cuando tengamos el informe, ¿quién lo arregla?»
El plan dice, hallazgo por hallazgo, si podemos ejecutarlo nosotros. Se puede hacer con vuestro equipo, con engineers nuestros integrados en él, o con nosotros llevando la dirección técnica. Las tres puertas están enlazadas al final de esta página.
Proceso
Del NDA a la sesión de resultados.
Cuatro fases y ningún acceso a producción. Cada una cierra con algo que se puede abrir.
01
NDA y accesos
Se firma el NDA y se piden los accesos: repositorio, builds de test o apps en store, entorno de staging y la documentación de arquitectura que exista.
NDA firmado y accesos
02
Análisis
Arquitectura y deuda, seguridad frente a OWASP MASVS, rendimiento con profiling real, y el proceso: integración, despliegue, pruebas y dependencias.
Hallazgos con severidad
03
Los dos informes
El ejecutivo para quien decide y el técnico detallado para quien lo va a arreglar, con el plan de remediación priorizado por impacto en el negocio.
Ejecutivo + técnico + plan
04
Presentación de resultados
Reunión con el equipo técnico y el directivo. Va siempre incluida: un informe que se entrega por correo y no se explica acaba archivado.
Sesión de resultados
Guía
Auditoría técnica de apps móviles: cuándo hacerla, qué cubre y cómo interpretarla
Una auditoría técnica de una app móvil no es una revisión de código superficial. Es un diagnóstico sistemático que cubre cuatro dimensiones: arquitectura y deuda técnica, rendimiento y experiencia de usuario técnica, seguridad frente a estándares como OWASP MASVS, y calidad del proceso de desarrollo (CI/CD, cobertura de tests, gestión de dependencias). El resultado no es un documento de 200 páginas que se cierra en un cajón, sino un informe priorizado que permite al CTO tomar decisiones de inversión: qué arreglar primero, cuánto costará, y qué impacto tiene en el negocio cada hallazgo.
Los momentos en los que una auditoría técnica tiene más valor son tres: antes de una inversión de desarrollo significativa (¿dónde está la deuda que va a frenar todo lo demás?), antes de un lanzamiento crítico en un mercado nuevo con requisitos de seguridad elevados (el equipo de IT del cliente o del regulador va a mirar estas cosas), y en procesos de M&A donde la app es el activo principal de la empresa objetivo. En estos tres escenarios, la auditoría convierte la incertidumbre técnica en cifras concretas: días de esfuerzo de remediación, nivel de riesgo de seguridad, y estimación del impacto en rendimiento de los cambios propuestos.
La deuda técnica es el concepto más difícil de vender a un consejo de administración porque no se ve hasta que paraliza al equipo. Una app puede funcionar perfectamente para el usuario final y tener una arquitectura que hace que cada nueva feature tarde el triple de lo que debería. Las señales más comunes: el equipo habla de 'tocar X sin romper Y', hay módulos que nadie quiere tocar porque 'están muy liados', los PRs de features pequeñas tienen cientos de líneas de cambios en archivos no relacionados, y el onboarding de nuevos developers tarda semanas porque el código no es autodescriptivo. La auditoría pone números a esa situación.
La seguridad en apps móviles tiene un estándar de referencia consolidado: el OWASP Mobile Application Security Verification Standard (MASVS). Cubre ocho categorías: almacenamiento de datos, comunicaciones de red, autenticación y gestión de sesiones, privacidad, criptografía, interacción con la plataforma, calidad y resiliencia del código, y resistencia a la ingeniería inversa. Para apps financieras, sanitarias o con datos de usuario sensibles, una evaluación frente a MASVS antes del lanzamiento no es opcional: es lo que permite al CTO afirmar con evidencia objetiva que la app cumple con los estándares de seguridad que los clientes enterprise y los reguladores esperan.
Cuándo una auditoría no es lo que necesitáis.
Te lo decimos en la primera llamada. Cobrar por un informe que no cambia ninguna decisión sale caro para los dos.
Ya sabéis qué está roto y por qué
Si el diagnóstico existe y está compartido, pagar por confirmarlo no cambia ninguna decisión. Lo que falta ahí es ejecutar, y eso es otro encargo.
La app se sustituye en los próximos meses
Auditar un activo que se va a tirar es pagar por un informe que caduca antes de aplicarse. Si la decisión de reescribir ya está tomada, lo útil es la auditoría pre-migración, que es más corta y mira otra cosa.
Lo que buscáis es una segunda opinión, no un diagnóstico
Si la pregunta es «¿esta decisión de arquitectura tiene sentido?», se resuelve en una sesión y no en tres semanas de análisis. Eso es dirección técnica puntual.
Lo que preguntan antes de encargar una auditoría.
Revisamos arquitectura y deuda técnica, rendimiento (Lighthouse, Xcode Instruments, Android Profiler), seguridad (OWASP MASVS), calidad de código, cobertura de tests, integraciones y dependencias externas, y el proceso de CI/CD. El resultado es un informe con severidad de cada hallazgo y un plan de remediación priorizado.
Una auditoría estándar (app con 1-3 módulos principales) tarda 2-3 semanas. Apps enterprise más complejas con integraciones múltiples pueden requerir 4-6 semanas. El informe ejecutivo para el C-suite está disponible antes del informe técnico completo.
Sí. Auditamos apps nativas iOS (Swift/Objective-C), Android (Kotlin/Java), React Native, Flutter e híbridas (Ionic/Capacitor). Para web apps y backends que dan servicio a la app también ofrecemos revisión de arquitectura.
El análisis completo parte de 4.100€ para apps de consumo estándar: arquitectura, seguridad, rendimiento y proceso, con informe ejecutivo e informe técnico. Apps enterprise con múltiples integraciones, módulos complejos o requisitos de seguridad elevados (fintech, salud) están entre 5.900€ y 9.400€. Incluimos siempre reunión de presentación de resultados con el equipo técnico y directivo.
Sí. La due diligence técnica pre-M&A es uno de los encargos más frecuentes. Evaluamos el estado real del activo tecnológico, estimamos la deuda técnica en euros de remediación y valoramos el riesgo de la adquisición. Firmamos NDA antes de cualquier acceso al código.
Siempre incluye ambas cosas. El diagnóstico sin plan de acción no es útil. Para cada hallazgo indicamos severidad (crítico/alto/medio/bajo), esfuerzo estimado de remediación y si Dribba puede ejecutarlo. No es un informe de consultoría que se cierra en un cajón.
Acceso al repositorio de código fuente (GitHub/GitLab/Bitbucket), acceso a las apps en stores (o builds de test), credenciales de entornos de staging, y documentación de arquitectura existente si la hay. Todo bajo NDA. No necesitamos acceso a producción ni a datos de usuarios.
La primera llamada
Tres preguntas. Con las respuestas ya sabemos qué auditoría te sirve.
No puedes mejorar lo que no mides, pero tampoco tiene sentido medir lo que ya sabes. Si la auditoría no cambia ninguna decisión, te lo decimos ahí.
¿Qué decisión depende del resultado de la auditoría?
Invertir, migrar, vender o contratar. El informe se escribe distinto según cuál sea.
¿Quién va a leer el informe: vuestro equipo, un inversor o un comité?
Marca cuál de los dos documentos es el importante y con qué nivel de detalle se redacta.
¿Tenéis ya los accesos al repositorio y a staging, o hay que pedirlos?
Es lo que decide si la auditoría arranca esta semana o la que viene.
o
Más sobre desarrollo Flutter