¿Cuánto cuesta una aplicación? Por qué el precio depende de ti

Por qué el precio de una app va de R$15 mil a medio millón, y cómo un fundador no técnico estima el número correcto antes de pedir el primer presupuesto.

La primera llamada casi siempre trae la misma pregunta. El fundador describe el producto durante diez minutos, con una claridad impresionante sobre el cliente y el problema, y entonces hace la pregunta que vino a hacer: “¿cuánto cuesta una aplicación así?”. La respuesta honesta decepciona, porque la respuesta honesta es otra pregunta.

Una aplicación a medida en Brasil cuesta, en la práctica, de R$15.000 a más de R$500.000. Ese rango es tan amplio que resulta inútil. Y es amplio no porque el mercado sea confuso, sino porque el precio de una app no es un valor de tarifario: es el resultado de decisiones que el fundador todavía no tomó. Quien responde “cuesta R$80.000” sin hacer ninguna pregunta de vuelta está adivinando, o está vendiendo un paquete que tal vez no sea el tuyo.

Este texto no te da un número. Te da lo que falta para que llegues a él solo: las variables que mueven el precio, los tres caminos reales de construcción y cuánto cuesta de verdad cada uno, y el costo que desaparece de todos los presupuestos. Al final, cuatro preguntas que definen el valor antes de que hables con cualquier proveedor.

Por qué “cuánto cuesta una aplicación” es la pregunta equivocada

Pregunta “cuánto cuesta una casa” y nadie responde con un número. Responde con preguntas: cuántas habitaciones, qué barrio, reformar o construir desde cero. El software es igual, con un agravante: la mayor parte del costo está en cosas que no ves desde la fachada.

Fíjate en lo que pasa en foros de desarrolladores brasileños como r/brdev cada vez que alguien pregunta el precio de una app. Las respuestas pelean entre sí, de R$5.000 a R$300.000, y todas tienen razón, porque cada una respondió por una aplicación distinta. Un chat con login y un marketplace con pagos, transferencias a vendedores y antifraude son “una app” en la cabeza del fundador y dos proyectos sin nada en común por debajo.

El precio, entonces, es una salida, no una entrada. Cae de tres decisiones: el tamaño del alcance, el camino de construcción que elijas, y cuánto tiempo va a vivir el producto después del lanzamiento. Mueve cualquiera de ellas y el número se mueve. Por eso definir el alcance antes de contratar a un dev vale más para tu bolsillo que cualquier búsqueda de precios.

Los tres caminos, y cuánto cuesta de verdad cada uno

Existen tres formas de sacar una app del papel en Brasil. No compiten por el mismo proyecto: cada una resuelve un momento distinto de la empresa.

No-code (Bubble, FlutterFlow, Glide). Montas la app en una plataforma visual, sin programar. Cuesta de R$0 a R$15.000 si la montas tú mismo, o de R$15.000 a R$40.000 si contratas a alguien para que la haga, más la mensualidad de la plataforma. Es el camino correcto para validar una idea antes de gastar de verdad. El techo aparece cuando el producto crece: una regla de negocio que la plataforma no previó, un costo de suscripción que escala con los usuarios, un rendimiento que se traba en la pantalla número cien. La mayoría de los fundadores se queda en no-code unos seis meses de más.

Freelancer o fábrica barata. Un dev de marketplace o una fábrica pequeña entrega código a medida por la cotización más baja. Cuesta de R$25.000 a R$80.000 para una primera app. El rango es tentador y es donde vive la mayor parte de las historias malas: alcance que crece a mitad de camino, código que después nadie consigue mantener, el dev que desaparece la víspera de la entrega. No es una regla, pero es lo bastante frecuente como para que el fundador escuche de todo el mundo que “ya se quemó con un freelancer”.

Socio de ingeniería. Un equipo que hace discovery, define el alcance contigo, construye y sigue al lado después del lanzamiento. Cuesta de R$80.000 a R$500.000 o más, según el tamaño. Es caro en la factura y más barato en el total cuando el producto es el centro del negocio y necesita durar, porque pagas una vez por un sistema que aguanta el segundo y el tercer año. La diferencia no es el lenguaje de programación. Es tener un socio técnico que no es una caja negra, que muestra las decisiones en vez de esconderlas.

El error caro no es elegir el camino barato. Es elegir el camino barato para un problema que pedía el caro, y descubrir al año siguiente que vas a pagar todo de nuevo.

El costo que desaparece de todos los presupuestos: el mantenimiento

Todo presupuesto de app habla del día del lanzamiento. Casi ninguno habla de los dos años siguientes, que es donde se gasta el dinero de verdad.

El software no es una obra que termina. Está más cerca de un auto: anda bien, y aun así va al taller. El sistema operativo del celular cambia y rompe la pantalla de login. Una librería que la app usa deja de recibir actualizaciones y abre una brecha de seguridad. El cliente pide un ajuste, el competidor lanza una función, la regulación cambia. Mantener una app en el aire cuesta, por año, algo entre el 15% y el 25% de lo que costó construirla, y esa cuenta empieza al mes siguiente del lanzamiento, no años después.

Por eso “cuánto cuesta una aplicación” necesita una hermana que nadie hace: ¿cuánto cuesta mantenerla viva? Una app de R$60.000 que nadie presupuestó para mantener se vuelve un activo huérfano en el momento en que el único dev que entendía el código se va. Lanzar la app es el comienzo del costo, no el final.

Las cuatro preguntas que definen el precio

Antes de pedir cualquier presupuesto, responde estas cuatro preguntas. Hacen el trabajo que haría el proveedor, y te sacan de la posición de quien solo puede aceptar o rechazar un número.

1. ¿La app necesita existir, o la idea necesita ser validada? Si todavía no tienes clientes pagando, el producto correcto es el más pequeño posible que pruebe la tesis, no la app de tus sueños. Aquí el no-code suele ganar. Construir el sistema completo antes de la validación es la forma más cara de aprender que nadie quería el producto. Vale conocer la diferencia entre un alcance mínimo de verdad y la lista de deseos disfrazada de MVP.

2. ¿Cuántos flujos críticos tiene la app? Cuenta las acciones que, si se rompen, derriban el negocio: el registro, el pago, la transferencia, la entrega. Una app con un flujo crítico es un proyecto. Con cinco, son cinco proyectos. El número de flujos predice el precio mejor que el número de pantallas.

3. ¿La app es el producto o es un apoyo? Si el software es lo que el cliente paga por usar, es el centro y merece una ingeniería que dure. Si es una herramienta interna que organiza la operación, el cálculo cambia, pero no por debajo de lo que imaginas: las herramientas internas bien hechas suelen dar más retorno que una función más en el producto de cara al cliente.

4. ¿Cuál es tu apetito, en dinero y en tiempo? Aquí vale robar una idea de Shape Up, de Basecamp: un presupuesto empieza por un número y termina en un diseño, no al revés. En vez de preguntar “cuánto cuesta para hacer todo esto”, di “tengo R$50.000 y tres meses, ¿qué cabe?”. Fijar el tiempo y el dinero y dejar variar el alcance es lo que separa un proyecto que entrega de uno que estalla. El proveedor serio prefiere esa conversación; el que no la prefiere te está vendiendo la factura, no el resultado.

Con las cuatro respuestas en la mano, ya no preguntas “cuánto cuesta una aplicación”. Dices lo que necesitas, con qué apetito, y evalúas quién entendió. El número deja de ser un tiro al aire y pasa a ser una decisión.

El presupuesto más barato suele ser el más caro

La cuenta que casi nadie hace es la del retrabajo. Una app de R$30.000 que hay que reconstruir desde cero al año siguiente costó R$30.000 más la app de verdad, más un año perdido, más el cliente que no atendiste mientras la arreglabas. Lo barato no salió caro por mala suerte. Salió caro porque el precio bajo vino de cortar exactamente las partes que no aparecen en la demo: el manejo de errores, la seguridad, el código que la próxima persona consigue leer.

Ya vimos la misma película en equipos de producto distintos. El fundador elige la cotización más baja, recibe algo que funciona en la presentación, y descubre seis meses después que cada cambio simple lleva semanas, porque el sistema se montó para pasar la demo, no para crecer. Ahí el costo real llega de golpe. El buen software parece simple por fuera, aun estando construido con precisión por dentro; el mal software hace lo contrario, parece listo y cobra la cuenta después.

No existe un precio correcto para una aplicación. Existe el rango que tiene sentido para el problema que tienes, en la etapa en que está la empresa. Responde las cuatro preguntas, elige el camino con un ojo en el segundo año, y trata cualquier presupuesto que llegue sin preguntas de vuelta por lo que es: un tiro al aire bien vestido.

Preguntas frecuentes

¿Cuál es el costo para crear una aplicación?

En Brasil, de R$15.000 a más de R$500.000. El no-code hecho por ti queda cerca de la base; una app a medida con freelancer o fábrica va de R$25.000 a R$80.000; un socio de ingeniería para un producto que es el centro del negocio empieza en R$80.000. El valor sigue al alcance, al camino de construcción y a cuánto tiempo necesita durar el producto.

¿Cuánto cuesta en promedio una app?

El “promedio” engaña, porque mezcla proyectos sin nada en común. Para una primera app a medida con pocos flujos críticos, el rango más común en Brasil es de R$40.000 a R$120.000. Marketplaces, fintechs y cualquier cosa con pagos y antifraude quedan bien por encima de eso. Y suma a la cuenta del 15% al 25% por año de mantenimiento.

¿Cuánto cuesta publicar una app en las tiendas?

Publicar es la parte barata. La cuenta de desarrollador de Apple cuesta US$99 por año y la de Google Play, US$25 una sola vez. Lo que pesa no es el registro, es todo lo que viene antes de él y lo que viene después, en el mantenimiento. Cuidado con los presupuestos que destacan el costo de publicar para parecer completos.

¿Vale la pena empezar en no-code?

Para validar una idea antes de tener clientes pagando, casi siempre vale. El no-code es la forma más barata de descubrir si el producto tiene demanda. El error es tratar la plataforma como arquitectura definitiva: la mayoría de los fundadores se queda en no-code de seis a doce meses más allá del punto en que el producto ya pedía ingeniería a medida.