"Qué incluye un presupuesto de app: guía antes de firmar nada"

Un presupuesto de app serio no es una cifra con un plazo de entrega: es un documento que deja escrito qué se va a construir, en qué fases, qué queda fuera y cómo se paga. Si solo recibes un número y una fecha, te falta la mitad de la información que necesitas para decidir. Saber qué debe incluir ese documento te permite comparar propuestas de verdad, en lugar de comparar solo cifras sueltas.

Esto importa especialmente al principio, cuando todavía no tienes claro si la idea es grande o pequeña. Un presupuesto bien hecho no solo te dice cuánto, sino qué exactamente vas a recibir por ese importe, y eso es lo que de verdad te protege de sorpresas a mitad de proyecto. Puedes ver qué tipo de aplicaciones a medida suelen encargarse para hacerte una idea del rango de proyectos que hay detrás de una app.

Qué debería incluir siempre un presupuesto de app

Un presupuesto que se toma en serio tu proyecto suele incluir estos bloques, como mínimo:

• El alcance de la primera versión, descrito con funcionalidades concretas, no con frases genéricas como "app completa de gestión". Si no reconoces tu idea en la lista, algo no está bien definido todavía.
• Las fases del proyecto: normalmente descubrimiento y definición, construcción del MVP, lanzamiento y, después, evolución. Cada fase con lo que incluye y lo que entrega.
• Quién usa la app y con qué permisos: no es lo mismo un único tipo de usuario que administradores, clientes y colaboradores viendo cosas distintas.
• Las integraciones previstas: pagos, mensajería, facturación, calendarios u otros sistemas con los que la app tiene que hablar.
• La forma de pago, normalmente repartida en hitos ligados a entregas concretas, no todo por adelantado ni todo al final.
• A nombre de quién quedan las cuentas y el código al terminar: dominio, hosting, pasarela de pago, repositorio. Esto condiciona tu independencia real frente al proveedor.
• Qué pasa después del lanzamiento: si incluye algún nivel de mantenimiento o no, y qué diferencia hay entre mantener lo que ya existe y construir funcionalidades nuevas.

Un ejemplo ayuda a verlo aplicado: si tu idea es un sistema de reservas para un negocio de servicios, el presupuesto debería dejar claro si el MVP incluye solo calendario y confirmaciones, o también pagos por adelantado y sincronización con tu facturación. Esa diferencia cambia el alcance, y con él, lo que firmas.

Qué debe quedar fuera (y por qué es buena señal)

Un presupuesto honesto no solo dice qué incluye: también dice qué no incluye todavía. Esto parece una debilidad, pero es justo lo contrario. Significa que alguien se ha tomado el tiempo de separar lo imprescindible de lo que puede esperar, en vez de prometerte todo de golpe para cerrar la venta.

Es razonable que el documento mencione explícitamente funcionalidades que se han dejado fuera del alcance inicial, y que queden anotadas para una fase posterior de evolución. También es razonable que el presupuesto no fije una fecha de entrega exacta y cerrada: puede dar una previsión de tiempos, pero comprometerse a un día concreto sin margen suele acabar en recortes de alcance que no te cuentan, para cumplir esa fecha como sea.

Tampoco debería incluir, mezclados con el desarrollo, los costes de terceros que no dependen del estudio: hosting, dominio y las APIs externas que use la app. Lo razonable es que esos costes recurrentes los pague directamente el cliente, con las cuentas a su nombre, y que el presupuesto te avise de ellos antes de que se active cualquier plan de pago.

Cómo se reparte el pago: hitos, no todo de golpe

La forma de pago es una de las partes del presupuesto que más dice sobre cómo trabaja quien te lo envía. Lo habitual, y lo más sano para ambas partes, es repartir el pago en hitos: un primer pago al arrancar el proyecto, otros ligados a entregas concretas (por ejemplo, al terminar el diseño de pantallas o al lanzar el MVP), y el resto al finalizar.

Este reparto tiene una ventaja clara para ti: si algo no avanza como se esperaba, no has adelantado todo el dinero sin nada que mostrar a cambio. Y tiene otra ventaja menos evidente: obliga a que el alcance esté bien dividido en entregas reconocibles, lo que a su vez ayuda a que el presupuesto inicial sea más fiable, porque cada hito es más fácil de calcular que el proyecto entero de una sola vez.

Si un presupuesto pide todo el importe por adelantado, o al revés, todo al final sin ningún hito intermedio, merece la pena preguntar por qué. No es automáticamente una señal mala, pero sí una pregunta que conviene hacer antes de firmar.

Señales de alerta en un presupuesto

Algunas cosas que conviene mirar con lupa antes de aceptar una propuesta:

1. Un número sin preguntas previas. Si nadie te ha preguntado por tus usuarios, tus integraciones o si la app mueve pagos, el presupuesto está adivinando, no calculando.
2. Alcance descrito en una sola frase genérica. "Desarrollo de app a medida" no te dice nada sobre qué vas a recibir. Pide que se detalle por funcionalidades.
3. Silencio sobre quién es propietario de las cuentas y el código. Si el documento no lo menciona, pregúntalo directamente antes de avanzar.
4. Ningún hito de pago intermedio. Todo por adelantado traslada el riesgo entero a tu lado.
5. Ninguna mención a qué pasa después del lanzamiento. Un proyecto que se queda sin mantenimiento ni evolución definida suele generar sorpresas meses después.

Ninguna de estas señales significa automáticamente que debas rechazar la propuesta, pero sí que merece la pena pedir que se aclare antes de dar el siguiente paso.

Si estás reuniendo información para pedir presupuesto y no sabes todavía cómo explicar tu idea con suficiente detalle, lo más práctico es contarla tal cual la tienes, aunque no esté cerrada del todo, en cuéntanos tu idea. A partir de esa conversación se puede definir el alcance de un primer MVP y dar una horquilla ajustada a tu caso concreto, no a una media genérica. Puedes ver con más detalle de qué depende esa horquilla en cuánto cuesta hacer una app.

Si quieres ver el perfil de tu proyecto antes de pedir una propuesta, prueba la calculadora de presupuesto.

Preguntas frecuentes

¿Un presupuesto de app debe incluir una fecha de entrega fija?

Puede incluir una previsión de tiempos, pero comprometerse a una fecha exacta y cerrada sin margen suele terminar en recortes de alcance no comunicados para cumplirla. Es más fiable un presupuesto por fases, donde cada entrega tiene su propio hito.

¿Por qué el presupuesto no incluye el hosting ni el dominio?

Porque son costes de terceros que conviene que pague directamente el cliente, con las cuentas a su nombre. Un presupuesto serio te informa de ellos aparte, no los esconde dentro del precio del desarrollo.

¿Qué significa que el presupuesto venga dividido en hitos?

Que el pago se reparte en varios momentos, ligados a entregas concretas del proyecto, en lugar de cobrarse todo por adelantado o solo al terminar. Así el riesgo se reparte entre las dos partes, no solo en la tuya.

¿Qué debo pedir si el presupuesto no detalla el alcance?

Pide que se liste por funcionalidades, no por frases genéricas, y que quede claro qué queda fuera de la primera versión. Si tienes dudas sobre cómo debe quedar recogido por escrito, conviene revisarlo con un profesional antes de firmar.