Cuánto cuesta desarrollar una app y por qué cotizo precio fijo

Cuánto cuesta desarrollar una app, una plataforma web o un chatbot con IA es la primera pregunta que recibe cualquier persona que construye productos digitales, y la que peor se responde. Aquí no vas a encontrar un monto, porque no existe antes de definir qué se construye; vas a encontrar lo que sí se puede saber antes: de qué depende, cuántas semanas suele tomar y cómo leer una cotización. La respuesta honesta es “depende del alcance”, que suena a evasiva hasta que entiendes de qué depende exactamente. En este artículo explico las variables que mueven el precio, por qué no doy un número antes de definir qué se va a construir, y cómo funciona mi cotización: un precio fijo por escrito para la primera versión, por hora para el trabajo que no se puede acotar. La idea es que puedas leer cualquier cotización, la mía o la de otro, y saber qué te están vendiendo.

Resumen para perezosos

• El precio de un producto digital depende de cuántos flujos tiene, qué backend necesita, con qué servicios se integra, si se publica en tiendas y si incluye IA. No de la tecnología con que se escribe.
• Un número dado antes de definir el alcance es una adivinanza. Por eso el primer paso es una llamada de 30 minutos y una propuesta escrita, sin costo si decides no avanzar.
• Cotizo precio fijo para la primera versión porque el alcance ya se definió y el riesgo de equivocarme al estimar es mío. La auditoría y el mantenimiento van por hora, porque ahí el alcance no se puede cerrar de antemano.

En este artículo:

• Fundamentos — De qué depende el precio · Por qué no doy un número sin alcance · Precio fijo o por hora
• El proceso — Cómo se llega a la cotización · Qué incluye y qué no · Cuando cambia el alcance
• Comparar — Cómo comparar cotizaciones · Qué encarece un proyecto

Cuánto cuesta desarrollar una app: de qué depende el precio

El precio de un producto digital es, en su mayor parte, tiempo de una persona con criterio. Lo que hace que ese tiempo crezca es la cantidad de cosas distintas que el producto tiene que hacer bien. Estas son las variables que miro antes de cotizar cualquier proyecto, y que explican casi toda la diferencia entre una cotización y otra:

Variable	Qué la hace crecer	Ejemplo
Flujos y pantallas	Cada recorrido completo que un usuario puede hacer	Registrarse, buscar, reservar y pagar son cuatro flujos, no una app
Backend y datos	Si hace falta un servidor propio, una base de datos y reglas de negocio	Un catálogo que se lee es barato; un inventario que varias personas editan a la vez no
Integraciones	Cada servicio externo con el que hay que hablar	Pagos, notificaciones push, mapas, correo, facturación, un sistema que ya tienes
Publicación	Si el producto va a las tiendas de aplicaciones	Cuentas, revisión de Apple y Google, firma, y volver a pasar por ahí en cada versión
IA	Si un modelo de lenguaje responde a usuarios reales	Hay que evaluarlo antes de exponerlo, y decidir qué hace cuando se equivoca
Diseño	Si existe un diseño en Figma o hay que definir la interfaz	Construir sobre un diseño cerrado es más rápido que decidirlo mientras se programa
Lo que ya existe	Si se parte de cero o de un producto en uso	Un producto heredado se cotiza después de leerlo, no antes

Dos de esas filas suelen sorprender. La primera es la publicación en tiendas: la revisión de Apple y Google es un trabajo con sus propios tiempos y rechazos, y se repite con cada versión. La segunda es la IA: un chatbot que responde bien en la demo y mal frente a un cliente real es peor que no tener chatbot, y evitar eso cuesta tiempo de evaluación que no se ve en la interfaz.

Lo que no mueve el precio, o lo mueve mucho menos de lo que se cree, es la lista de tecnologías. Que la app se escriba en React Native o en Swift cambia decisiones importantes, pero no cambia que registrarse, buscar, reservar y pagar son cuatro flujos que hay que construir y probar.

Lo que sí puedo decir antes de la llamada son los rangos que salen de mi propio trabajo. Una primera versión enfocada de una app móvil o una plataforma web, con un flujo principal, datos reales y una interfaz cuidada, suele tomar entre 4 y 8 semanas de trabajo a tiempo completo. Una funcionalidad de IA sobre un producto que ya existe, como un chatbot con RAG o un flujo de generación, suele salir en 2 a 5 semanas. Productos más grandes, como una plataforma de streaming o de salud, se planifican por fases y cada fase se cotiza por separado. Esas semanas son lo que se cotiza: el precio de la propuesta es ese tiempo, cerrado por escrito, y con cualquier tarifa de mercado que conozcas puedes sacar un orden de magnitud antes de escribirme.

Por qué no te doy un número antes de definir el alcance

Cuando alguien me escribe con “quiero una app como X, ¿cuánto cuesta?”, la respuesta correcta no es un número, y no por estrategia comercial. Es porque el número todavía no existe. “Una app como X” describe un producto que a su dueño le tomó años y varios equipos; la pregunta útil es cuál es la parte de X que tu negocio necesita en los primeros meses, y esa parte solo la podemos definir hablando.

Un número dado antes de esa conversación tiene un solo origen posible: alguien lo adivinó. Y las adivinanzas en cotizaciones tienen una propiedad conocida: cuando son bajas, el proyecto las corrige después con retrasos, discusiones o funcionalidades que desaparecen sin aviso. En la auditoría de un producto heredado escribí lo mismo desde el otro lado: nadie puede cotizar de verdad un código que no ha leído.

Precio fijo o por hora: cuándo uso cada uno

No cobro todo de la misma forma, y el criterio para elegir es uno solo: si el alcance se puede cerrar antes de empezar, el precio se puede cerrar también. Si no, cobrar un precio fijo sería fingir una certeza que no tengo.

Tipo de trabajo	Cómo se cobra	Por qué
Primera versión de un producto (app, plataforma, chatbot)	Precio fijo, dividido en hitos	El alcance se definió antes; el riesgo de estimar mal es mío, no tuyo
Auditoría de un producto heredado	Por hora, acotado a una semana	No sé qué voy a encontrar hasta leerlo; lo que sí se acota es el tiempo
Mantenimiento y evolución después del lanzamiento	Por hora, dentro de un acuerdo mensual con un límite semanal que fijas tú	El trabajo depende de lo que pase con usuarios reales, y eso no se conoce por adelantado

El precio fijo tiene una consecuencia que conviene entender: si me equivoqué estimando y la primera versión toma más tiempo del previsto, ese costo lo asumo yo. Por eso la fase de definir el alcance existe y por eso la tomo en serio: es lo que permite que el precio no cambie. Ese precio incluye el costo de asumir el riesgo; es más alto que la suma de horas si todo saliera perfecto, y a cambio no cambia si no sale perfecto. Y por eso la cotización por hora no es peor ni mejor: es la forma correcta de cobrar cuando el trabajo, por su naturaleza, no se puede acotar antes de empezar.

Cuando el contrato pasa por Upwork, esta división existe ya en la plataforma: contratos de precio fijo con el dinero en custodia por hito, y contratos por hora con registro y límite semanal. Lo explico en por qué contratar por Upwork protege al cliente.

Cómo se llega a la cotización en diez días

Este es el recorrido desde tu primer mensaje hasta la primera semana de trabajo, en el orden en que ocurre:

La llamada del día 3 es la que decide cuánto termina costando el proyecto. Es el momento en que decidimos qué no construir todavía, y esa es la decisión que más ahorra, como expliqué en qué es un ingeniero de producto.

La cotización que llega sin la llamada no tiene de dónde haber sacado el alcance: el número lo puso quien la escribió, no el producto.

La propuesta del día 5 es el mismo documento que después se convierte en el cronograma compartido. Los hitos que aparecen ahí, con sus fechas, son los que marco cada semana como cumplidos o movidos, y si algo se movió escribo por qué.

Qué incluye la cotización y qué no

Una cotización fija solo sirve si está claro qué compra. Lo que incluye la mía para una primera versión:

• El producto funcionando y publicado. La app en las tiendas o la plataforma en línea, no un repositorio que “solo falta desplegar”.
• Una entrega que puedes abrir cada viernes. Una build en tu teléfono o una URL, con una nota de avance en lenguaje claro. En cómo trabajo describo esa semana.
• Ingeniería completa. Pruebas, revisión de código e integración continua vienen incluidas; son lo que evita que la versión dos cueste el doble. Con precio fijo, la tentación del proveedor es recortar donde no se ve; la demo de cada viernes y las pruebas incluidas son lo que hace visible ese recorte.
• Todo a tu nombre. El repositorio en tu cuenta de GitHub, las cuentas de las tiendas, del dominio y del hosting a tu nombre, y documentación suficiente para que otro desarrollador continúe.

Lo que no incluye, y que conviene tener en cuenta antes de comparar:

• Los costos de terceros. La cuenta de desarrollador de Apple tiene un costo anual y la de Google uno único; el hosting, la base de datos, el envío de correos, los mapas y las llamadas a modelos de IA se pagan al proveedor, a tu nombre, según el uso. En la propuesta los enumero para que no aparezcan como sorpresa, pero no pasan por mí.
• El contenido y la marca. Los textos, las fotos, el logo y la identidad visual son tuyos o de un diseñador. Yo construyo sobre eso.
• Lo que quedó fuera del alcance. Todo lo que en la llamada decidimos dejar para después queda fuera, por escrito; ese recorte es lo que permite cerrar el precio.

Qué pasa cuando cambia el alcance a mitad del proyecto

Un cambio de alcance a mitad del proyecto se maneja por escrito, en la reunión semanal, y termina en una de tres situaciones según su tamaño. Va a pasar: un producto se entiende mejor cuando se puede abrir, y la demo de cada semana produce ideas que la llamada inicial no podía producir. Que el precio sea fijo no congela el alcance; obliga a que los cambios queden registrados en lugar de absorberse en silencio.

Las tres situaciones:

El cambio	Qué pasa con el precio y el cronograma
Es un detalle dentro de lo acordado: un texto, un color, el orden de una pantalla	Entra sin costo, en la semana en curso o la siguiente
Sustituye algo de tamaño parecido que aún no se construyó	Se intercambia, queda en el acta de la reunión y las fechas se mantienen mientras el tamaño sea de verdad parecido; si no lo es, pasa a la fila siguiente
Es nuevo y suma trabajo: una pantalla, una integración, un rol de usuario	Se cotiza como hito adicional y tú decides si entra ahora, después del lanzamiento o nunca

La tercera fila es la que evita las dos formas conocidas de arruinar un proyecto de precio fijo: que el desarrollador acepte todo y el cronograma se desarme, o que rechace todo y el producto salga sin lo que aprendiste en el camino. La reunión semanal es donde esa decisión se toma, con la demo delante, y el acta de tres líneas es donde queda registrada. Y si en algún punto quieres parar, el corte natural es el final de un hito: lo entregado ya es tuyo y lo que no se empezó no se paga.

Cómo comparar cotizaciones que no se parecen

Si pediste tres cotizaciones y llegaron con números muy distintos, lo más probable es que no cotizaran lo mismo. Antes de comparar precios, compara esto:

1. ¿Sobre qué alcance se cotizó? Si no hay un documento con los flujos que entran y los que no, cada proveedor imaginó un producto diferente. Pide que coticen sobre el mismo texto.
2. ¿Qué incluye “terminado”? Publicado en tiendas, con pruebas, con las cuentas a tu nombre, o “listo para desplegar”. Son cuatro precios distintos.
3. ¿Cómo se maneja un cambio? Si la respuesta es vaga, el precio fijo va a dejar de serlo en la semana tres.
4. ¿Qué pasa si toma más tiempo del previsto? Con precio fijo, ese riesgo es del proveedor. Si la cotización es “estimada” o “aproximada”, el riesgo es tuyo y el número es, en la práctica, una tarifa por hora que no se dice. Si además el contrato pasa por Upwork, tu dinero queda en custodia por hito y solo se libera cuando apruebas la entrega; en por qué contratar por Upwork protege al cliente explico cómo funciona esa protección.
5. ¿Cuántas personas hay entre tú y quien escribe el código? Cada intermediario cuesta, en dinero y en decisiones que llegan tarde.

Sobre comparar por hora: la tarifa por hora es la forma más fácil de comparar y la que menos dice. Alguien que cobra menos por hora y necesita el doble de horas, o que construye lo que no hacía falta, sale más caro. La comparación que sirve es el costo del proyecto entero: incluye las horas que no hicieron falta porque algo no se construyó, y las que no hubo que repetir.

Qué hace que un proyecto salga más caro de lo cotizado

Con precio fijo, lo que sube el costo no es el tiempo que me toma a mí, es lo que se agrega al alcance. Y casi siempre se agrega por alguna de estas razones, todas evitables:

• Nadie puede decidir en 48 horas. Cada semana necesita decisiones pequeñas, y si esperan a que se reúna un comité, el cronograma se mueve y el producto se llena de suposiciones que después hay que deshacer. Por eso pido una persona con poder de decisión desde el inicio.
• Los accesos llegan tarde. Cuentas de tiendas, dominios, un sistema que hay que integrar. Si se crean en la semana cuatro, la semana cuatro se pierde.
• Todo tiene que entrar en la primera versión. Es la razón más común y la más cara. Cada flujo que se suma en la llamada inicial se cotiza, pero cada flujo que se suma “porque ya que estamos” se cotiza aparte, con el cronograma en marcha, y cuesta más porque interrumpe lo que ya estaba planificado.
• El contenido no está listo. Textos, imágenes, datos reales. Una app sin sus datos no se puede probar de verdad, y probar con datos inventados esconde los problemas que después aparecen en producción.
• Se hereda algo que nadie leyó. Si el producto parte de un código existente, cotizarlo sin auditarlo primero es la forma más segura de equivocarse. Por eso la auditoría va antes y por hora.

Ninguna de esas causas está en la parte técnica. Están en la organización del proyecto, y es donde un cliente tiene más control del que cree sobre lo que finalmente paga.

Preguntas frecuentes

¿Cuánto cuesta desarrollar una app móvil?

El costo de desarrollar una app móvil depende del alcance: cuántos flujos tiene, si necesita backend propio, con qué servicios se integra y si va a las tiendas. Una primera versión enfocada, con un flujo principal, datos reales y una interfaz cuidada, suele tomar entre 4 y 8 semanas de trabajo a tiempo completo, y el precio se cotiza por proyecto después de una llamada de 30 minutos que define ese alcance. Nadie puede dar un número serio antes de esa conversación, porque el producto que hay que cotizar todavía no está definido.

¿Por qué cobras precio fijo y no por hora?

Cobro precio fijo en la primera versión porque el alcance se define antes de empezar y, una vez definido, el riesgo de estimar mal debe ser del proveedor, no del cliente. Con precio fijo, si el trabajo toma más de lo previsto, ese costo lo asumo yo. Cobrar por hora un alcance ya cerrado traslada ese riesgo al cliente sin darle nada a cambio. Por hora cobro solo lo que no se puede acotar por adelantado: la auditoría de un producto heredado y el mantenimiento después del lanzamiento.

¿Qué pasa si el proyecto toma más tiempo del cotizado?

Si el alcance no cambió, el precio tampoco: el tiempo adicional es mi costo. Si el alcance cambió porque agregaste algo nuevo, ese cambio se cotizó como hito adicional en el momento en que lo pediste, por escrito, y decidiste si entraba. Lo que no ocurre es que el precio suba al final por razones que nadie registró durante el proyecto.

¿La cotización tiene costo?

No. La llamada de 30 minutos y la propuesta escrita con alcance, hitos, fechas y precio son parte de decidir si trabajamos juntos, y si decides no avanzar no te cuestan nada. Lo que sí tiene costo, y va por hora, es la auditoría de un producto que ya existe, porque ahí la cotización requiere leer el código y eso es trabajo real de una semana.

¿Puedo pagar por partes?

Sí: el precio fijo se paga por hitos de una o dos semanas, cada uno con una entrega que puedes abrir y probar antes de aprobarlo. Si el contrato pasa por Upwork, el dinero de cada hito queda en custodia hasta que apruebas la entrega; si es directo, el pago de cada hito se hace contra la misma entrega. En los dos casos, lo que apruebas en el hito es lo que ya viste funcionando en la demo semanal.

¿Qué costos no están en la cotización?

Los que se pagan a terceros según el uso y a tu nombre: la cuenta de desarrollador de Apple y la de Google, el hosting, la base de datos, el envío de correos, los mapas, los pagos y las llamadas a modelos de IA. También el contenido y la marca: textos, imágenes, logo e identidad visual. En la propuesta enumero los servicios que el producto va a necesitar para que no aparezcan como sorpresa, pero se contratan directamente contigo como titular.

Conclusión

El precio de un producto digital sale de su alcance, y el alcance no existe hasta que alguien con criterio técnico lo define contigo. Por eso una cotización seria empieza con una conversación y termina con un documento, y por eso el precio fijo es posible: no porque el trabajo sea predecible, sino porque el riesgo de estimarlo mal queda del lado de quien tiene la información para estimarlo. Lo que no se puede acotar de antemano, como leer un código ajeno o mantener un producto en uso, se cobra por hora, y decirlo con claridad es parte de cotizar bien.

Si estás por pedir cotizaciones, haz esto en orden: escribe en una página qué tiene que hacer la primera versión y qué puede esperar, aunque te salga incompleto; pide que todas las cotizaciones se hagan sobre ese mismo texto; pregunta en cada una qué incluye “terminado”, cómo se maneja un cambio y quién asume el riesgo si toma más tiempo. Con el mismo alcance y esas tres respuestas, los números que antes no se parecían empiezan a compararse. Y si quieres empezar por la conversación, cómo trabajo describe qué pasa desde tu primer mensaje hasta la propuesta.