Pides tres cotizaciones para la misma aplicación. Una promete tres meses, otra siete, y la tercera no da plazo hasta hacer un "levantamiento". Entre la más barata y la más cara hay casi el triple. Lo más probable es que ninguna esté mal: cada proveedor entendió algo distinto de lo que pediste, así que cada uno cotizó una aplicación diferente.
¿Cuánto cuesta el desarrollo de aplicaciones a medida? La respuesta corta es "depende", y con eso no se arma un presupuesto. Tampoco sirve una tarifa de mercado sacada de cualquier parte, porque no existe una que aplique a todos los proyectos. Lo que sí podemos hacer es mostrar de qué depende el costo de un software a medida, cómo se suele cobrar y qué hacer para que el monto que apruebas se parezca al que terminas pagando.
Por qué dos cotizaciones pueden ser tan distintas
Una cotización temprana es una estimación hecha con poca información. Steve McConnell lo describe con el "cono de incertidumbre": una estimación hecha en la etapa de concepto inicial puede errar hasta cuatro veces hacia arriba o hacia abajo. El margen se va cerrando a medida que se definen requisitos y diseño.
Ahí está buena parte de la diferencia entre proveedores. Uno supuso que la integración con tu ERP era una consulta simple y otro asumió que había que construir una API desde cero. Uno cotizó solo la versión web; otro sumó la app móvil, las pruebas de seguridad y el despliegue. Antes de comparar montos, compara supuestos. Si una propuesta no los explica, pídelos por escrito.
Qué mueve el costo
El precio sale de las horas de trabajo multiplicadas por el valor de cada hora, más infraestructura y licencias. Las horas suben o bajan según estos factores:
| Factor | Qué lo encarece | Qué lo abarata |
|---|---|---|
| Alcance | Muchos tipos de usuario, flujos con excepciones, reportes a medida | Una primera versión acotada a un proceso |
| Integraciones | Sistemas sin API, ERP antiguos, datos duplicados entre sistemas | Sistemas con API documentada y datos ordenados |
| Plataformas | Web, iOS y Android desarrolladas por separado | Una sola plataforma o una app multiplataforma |
| Seguridad y datos | Datos personales o sensibles, muchos roles, auditoría | Datos internos sin información personal |
| Experiencia de usuario | Diseño desde cero y pruebas con usuarios | Componentes estándar |
| Equipo y plazo | Perfiles muy especializados o plazos comprimidos | Plazo razonable y equipo estable |
| Migración de datos | Limpiar y cargar años de historia | Partir con datos nuevos |
Las integraciones son el factor que más se subestima. Conectar una aplicación nueva con un sistema antiguo puede costar más que la aplicación misma, sobre todo cuando ese sistema no expone servicios y hay que construir el puente.
La seguridad viene justo después. Si el sistema va a tratar RUT, datos de salud o información de clientes, necesita control de acceso, registro de actividad y protección de datos desde el diseño, y todo eso se traduce en horas de diseño y de pruebas. Además, la Ley 21.719 de protección de datos personales sigue fijada para entrar en vigencia el 1 de diciembre de 2026. Hay un proyecto que la posterga un año, cuya idea de legislar aprobó la Comisión de Constitución del Senado en octubre de 2026, pero mientras no se publique como ley, la fecha es la misma. Una aplicación que empiezas a construir hoy va a operar años con la ley vigente. El cumplimiento tiene que estar en la cotización, no en una "fase dos".
Precio fijo o tiempo y materiales
La forma de cobro decide quién carga con el riesgo de haber estimado mal. Por eso conviene elegirla según el proyecto y no por costumbre.
Con precio fijo se acuerda un alcance cerrado y un monto. Tienes certeza presupuestaria, pero el proveedor agrega un margen para cubrir lo que no sabe, y cada cambio pasa por una negociación de alcance. Funciona cuando el requerimiento está claro y es poco probable que cambie.
En tiempo y materiales pagas las horas efectivamente trabajadas, por lo general con un tope o una estimación por etapa. Es más flexible y muchas veces sale más barato cuando el proyecto va a aprender en el camino. A cambio, te exige participar en la priorización y revisar avances seguido.
Muchos proyectos combinan los dos: un descubrimiento a precio fijo, que entrega alcance, arquitectura y una estimación más afinada, y después desarrollo por sprints con presupuesto acordado por etapa.
| Precio fijo | Tiempo y materiales | |
|---|---|---|
| Certeza del monto | Alta, si el alcance no cambia | Media, se controla por etapa |
| Flexibilidad ante cambios | Baja | Alta |
| Quién asume el error de estimación | El proveedor, y lo cobra en el margen | Compartido |
| Cuánto te involucras | Al inicio y en la aceptación | Durante todo el proyecto |
El costo que no aparece en la cotización
Construir la aplicación es la primera factura, no la última. Después llegan infraestructura, licencias de terceros, soporte y mejoras. La investigación académica sitúa la mantención entre el 60% y el 90% del costo total del ciclo de vida de una aplicación. El porcentaje exacto varía según cómo se mida, pero la conclusión se sostiene: lo que pagas por construir suele ser la parte menor.
Para evitar sorpresas, pide que la propuesta incluya:
- El costo mensual estimado de infraestructura con el uso esperado. Si la aplicación va a correr en Azure, se puede calcular con la calculadora de precios de Azure antes de escribir una línea de código.
- Las licencias y servicios de terceros que el sistema necesita, indicando cuáles se pagan todos los meses.
- Cómo será el soporte después de la entrega: bolsa de horas, mensualidad o cobro por requerimiento.
- Un monto de referencia para mejoras del primer año. Apenas los usuarios empiezan a usar la aplicación, aparecen los pedidos de cambio.
Cómo bajar el costo sin bajar la calidad
Recortar pruebas o documentación abarata la cotización y encarece todo lo que viene después. Hay maneras mejores de cuidar el presupuesto:
- Parte con una primera versión acotada. Es mejor resolver bien un proceso que cubrir cinco a medias, y lo que aprendes con usuarios reales vale más que cualquier especificación.
- Invierte en el descubrimiento, que es la etapa que más reduce la incertidumbre de la estimación. En Diseño y desarrollo de software: etapas y entregables detallamos qué deberías recibir al cerrarla.
- Revisa si todo tiene que ser código. Flujos de aprobación o formularios internos a veces se resuelven con Power Apps o Power Automate, y el desarrollo a medida queda para lo que de verdad lo necesita.
- Ordena tus datos antes de integrar. Cada inconsistencia entre sistemas termina convertida en horas de desarrollo.
- Asegura la propiedad del código. Si cambias de proveedor y el repositorio no es tuyo, pagas dos veces. Este y otros puntos están en Fábrica de software en Chile: 10 preguntas antes de firmar.
Preguntas frecuentes
¿Cuánto cuesta desarrollar software a medida en Chile?
No hay una cifra única. Depende del alcance, las integraciones, las plataformas y el nivel de seguridad que necesites. Una estimación seria se hace después de un descubrimiento, no tras una reunión de media hora.
¿Qué conviene más, precio fijo o tiempo y materiales?
Precio fijo si el alcance está claro y no va a cambiar. Tiempo y materiales si esperas ajustar en el camino. Un descubrimiento a precio fijo seguido de desarrollo por etapas suele equilibrar ambos.
¿Cuánto debo reservar para mantener la aplicación?
Más de lo que se suele pensar. Trata la infraestructura, las licencias, el soporte y las mejoras como costos anuales y pide que la propuesta los estime desde el inicio.
Pide una estimación con los supuestos a la vista
Una buena cotización dice qué supuso, qué incluye y qué deja fuera. En Disrupsoft desarrollamos aplicaciones web y móviles a medida, integradas con los sistemas que ya usas, con comunicación constante con tu equipo durante el proyecto. Si tienes una idea, o una cotización que no logras comparar con otra, conversemos sobre tu proyecto de desarrollo de aplicaciones a medida.
