Casi ninguno de los proyectos que salen mal lo hacen por un problema técnico. Salen mal por decisiones que se tomaron antes de escribir la primera línea de código, casi siempre con la mejor intención.

Estos son los siete que más se repiten, con lo que cuestan y cómo se evitan.

1. Empezar por la tecnología en vez de por el problema

“Quiero una app en Flutter.” Vale, pero ¿para quién y para qué? Elegir la tecnología antes de definir el problema es como comprar los materiales antes de tener los planos.

A veces la respuesta correcta ni siquiera es una app. Puede ser una web bien hecha, una automatización interna o un proceso mejor. Un proveedor que no te plantea eso, o no lo ha pensado o prefiere no decírtelo.

Cómo evitarlo: llega a la primera reunión con el problema y el usuario, no con la solución.

2. Meter todo en la primera versión

Es el error más caro de todos. La lógica parece impecable: “ya que lo hacemos, lo hacemos completo”. El resultado es un proyecto que tarda el triple, cuesta el triple, y llega al mercado con ocho funcionalidades de las que los usuarios usan dos.

Cada funcionalidad que añades no suma linealmente: multiplica los casos que hay que probar y las cosas que pueden romperse.

Cómo evitarlo: define un MVP de verdad y acepta que la primera versión te va a parecer pequeña.

3. No preguntar de quién es el código

Sucede más de lo que parece. Se firma, se paga, se lanza, y dos años después quieres cambiar de proveedor y descubres que el repositorio no es tuyo, que la infraestructura está a nombre de otro y que migrar cuesta casi lo mismo que rehacerlo.

Cómo evitarlo: que conste por escrito antes de firmar: el código fuente, el repositorio y todas las cuentas de infraestructura y de las tiendas están a tu nombre. Y pide acceso desde el primer día, no al final.

4. Olvidarse del mantenimiento

Una app no es una obra que se entrega y se acaba. iOS y Android publican versión mayor cada año y rompen cosas. Las librerías se quedan obsoletas. Los certificados caducan. Apple cambia requisitos de privacidad y te retira la app de la tienda si no los cumples.

Una aplicación sin mantenimiento empieza a fallar sola en 12-18 meses, sin que nadie la toque.

Cómo evitarlo: presupuesta entre un 15% y un 20% del coste de desarrollo al año, desde el principio, y ten claro qué incluye ese contrato y qué no.

5. Confundir “corregir un fallo” con “añadir algo”

Relacionado con el anterior y fuente inagotable de discusiones. El cliente cree que el mantenimiento cubre cambios; el proveedor entiende que cubre errores. Los dos tienen su lógica y nadie lo puso por escrito.

Cómo evitarlo: define en el contrato qué es una incidencia (algo que no funciona como se especificó) y qué es una evolución (algo nuevo o distinto), y qué precio tiene cada cosa.

6. No validar nada antes de construir

Se invierten meses y decenas de miles de euros en una app que nadie ha pedido. Se lanza. No la descarga nadie. Y entonces empieza la conversación sobre marketing, cuando el problema estaba antes.

Cómo evitarlo: habla con veinte usuarios potenciales antes de escribir código. No les preguntes si usarían tu app —todo el mundo dice que sí por educación—: pregúntales cómo resuelven hoy ese problema y qué les cuesta. Si nadie tiene el problema, no hay app que lo arregle.

Es exactamente lo que hicimos con Bipsy antes de construir nada: entrevistas con barberías y peluquerías sobre cómo gestionan hoy su agenda.

7. Lanzar y desaparecer

El día del lanzamiento no es la meta: es la salida. Es cuando empiezas a tener datos reales sobre qué usa la gente, dónde se atasca y qué pide.

Los proyectos que funcionan reservan presupuesto para los tres meses siguientes al lanzamiento, porque ahí es donde se corrige lo que la teoría no anticipó.

Cómo evitarlo: no gastes el 100% del presupuesto en llegar al lanzamiento. Deja entre un 20% y un 30% para después.

Un patrón común

Si te fijas, seis de los siete no son errores técnicos: son errores de expectativas y de contrato. La parte de escribir código es, con diferencia, la más predecible del proceso.

Por eso insistimos tanto en la fase de descubrimiento antes de dar un precio. No es burocracia: es donde se evitan estos siete.

Si estás a punto de encargar una app y quieres una segunda opinión sobre el planteamiento —no sobre el código—, escríbenos. Y si quieres ver cómo estructuramos estos proyectos, está en creación de aplicaciones móviles.