¿Cuánto cuesta desarrollar una app? La pregunta está mal hecha, y esta es la pregunta que sí funciona

Una founder con la que trabajamos el año pasado nos reenvió tres cotizaciones por lo que ella llamaba la “misma” app. US$ 18.000 de un freelancer en Bogotá. US$ 80.000 de un pequeño estudio en São Paulo. US$ 260.000 de una agencia estadounidense. Misma descripción de producto, mismos wireframes, tres estimadores honestos. Las tres cifras eran defendibles. La barata era un prototipo en Bubble que podía mostrar a inversionistas. La del medio era una app funcional que dos clientes reales podían usar sin que se rompiera. La cara incluía la integración SSO y la revisión de compliance que su piloto enterprise iba a exigir.

Cuánto cuesta desarrollar una app es una de las preguntas más buscadas en Google por founders. También es una de las menos respondibles. Las cifras de los listicles son técnicamente correctas de la misma forma que “una comida en Nueva York cuesta entre US$ 4 y US$ 400” lo es. El rango es tan ancho que no transmite nada. Peor aún: cada rango está sesgado por la fuente. Las agencias de apps cotizan rangos que favorecen a las agencias de apps. Los marketplaces de freelancers cotizan rangos que favorecen a los freelancers. Las plataformas no-code cotizan rangos que hacen que el no-code parezca obvio.

La pregunta que sí funciona es otra: ¿cuánto cuesta construir mi app, con mi alcance, en mi timeline, con un equipo en el que pueda confiar? El costo en software a medida es el resultado de seis drivers. Cuando conoces los tuyos, puedes nombrar un rango, defenderlo, y dejar de ser empujado por el área comercial.

Por qué la respuesta estándar está mal

La respuesta estándar funciona así. Una app simple cuesta de US$ 20K a US$ 50K. Una de complejidad media, de US$ 50K a US$ 150K. Una compleja de tipo enterprise, de US$ 150K a US$ 500K. Algunas fuentes empujan el techo a un millón.

Esos rangos no son mentira. Son el promedio de la población de apps que la fuente vio. Tú no estás construyendo la app promedio. Estás construyendo una app específica, y el promedio no te dice si tu número está en US$ 30K o en US$ 300K. La varianza dentro de cada banda es mayor que la propia banda.

El problema más profundo es que “simple, media, compleja” oculta cada decisión que de verdad mueve el número. Una app con una sola pantalla y checkout en Stripe es simple. Una app con una sola pantalla e integración SSO enterprise no lo es. Una app con cinco pantallas y un backend tipo Notion es enorme. Una app con quince pantallas y un panel admin CRUD es pequeña. Las etiquetas de categoría colapsan todo eso en ruido.

Los founders que se anclan en esos rangos cometen dos errores predecibles. Toman la cotización más barata dentro de su banda y descubren seis meses después que el equipo barato construyó una app distinta de la que necesitaban. O asumen que precio es igual a calidad y pagan 4x por un equipo que no es mejor que la opción del medio. Ambos errores empiezan en el mismo lugar: un número que nunca estuvo atado a una estimación real.

Los seis drivers que de verdad fijan tu número

El costo en software a medida no es magia. Es el producto de seis cosas, y puedes discutir con cualquier estimador sobre cada una. Si una cotización no descompone el número en al menos cuatro de esos seis, no es una estimación. Es un cálculo a ojo vestido como una.

Alcance: lo que hacen los usuarios, de inicio a fin

El alcance es el driver más grande, y el que los founders subestiman de manera consistente. La unidad correcta no son “pantallas” ni “features”. Son flows. Un flow es todo lo que un usuario hace para alcanzar un objetivo, desde el sign-up hasta el resultado.

La mayoría de los founders cuenta features y reporta el alcance como “diez features”. Una app funcional con diez features tiene aproximadamente cuarenta flows una vez que incluyes los caminos infelices (qué pasa cuando un pago falla, cuando una sesión expira, cuando un email rebota, cuando un usuario quiere borrar su cuenta, cuando un admin necesita reembolsar). Cada flow son entre dos y diez horas de trabajo según cómo esté armado el sistema por debajo. La diferencia entre contar diez features y contar cuarenta flows es la diferencia entre una cotización de US$ 40K y una realidad de US$ 120K.

Si todavía no escribiste los flows que tu app necesita soportar, no estás listo para ser cotizado. Estás listo para escribir un product requirements document, que es lo primero que un estimador real te va a pedir antes de cotizar.

Integraciones: con qué habla tu app

Cada sistema externo que tu app toca añade costo en dos lugares: el build inicial y la cola larga del mantenimiento. Una integración con Stripe es barata porque Stripe invirtió en ser fácil. Una integración directa con un proveedor de PIX brasileño no es barata, porque la documentación está en portugués, el sandbox es inestable, y los bugs de producción solo aparecen bajo carga.

Las integraciones también traen modos de fallo que el resto de tu código no tiene. Un webhook de Stripe puede llegar dos veces. Un CRM puede devolver un 502. Un proveedor de identidad puede cambiar su pantalla de consentimiento un martes. Manejar bien todo eso requiere más código que el camino feliz, y un estimador real lo cobra. Una cotización barata que lista “integración con Stripe” como una sola línea está cotizando el camino feliz y descubriendo el resto a tu costa.

Cuenta tus integraciones. La mayoría de las apps en etapa temprana tienen entre tres y siete (auth, pagos, email, analytics, file storage, una o dos APIs de dominio). Cada una rara vez sale por menos de US$ 2.000 de trabajo, y queda en US$ 5.000–US$ 10.000 si el proveedor es complicado.

Datos: dónde vive el estado, quién es dueño

Algunas apps son sobre todo UI encima de una pequeña tabla Postgres. Esas son baratas. Otras apps son sobre todo los datos, y la UI es una capa fina por encima. Esas no.

Las preguntas que mueven el número: cuántos datos por usuario, con qué frecuencia cambian, quién más necesita verlos, se pueden exportar, hay que poder buscarlos, cómo haces el backup, qué pasa cuando los datos de un usuario se corrompen a las 11 de la noche un viernes. Cada respuesta arrastra un diseño de US$ 0 o uno de US$ 20K. Un habit tracker B2C con cinco campos por usuario es el extremo barato. Una plataforma B2B que ingiere el CSV de un partner cada noche, lo transforma y lo expone en un dashboard al que el partner también tiene que loguearse es el extremo caro. Mismo número de pantallas.

Si tu app es el dato, el costo es el dato. Si tu app es el workflow encima del dato, el costo es el workflow. Los estimadores que no preguntan cuál de los dos estás construyendo no están estimando; están adivinando el más fácil de los dos.

Compliance y cuentas: lo que la ley y la identidad te obligan a construir

Tres cosas rompen una cotización barata al contacto: industrias reguladas, clientes enterprise, e identidad a escala.

Salud, fintech, educación y legaltech cargan con un overhead de compliance que no es opcional. HIPAA, SOC 2 readiness, LGPD, audit logs, cifrado en reposo, control de acceso por rol. Nada de eso es difícil, pero todo es trabajo, y agregar postura de compliance tarde cuesta entre tres y cinco veces más que cocinarlo desde el inicio.

Los clientes enterprise son parecidos. El día que tu primer cliente real te pida SSO, exportación de audit log, roles personalizados y un SLA es el día en que tu MVP de US$ 40K se convierte en un producto de US$ 120K. Ninguna de esas cosas es mala de construir. No son gratis, y una cotización barata que dice “agregamos las features enterprise después” está moviendo costo de la cotización al futuro.

La identidad es el tercer driver silencioso. Una app con un único rol de usuario es barata. Una app con admins, usuarios finales, super-admins, cuentas de partner y un rol read-only para el cliente no lo es. Cada rol arrastra una matriz de permisos detrás, y las matrices de permisos tienen la peor densidad de bugs de cualquier código del sistema.

Calidad del equipo: quién está escribiendo el código

Dos equipos cotizando el mismo alcance pueden producir números 3x distintos, y el número más alto suele ser el mejor negocio. Los equipos juniors escriben más código para hacer lo mismo, y luego escriben más código encima para arreglar lo que la primera ronda rompió. La tarifa por hora parece el ahorro. El costo total de propiedad cuenta la verdad.

Un equipo senior escribe menos código, lo escribe con más cuidado, lo deja documentado lo suficiente como para que un equipo futuro pueda extenderlo, y entrega un sistema que no se desploma la primera vez que intentas agregar una segunda feature encima. La tarifa por hora es más alta. El costo de construir, correr y extender la app durante sus primeros 18 meses suele ser más bajo.

Si no puedes evaluar código (y casi ninguno de nuestros clientes puede), mira señales. ¿Cómo habla el equipo de los trade-offs? ¿Pregunta por el objetivo de negocio o solo por la especificación? ¿Empuja de vuelta en pedidos que van a crear deuda técnica? ¿Te muestra un sistema corriendo en producción de un cliente anterior, no solo un screenshot de Dribbble? Un equipo que no puede defender una sola decisión de arquitectura en lenguaje claro es el equipo que va a cobrarte dos veces por la misma feature cuando se rompa. Desarmamos el resto del diagnóstico en cómo evaluar una software house; casi cada señal de esa lista mapea a costo.

Ritmo: qué tan fuerte te está apretando el calendario

El calendario es la variable más barata de mover y la que los founders más se resisten a mover. Comprimir un build de seis meses en tres meses no corta el costo a la mitad. Lo duplica aproximadamente, porque los builds comprimidos requieren más gente en paralelo, más overhead de coordinación, más rework cuando dos branches paralelas chocan, y más tiempo senior por hora.

Lo contrario también es cierto. Un equipo que puede construir a un ritmo estable durante seis meses va a cotizar un total más bajo que el mismo equipo corriendo un sprint para entregar antes de tu demo de inversionistas. Si tienes flexibilidad en la fecha, esa flexibilidad vale dinero real. Si no la tienes, la cotización va a reflejar el apretón, y un equipo que te dio el número de ritmo calmado va a entregar un producto distinto (peor) cuando el martes le digas que lo necesitas el viernes.

Rangos realistas por etapa

Con los seis drivers en mano, los rangos siguientes pasan a ser útiles en vez de engañosos. Siguen siendo rangos. Los drivers de arriba te dicen dónde dentro de cada rango caes.

Esbozo / prototipo para mostrar, no para usar. US$ 5.000 a US$ 20.000. Un build no-code (Bubble, Glide, FlutterFlow), o una app React muy templada, o un Figma clickeable. Demuestra. No sobrevive a un usuario real. Úsalo para fundraising, para alineación interna, o para una carta de intención de cliente. No lo uses como base de tu producto real, y no dejes que un estimador te prometa que sí.

MVP real que dos clientes reales pueden usar. US$ 35.000 a US$ 120.000. Tres a siete integraciones. Dos a tres roles de usuario. Compliance todavía leve. Ocho a veinte flows. Un equipo de dos a tres ingenieros durante tres a cinco meses. Es la forma más común de un engagement de Pixel Breeders, y donde la varianza es más amplia, porque los seis drivers dejan de ser abstractos y empiezan a producir horas reales.

V1 post-lanzamiento con clientes pagos y un backlog real. US$ 150.000 a US$ 400.000+ durante el primer año. El build del MVP más las diez cosas que los clientes piden en los primeros noventa días que no podrías haber predicho. El pedido de SSO de tu primer piloto enterprise. El rebuild de la cola que conectaste demasiado rápido durante el MVP. El analytics que decidiste saltar. Los founders que solo alcanzan al MVP y no a “MVP más el primer año de realidad” vuelven preguntando por qué los segundos seis meses costaron lo mismo que los primeros.

Estos rangos asumen un equipo competente, un alcance honesto y el mercado de Estados Unidos o Europa Occidental. Brasil, Europa del Este y América Latina cortan la parte de costo del equipo aproximadamente a la mitad sin cortar calidad, si encuentras un equipo real. El arbitraje geográfico funciona, pero los peores proyectos que hemos escuchado empezaron con “encontramos un equipo en [país] por la mitad del precio”.

El diagnóstico de cinco preguntas que pone a prueba una cotización

Cuando llegue una cotización, haz las cinco preguntas que siguen antes de comparar dos cotizaciones entre sí. El diagnóstico separa estimaciones reales de teatro de venta. Un estimador real responde sin titubear. Un cálculo a ojo produce respuestas vagas, lenguaje defensivo o “lo vamos a ir descubriendo juntos”.

1. ¿Qué alcance asumieron, en flows? No features. Flows. Si no pueden listar diez o veinte flows por nombre, no estimaron; pusieron precio a tus wireframes.
2. ¿Qué integraciones están dentro de la cotización y cuáles están explícitamente fuera? Una cotización real tiene una lista. Un cálculo a ojo dice “manejamos las integraciones según vayan apareciendo”.
3. ¿Quién exactamente va a estar en este equipo? No la experiencia colectiva de la empresa. Las tres personas reales que van a escribir el código, con su LinkedIn o GitHub. Un equipo real entrega los nombres. Un equipo bait-and-switch no.
4. ¿Cuáles son los tres mayores riesgos que ven en este alcance? Este es el diagnóstico que más atrapa. Un estimador senior nombra tres riesgos en quince segundos. Uno junior o deshonesto dice “ningún riesgo grande, ya hicimos esto antes”.
5. ¿Cómo se ve el séptimo mes si los contratamos? Esta pregunta los obliga a pensar más allá del build, hacia el mantenimiento, los pedidos inevitables de features, los bugs que aparecen en producción. Un equipo que solo pensó en el build te va a cobrar dos veces por esa conversación más adelante.

Si una cotización responde las cinco bien y cuesta el doble que una cotización que no responde ninguna, la más cara es la más barata en doce meses.

Dónde los founders queman más dinero

Vimos los mismos tres errores drenar presupuestos durante años. Ninguno de ellos es sobre la tarifa por hora.

Construir la app que imaginaste en lugar de la app que tus clientes van a usar. La forma más rápida de gastar US$ 80.000 que no necesitabas gastar es entregar el producto que está en tu cabeza y descubrir, después del lanzamiento, que los clientes quieren otra cosa. La cura es poner la versión más pequeña posible delante de tres clientes reales antes del build, no después. Hemos escrito sobre por qué la mayoría de los llamados MVPs no son MVP, y el principio se mantiene para el costo: la feature más barata es la que no construyes.

Ahorrar en el equipo y pagarlo de vuelta en rework. El freelancer que cuesta US$ 25 por hora y produce código que el siguiente equipo reescribe desde cero no te ahorró dinero. Te costó el build dos veces, más el tiempo perdido entre rondas. La mano de obra barata en trabajo de ingeniería es la forma más confiable de pagar de más.

Elegir el contrato que deja que la baratura se esconda. Una cotización fixed-price sobre un alcance mal definido crea el incentivo para que el equipo recorte en todo lo que no escribiste. Una cotización puramente time-and-materials sobre un brief vago crea el incentivo para que el trabajo se expanda. La forma del contrato importa tanto como el monto. Desarmamos los trade-offs en precio cerrado vs tiempo y materiales; elige la estructura que deje a tu equipo ser honesto contigo.

Qué preguntar antes de firmar

Pon las tres cosas siguientes en el contrato.

Una lista de los flows que la cotización cubre, y la declaración explícita de que cualquier cosa fuera de esa lista es un change request. Esto protege a las dos partes. El equipo no queda atado a cosas que no fueron estimadas. Tú no te sorprendes cuando “nos hacemos cargo del panel admin” se convierte en una adición de US$ 30K.

Una demo semanal de software funcionando, no slides, no screenshots. Si el equipo no puede mostrarte una versión corriendo de lo que construyeron esa semana, no lo construyeron esa semana. La demo es la forma más barata de project management que vas a comprar.

Una estructura de pago por hitos atada a esas demos. No “33% al inicio, 33% a la mitad, 33% al final”. Algo más cercano a “5% al inicio, después un pago tras cada quincena de demo funcionando”. El equipo cobra por entregar. Tú dejas de pagar si las demos paran.

El costo de desarrollar una app es el costo de esas decisiones, bien o mal tomadas, multiplicado por el tiempo que un equipo competente necesita para ejecutarlas. El número no es aleatorio. Es el resultado de seis drivers que puedes nombrar, tres cláusulas de contrato que puedes escribir, y una conversación diagnóstica que puedes tener antes de firmar. Los founders que se saltan la conversación la pagan más adelante. Los que la tienen pagan aproximadamente lo que la app debería haber costado, y terminan con la app que de verdad pretendían construir.

Esa es la respuesta a la pregunta original. No un rango. Un método.

FAQ

¿Puedo construir una app gratis?
Puedes construir un esbozo gratis con Bubble, Glide, o alguna herramienta no-code. No puedes construir un negocio así. La versión gratis demuestra. No sobrevive a usuarios reales, escala, integraciones o customización significativa. Trata el build gratis como herramienta de fundraising y validación, después planifica un build real cuando la demanda esté probada.

¿Por qué los rangos de costo que veo online son tan amplios?
Cada rango colapsa seis drivers independientes en un número. Una app de US$ 20K y una app de US$ 200K pueden tener la misma cantidad de pantallas, la misma descripción y el mismo objetivo de negocio. Los drivers de este artículo son cómo conviertes un rango en un número para tu app.

¿Cuánto tiempo lleva desarrollar una app?
Un MVP real con clientes pagos lleva de tres a seis meses con un equipo de dos a tres ingenieros. Quien promete menos está construyendo un prototipo, recortando alcance sin avisarte, o a punto de entregar algo que se rompe. Quien cotiza doce meses está sobreconstruyendo o subdimensionando el equipo en silencio.

¿Cuál es la forma más barata de validar una idea de app antes de construir?
Una landing page, un video demo y tres conversaciones lideradas por el founder con clientes potenciales validan más en dos semanas que tres meses construyendo. La mayoría de los founders se saltan este paso y descubren después del build que la demanda que asumieron no estaba ahí en la forma que pensaban.