Lo que de verdad cuesta una app a medida: un desglose honesto y transparente

Pregunte a tres agencias cuánto cuesta una app a medida y obtendrá tres cifras que ni siquiera comparten un dígito. Una dice cuatro mil, otra cuarenta, y la tercera dice por lo bajo «depende» y agenda una segunda reunión. Ninguna miente, exactamente, pero ninguna le está diciendo lo que de verdad necesita saber: adónde va el dinero y por qué su app en concreto acaba donde acaba. Así que abramos el capó.

He redactado más presupuestos de apps de los que puedo contar, para negocios que van desde un autónomo del gremio hasta una cadena regional. La reacción más habitual ante un precio no es el susto por el total, sino la confusión por la horquilla. ¿Cómo puede el mismo encargo de tres palabras («una app de reservas») dar estimaciones que se diferencian por un factor de diez? La respuesta honesta es que «una app de reservas» no es un encargo. Es un deseo. El precio vive en las cien pequeñas decisiones que se esconden debajo.

Este artículo es el desglose que ojalá tuviera todo empresario antes de su primera llamada con un desarrollador. Sin relleno, sin tácticas de miedo, sin venta cruzada. Solo los componentes reales del coste, las cosas que en silencio duplican un presupuesto y algunas formas honestas de gastar menos sin acabar con algo de lo que se arrepienta.

Por qué dos presupuestos para «la misma app» se diferencian en 10x

El software no es un producto que se coge de una estantería: es trabajo, medido en las horas de personas cualificadas. Por eso el precio de una app a medida es, en esencia, simplemente alcance × tarifa por hora × riesgo. Todo lo demás es una nota al pie de esas tres cosas. Cuando dos presupuestos divergen mucho, una de esas tres cifras se está leyendo de forma muy distinta, y normalmente nadie lo ha dicho en voz alta.

El alcance es el factor obvio. «Una app de reservas» puede significar una sola pantalla donde los clientes eligen una franja, o puede significar calendarios del personal, pagos, recordatorios, un acceso de cliente, un panel de administración, reembolsos y un informe que el dueño lee el lunes. Las mismas tres palabras, diez veces el trabajo. El presupuesto barato suele asumir la versión pequeña; el caro asume en silencio la grande. Ninguno le preguntó a cuál se refería.

Luego está el riesgo, la parte que a nadie le gusta poner en precio. Un encargo vago, un cliente que no ha decidido qué quiere, una integración con un sistema heredado y achacoso: eso no solo añade horas, añade incertidumbre. Los equipos con experiencia colchonan ante la incertidumbre porque ya se han quemado con ella. Un presupuesto más barato a menudo no ha puesto precio al riesgo en absoluto, que es justo por lo que a veces se dispara a mitad de camino.

Adónde va realmente el dinero

Cuando la gente imagina el desarrollo de una app, imagina programar. Programar es real, pero rara vez supone ni la mitad de la factura. Una app a medida se parece más a construir una casa pequeña que a escribir un documento: alrededor de la parte visible hay diseño, instalaciones, inspección y papeleo. Así se reparte un presupuesto típico cuando se tiene todo en cuenta.

Dos cosas suelen sorprender de esa tabla. Primero, cuánto del presupuesto ocurre antes de escribir una sola línea de código funcional: descubrimiento y diseño no son un lujo, son el lugar más barato para corregir un error. Cambiar una pantalla en un boceto cuesta minutos; cambiarla una vez construida cuesta días. Segundo, lo real que es la línea de pruebas. Saltársela no ahorra dinero, solo traslada el coste a la semana del lanzamiento, con intereses.

Descubrimiento y diseño: la parte que todos quieren saltarse

El descubrimiento es donde convierte «una app de reservas» en una lista precisa de pantallas y reglas. Parece un gasto añadido porque aún no se construye nada. Pero cada hora aquí ahorra varias más adelante, porque es donde se elimina la ambigüedad mientras todavía es barata. Un equipo que le da un precio sin fase de descubrimiento o está adivinando, o planea facturarle el descubrimiento más tarde bajo otro nombre.

Desarrollo central: el motor visible

Es el código que hace funcionar su idea: las pantallas que la gente toca, la lógica detrás de ellas y la base de datos que recuerda todo en silencio. Es la mayor porción individual y escala casi directamente con el alcance. Cada función que añade es más que construir, más que probar y más que mantener para siempre. Esta es la línea donde «estaría bien que...» se encarece deprisa.

Integraciones: la parte engañosamente cara

Conectar su app con otros sistemas —cobrar con tarjeta, enviar un recordatorio por SMS, sincronizar un calendario, extraer datos del software de contabilidad que ya usa— parece poco en una lista de funciones y pesa sorprendentemente en la factura. Cada conexión es un pequeño proyecto en sí mismo, con sus propias rarezas y modos de fallo. Una integración de pago que se porta bien no es problema. Cinco integraciones enmarañadas con un sistema interno envejecido es donde mueren los presupuestos.

Los costes que nadie pone en el presupuesto

Aquí es donde muchos empresarios se llevan una desagradable sorpresa a los doce meses. La construcción es una cifra única; una app no es algo de una sola vez. El software está vivo —los teléfonos se actualizan, las reglas cambian, su negocio crece— y algo vivo necesita alimentarse. El presupuesto que firma es el precio del nacimiento, no el precio de la propiedad.

Nada de esto es una estafa ni una trampa oculta: es solo la parte que no encaja bien en un presupuesto de una página, así que los socios más flojos la omiten para parecer más baratos. Uno bueno se lo cuenta de antemano, aunque eso haga que su primera cifra parezca mayor. Pregunte explícitamente: ¿qué me cuesta tener esto en marcha durante un año tras el lanzamiento? La calidad de la respuesta le dice mucho de con quién está tratando.

Lo que en silencio duplica el precio

Algunas cosas añaden coste en proporción al valor que aportan: justo es. Otras añaden coste de forma totalmente desproporcionada, normalmente por cómo se estructura el trabajo más que por lo que hace la app. Estas palancas conviene entenderlas, porque algunas están enteramente en sus manos.

• Dos plataformas en lugar de una. Una app nativa de iPhone y una app nativa de Android son, a grandes rasgos, dos construcciones. Las herramientas multiplataforma o una app web pueden volver a juntarlas hacia una sola. Esta única decisión puede mover el total más que cualquier función.
• Diseño a medida frente a opciones por defecto sensatas. Una interfaz totalmente a medida y pulida al píxel cuesta dinero de verdad diseñarla y construirla. Una limpia y convencional, con patrones probados, es más rápida, más barata y a menudo más fácil de usar para los clientes.
• Cambiar de idea después de empezar la construcción. Las decisiones son baratas en una pizarra y caras en código. El sobrecoste más común no es una mala estimación, sino un alcance que no paró de crecer porque nada estaba cerrado.
• Tiempo real, sin conexión o datos pesados. «Debe funcionar sin cobertura» o «las actualizaciones deben aparecer al instante para todos» son peticiones razonables que en silencio multiplican la ingeniería que hay debajo.
• Integrar con algo viejo y sin documentar. Conectar con un sistema moderno y bien construido es rutina. Conectar con una herramienta interna de quince años sin documentación es arqueología, y se factura por horas.

Un ejemplo real: el presupuesto de 60.000 € que acabó siendo una app de 14.000 €

Cambiamos algunos detalles por privacidad, pero la forma de esto es real y totalmente típica. Una empresa de servicios regional —imagine una docena de operarios de campo y una oficina ajetreada— vino a nosotros frustrada. Querían una app a medida para que sus clientes reservaran trabajos, siguieran el progreso y pagaran. Ya tenían un presupuesto de otro sitio de unos 60.000 €, más una jugosa cuota mensual, y eso les había espantado de toda la idea durante casi un año.

Cuando de verdad mapeamos lo que necesitaban —no lo que les habían presupuestado— el panorama era muy distinto. El primer presupuesto había asumido dos apps totalmente nativas, un diseño a medida desde cero, un sistema de despacho en tiempo real y una plataforma de administración a medida para sustituir herramientas que ya tenían y con las que estaban discretamente contentos. Era, técnicamente, una app perfectamente buena. También era la respuesta a una pregunta que no habían hecho.

Lo que hicimos en realidad

Dedicamos las primeras sesiones solo a descubrimiento, separando el deseo en «el negocio se rompe sin esto» frente a «eso estaría bien algún día». Lo imprescindible era más reducido de lo que nadie esperaba: una forma limpia de que los clientes pidieran y siguieran un trabajo, recordatorios automáticos y pago en línea. El despacho en tiempo real y la trastienda a medida resultaron ser soluciones a problemas que su software existente ya resolvía bien.

1. 1
   Recortar el alcance al trabajo real

   Eliminamos las funciones que resolvían problemas que no tenían y conservamos una lista ajustada sin la que el negocio realmente no podía operar.
2. 2
   Elegir una única construcción multiplataforma

   En lugar de dos apps nativas separadas, una sola app multiplataforma cubría iPhone y Android, lo que más o menos redujo a la mitad el desarrollo central.
3. 3
   Usar patrones de diseño probados

   Una interfaz limpia y convencional en lugar de una a medida. A los clientes les resultó más fácil de usar y recortó semanas del calendario.
4. 4
   Conectar, no sustituir

   Enlazamos la app con el software de oficina que ya pagaban, en lugar de reconstruirlo. La costosa «plataforma de administración a medida» simplemente desapareció del alcance.

El resultado fue una construcción de en torno a 14.000 €, en directo en pocos meses, con unos costes de funcionamiento que podían prever. No es tan extensa como la versión de 60.000 €, y no necesita serlo. Hace el trabajo que el negocio tenía de verdad. Un año después, han añadido dos pequeñas funciones encima, pagadas con el dinero que les ahorró la primera versión. Ese es todo el patrón: empezar por el trabajo real y ganarse los extras con resultados.

Cómo mantener el coste bajo control sin recortar por lo barato

Gastar menos en una app a medida no consiste en regatear la tarifa por hora ni en encontrar el equipo más barato que pueda. Así se acaba pagando dos veces. Consiste en ser deliberado con el alcance, la secuencia y las decisiones: las tres cosas que de verdad mueven la cifra. Aquí viven los ahorros reales.

Primero, construya la versión más pequeña que sea realmente útil y luego hágala crecer. Una primera entrega enfocada que hace bien una sola cosa le pone en directo antes, cuesta una fracción del sueño todo-en-uno y —crucialmente— le enseña qué construir después a partir de clientes reales en lugar de suposiciones. Segundo, tome sus decisiones antes de empezar la construcción; la indecisión es lo más caro que puede aportar a un proyecto. Tercero, conecte con lo que ya posee en vez de sustituir herramientas que funcionan, y reconstruya algo solo cuando de verdad le esté frenando.

Preguntas frecuentes