Tienes una idea de app. O tienes una app que no está funcionando como esperabas. Buscas una agencia en Valencia y encuentras varias con portafolios con capturas de pantalla bonitas y propuestas que mencionan «desarrollo ágil», «diseño centrado en el usuario» y «tecnología escalable». Y no sabes cómo distinguir cuál de ellas va a construir algo que funcione de la que va a construir algo que parece que funciona.
El desarrollo de apps es uno de los proyectos donde las decisiones equivocadas al inicio tienen el coste más alto. Un proyecto de 6 meses con una agencia que no entiende tu negocio puede terminar en un producto que hay que rehacer — con todo lo que eso implica en tiempo, dinero y desgaste del equipo.
Aquí tienes los criterios que diferencian un buen proyecto de app de uno que termina en frustración, y cómo detectarlos antes de firmar.
Criterio 1 — ¿Empiezan por el problema o por la solución?
Una agencia de apps que sabe lo que hace empieza por entender el problema de negocio que la app tiene que resolver, quién es el usuario final y cuál es el modelo de negocio. Una agencia que no sabe lo que hace empieza hablando de tecnología, plataformas y presupuesto.
La primera reunión es el mejor indicador. Si en la primera reunión te preguntan cómo gana dinero la app, quién es el usuario y cuáles son los dos o tres flujos más críticos — estás con alguien que entiende el negocio. Si en la primera reunión te preguntan si quieres iOS y Android y te hablan de frameworks, tienes información sobre cómo va a ir el proyecto.
La pregunta de filtro que puedes hacer tú: «Antes de presupuestar, ¿qué necesitáis entender del proyecto?» La respuesta dice mucho sobre el proceso que hay detrás.
Criterio 2 — ¿Tienen proceso de diseño antes de desarrollo?
El error más caro en el desarrollo de apps es construir antes de diseñar. Cada hora de desarrollo sobre una funcionalidad que luego cambia porque el diseño no estaba validado es dinero que no se recupera.
Una agencia que trabaja bien tiene una fase de diseño UX/UI en Figma — con prototipo interactivo validado — antes de escribir una línea de código. El prototipo no es decorativo: es el documento que define exactamente qué se va a construir, qué interacciones tiene cada pantalla y cómo fluye el usuario entre ellas.
La pregunta: «¿Cómo manejáis el proceso de diseño antes del desarrollo? ¿Hay un prototipo validado antes de empezar a programar?» Si la respuesta es que diseño y desarrollo van en paralelo o que el diseño se va haciendo a medida que se construye, es una señal de riesgo.
Criterio 3 — ¿Qué tecnología usan y por qué?
La tecnología de una app importa más de lo que parece en el momento de la firma. La decisión entre desarrollo nativo (Swift/Kotlin), híbrido (React Native, Flutter, Ionic) o PWA tiene implicaciones en rendimiento, coste, velocidad de desarrollo y mantenimiento a largo plazo.
Lo que importa no es qué tecnología usan — es que puedan explicarte por qué esa tecnología para tu caso concreto. Si la respuesta es «usamos X para todo», sin razonamiento adaptado a tu proyecto, la tecnología la eligen por preferencia del equipo, no por lo que es mejor para ti.
En nuestro trabajo de desarrollo de apps, usamos Ionic Framework para apps híbridas iOS y Android cuando el contexto lo justifica: proyectos donde la velocidad de desarrollo importa, donde el mismo código tiene que funcionar en las dos plataformas, y donde el rendimiento nativo no es un requisito crítico. Y explicamos exactamente por qué en cada proyecto.
| Criterio | Nativo (Swift/Kotlin) | Híbrido (Ionic, Flutter) |
|---|---|---|
| Rendimiento | Máximo | Muy bueno, salvo casos extremos |
| Coste de desarrollo | Alto (dos equipos o dos bases de código) | Más eficiente (una base de código) |
| Velocidad de lanzamiento | Más lenta | Más rápida |
| Acceso a APIs nativas | Total | Casi todas, con plugins |
| ¿Cuándo elegirlo? | App con requisitos de rendimiento extremo, acceso profundo al hardware | La mayoría de apps de negocio, con buen rendimiento y coste controlado |
Criterio 4 — ¿Tienen proceso de QA definido?
El testing de una app es donde más se recorta cuando hay presión de tiempo o presupuesto. Y es donde los problemas que no se detectaron antes del lanzamiento aparecen en producción, con usuarios reales, en momentos que no se pueden controlar.
La pregunta concreta: «¿Cómo gestionáis el QA? ¿Hay un proceso de testing antes de cada entrega? ¿Se hacen tests en dispositivos reales, no solo en simuladores?» Una respuesta vaga sobre «buenas prácticas» no es suficiente. Quieres saber si hay un plan de test definido, si hay alguien con ese rol específico en el proyecto o si el testing lo hace el mismo developer que escribió el código.
Criterio 5 — ¿Qué pasa después del lanzamiento?
El lanzamiento no es el final del proyecto. Es el inicio de la vida real del producto. Las apps necesitan actualizaciones de sistema operativo, corrección de bugs que aparecen con uso real, mejoras basadas en el comportamiento de los usuarios reales y evolución de funcionalidades.
Antes de firmar, la pregunta que hay que hacer: «¿Qué incluye el mantenimiento post-lanzamiento y qué coste tiene?» Si nadie ha hablado de esto en el proceso comercial, aparecerá en forma de sorpresa en la primera factura después del lanzamiento.
Checklist para evaluar una agencia de apps
- ¿Te han preguntado por el modelo de negocio y el usuario antes de presupuestar?
- ¿Hay una fase de diseño UX/UI con prototipo validado antes del desarrollo?
- ¿Pueden explicarte por qué la tecnología que proponen es la correcta para tu caso concreto?
- ¿Hay un proceso de QA definido con testing en dispositivos reales?
- ¿El presupuesto especifica qué está cerrado y qué puede variar con el alcance?
- ¿Puedes hablar con un cliente de un proyecto similar que ya esté en producción?
- ¿Está claro qué incluye el mantenimiento post-lanzamiento y cuánto cuesta?
