TL;DR: El error más caro al pedir un presupuesto de app es elegir el más barato sin entender qué incluye. Los presupuestos no son comparables si no cotizaron lo mismo. Antes de decidir, verificá qué fases incluye (discovery, diseño, testing), quién hace el trabajo, cómo se manejan los cambios de scope y cuál es el costo de operación mensual después del lanzamiento.
Errores al pedir presupuesto de app: cómo no desperdiciar tu dinero
Después de revisar cientos de presupuestos de desarrollo de apps y hablar con decenas de dueños de pymes que pasaron por proyectos complicados, identificamos los patrones de error que se repiten. Esta guía es lo que hubiéramos querido que leyeran antes de empezar.
Puntos clave
- Los presupuestos de app que no desglosan por fase son casi imposibles de comparar
- Elegir el proveedor más barato sin entender el scope es la causa número uno de proyectos fallidos
- Un presupuesto sin costo de mantenimiento post-lanzamiento está incompleto
- La forma en que un proveedor maneja los cambios de scope te dice mucho de cómo va a ser trabajar con él
- El brief que mandás determina la calidad del presupuesto que recibís
Error 1: Pedir presupuesto sin un brief claro
El presupuesto que recibís es tan bueno como el brief que enviaste. Si describís tu app en una oración ("quiero algo como Rappi pero para veterinarias"), el proveedor va a suponer el 80% de los detalles — y esas suposiciones van a ser diferentes para cada uno.
Resultado: Recibís presupuestos completamente distintos que no podés comparar porque cada uno cotizó algo diferente.
Cómo evitarlo:
- Describí los flujos principales (qué hace el usuario paso a paso)
- Listá las pantallas que sí o sí tiene que tener la primera versión
- Indicá a cuántos usuarios simultáneos tiene que soportar
- Especificá si necesitás integraciones con sistemas externos (pagos, AFIP, GPS)
- Aclará si es solo para iOS, solo Android o ambos
💡 Consejo
Invertí 2–3 horas en escribir un brief detallado antes de salir a pedir presupuestos. Ese tiempo te va a ahorrar semanas de idas y vueltas y te va a permitir comparar presupuestos reales entre sí.
Error 2: Comparar presupuestos que no cotizaron lo mismo
Recibís tres presupuestos: USD 8.000, USD 18.000 y USD 35.000. La tentación es ir al del medio "porque parece razonable". Pero el de USD 8.000 puede que no incluya diseño UX/UI, el de USD 35.000 puede que incluya discovery, diseño, testing y soporte por 6 meses.
Lo que hay que verificar que incluye cada presupuesto:
| Fase | ¿Está incluida? | Si no: ¿cuánto cuesta aparte? |
|---|---|---|
| Discovery / relevamiento de procesos | Preguntar | USD 1.500 – 5.000 |
| Diseño UX (wireframes, flujos) | Preguntar | USD 2.000 – 6.000 |
| Diseño UI (visual, sistema de diseño) | Preguntar | USD 1.500 – 4.000 |
| Desarrollo front-end | Generalmente sí | — |
| Desarrollo back-end + API | Preguntar | USD 5.000 – 15.000 |
| Testing y QA | No siempre | USD 1.500 – 4.000 |
| Deploy en tiendas (App Store / Google Play) | No siempre | USD 500 – 1.500 |
| Capacitación del equipo | Raro que lo incluyan | USD 500 – 2.000 |
| Soporte post-lanzamiento (30–90 días) | Varía | USD 500 – 2.000 |
Error 3: Elegir al más barato sin evaluar el equipo
Un presupuesto de USD 8.000 puede ser una muy buena oferta de un freelancer senior con 10 años de experiencia — o puede ser alguien que subcontrata a juniors offshore y vos sos el que va a tener que lidiar con el código resultante.
Preguntas para hacer antes de elegir:
- ¿Quiénes van a trabajar en mi proyecto? (No el equipo del proveedor en general, sino específicamente en este proyecto)
- ¿Puedo ver código que hayan escrito antes?
- ¿Podés hablar con 2–3 clientes anteriores del proveedor?
- ¿Tienen experiencia en la industria de mi negocio?
- ¿Trabajás con un equipo dedicado o compartido con otros proyectos?
⚠️ Atención
Los portfolios de sitio web no son suficientes. Pedí ver repositorios de GitHub o, si el código es privado, hacé una reunión técnica donde alguien de tu equipo (o un consultor externo) pueda hacer preguntas específicas sobre el código y la arquitectura.
Error 4: No preguntar cómo se manejan los cambios de scope
Esta es la pregunta más importante que podés hacer y la que menos dueños de pymes hacen. Los cambios de scope son inevitables — lo que varía es cómo los maneja el proveedor.
Situaciones posibles:
- Precio fijo estricto: Lo que se acordó en el presupuesto es lo que se hace. Todo cambio es una nueva cotización. Predecible pero rígido.
- Time & materials: Se cobran las horas de trabajo al precio acordado. Flexible pero el costo final es incierto.
- Scrum con backlog priorizado: Se trabaja por sprints, el cliente puede cambiar prioridades entre sprints. El costo por sprint es fijo pero el total depende de cuántos sprints se necesiten.
Ninguna es perfecta. Lo que importa es que el proveedor lo tenga claro y pueda explicártelo. Si la respuesta es vaga o evasiva, es una señal.
Error 5: Ignorar el costo de operación después del lanzamiento
El presupuesto de desarrollo es un costo único. Pero después del lanzamiento hay costos recurrentes que van a aparecer sí o sí:
- Hosting en la nube: USD 50 – USD 500/mes
- Mantenimiento correctivo (bugs que aparecen): USD 200 – USD 1.000/mes
- Adaptación a nuevas versiones de iOS/Android: USD 500 – USD 2.000 dos veces por año
- Nuevas funcionalidades: según demanda
Un proveedor que te da un presupuesto sin mencionar el costo post-lanzamiento te está dejando una sorpresa para después. Preguntá explícitamente: "¿Qué pasa después del lanzamiento? ¿Cuánto me va a costar mantener esto?"
Error 6: No pedir referencias ni ver proyectos similares
Un proveedor que hizo 10 apps de e-commerce puede ser la elección perfecta para una app de e-commerce — y la elección equivocada para una app de logística con GPS en tiempo real. La experiencia en el tipo específico de proyecto importa mucho.
Pedí:
- Ejemplos de apps similares a la tuya que hayan desarrollado
- Contacto de 2–3 clientes para llamar y preguntar cómo fue el proceso
- Qué problemas específicos de tu industria conocen
Error 7: Aceptar plazos sin hitos claros
"La app está lista en 4 meses" no dice nada. ¿Qué pasa si no está lista a los 4 meses? ¿Qué se entrega en cada etapa? ¿Cómo sabés que el proyecto avanza?
Un cronograma bien estructurado incluye:
- Hito 1 (semana 2): Discovery completado, alcance firmado
- Hito 2 (semana 6): Diseño UX/UI aprobado
- Hito 3 (semana 12): Primera versión funcional para testing interno
- Hito 4 (semana 16): Beta corregida, lista para publicar
- Hito 5 (semana 18): App publicada en tiendas
Cada hito debería tener un entregable concreto que vos podés verificar. Los pagos deberían atarse a los hitos, no a las fechas.
🚫 Importante
Nunca paguésel 100% al inicio. La estructura de pagos recomendada es: 30% al firmar, 30% al aprobar el diseño, 30% al aprobar la versión beta, 10% al publicar en tiendas. Esto alinea los incentivos del proveedor con la entrega real.
Error 8: No preguntar quién es dueño del código
Cuando la app esté terminada, ¿dónde vive el código? ¿Podés llevarlo a otro proveedor si el actual falla o sube los precios?
Lo que tenés que pedir:
- El código fuente en un repositorio que sea de tu cuenta (GitHub, GitLab, Bitbucket)
- Acceso a todas las credenciales: servidor, base de datos, App Store, Google Play, servicios externos
- Documentación básica de la arquitectura técnica
Si el proveedor se niega a darte el repositorio en tu cuenta propia, es una señal de alarma. El código de tu app es tuyo desde el primer día.
El checklist antes de firmar
Antes de cerrar un presupuesto, verificá que tengas respuestas claras a estas preguntas:
- ¿El presupuesto desglosa cada fase con su costo?
- ¿Incluye discovery, diseño, testing y deploy?
- ¿Quiénes van a trabajar en el proyecto específicamente?
- ¿Cómo se manejan los cambios de scope?
- ¿Cuál es el cronograma con hitos y entregables?
- ¿Cómo es la estructura de pagos?
- ¿El código va a ser mío en mi repositorio?
- ¿Cuánto cuesta el mantenimiento post-lanzamiento?
- ¿Hablé con al menos un cliente anterior del proveedor?
Usá el cotizador de AppWizard para obtener una estimación de referencia antes de salir a pedir presupuestos — así llegás a las reuniones sabiendo qué rango esperar.
Preguntas frecuentes
- Los presupuestos varían porque los proveedores no siempre cotizan lo mismo. Algunos incluyen discovery, diseño, testing y soporte; otros solo el desarrollo de código. También varía la experiencia del equipo, la metodología de trabajo y la forma de estimar la complejidad técnica. Para comparar correctamente, exigí que cada proveedor desglose el presupuesto por fase e indique explícitamente qué incluye y qué no.
- La estructura de pagos estándar es un anticipo del 30% al firmar el contrato, un segundo pago del 30% al aprobar el diseño, un tercer pago del 30% al aprobar la versión beta y el 10% restante al publicar en tiendas. Nunca pagues más del 30–40% al inicio — los pagos deben estar atados a hitos concretos y verificables, no a fechas.
- Depende de lo que diga el contrato. Un contrato bien redactado incluye cláusulas de penalidad por retraso o mecanismos de ajuste de pago. Si el contrato no lo menciona, los retrasos son un riesgo que absorbés vos. Antes de firmar, preguntá qué pasa si el proyecto se retrasa más de X semanas y pedí que la respuesta quede escrita en el contrato.
- Una forma es usar herramientas de cotización como Deepyze para tener un rango de referencia antes de salir a pedir presupuestos. También podés pedir al menos 3 presupuestos a proveedores de distinto perfil (un freelancer senior, una agencia pequeña y una agencia mediana) y comparar qué incluye cada uno. Un presupuesto que está más de un 40% por debajo de los demás casi siempre es una señal de que algo no está incluido.
- Para proyectos con scope bien definido, el precio fijo da previsibilidad y protege tu presupuesto. Para proyectos exploratorios o donde el scope va a evolucionar, el modelo por hora (time & materials) es más honesto. El problema del precio fijo con scope mal definido es que los proveedores se protegen cotizando más alto de lo necesario para cubrirse ante imprevistos.