Recursos / Guía de decisión

Cuanto Cuesta un Software a Medida: Guía para Presupuestar

Una guía práctica para entender los componentes del costo, pedir cotizaciones comparables y decidir entre un piloto y la construcción completa.

Actualizado: 20 de septiembre de 2026

Esta guía explica factores de costo; no publica paquetes ni rangos de precio reales. Para una cifra basada en tu caso, describe el proceso, los sistemas, los datos y el volumen esperado en una solicitud de cotización.
01

La respuesta corta

No existe una cifra universal y responsable para el costo de un software a medida. Un sistema que digitaliza un solo proceso con diez usuarios no tiene el mismo alcance que uno que conecta cuatro sistemas, maneja permisos por rol y opera las 24 horas. La diferencia entre ambos puede ser de varios meses de trabajo y de un orden de magnitud en el presupuesto.

Lo que determina el costo no es la cantidad de pantallas, sino cuatro variables: el alcance funcional, las integraciones con tus sistemas actuales, el estado de tus datos y el nivel de confiabilidad que exige la operación. Dos proyectos con la misma descripción comercial pueden separarse por semanas de trabajo cuando esas variables se revisan en detalle.

Mientras tanto, el costo de no hacer nada corre todos los meses. Cada semana que el proceso sigue en hojas de cálculo hay horas de captura duplicada, errores que alguien corrige a mano y decisiones tomadas con números de hace quince días. Ese gasto no aparece en ninguna cotización, pero suele ser mayor que la mensualidad de operación del sistema que lo elimina.

Por eso esta guía no publica una tarifa. Explica los componentes del costo, muestra un ejemplo ilustrativo con números inventados y te da la información necesaria para pedir cotizaciones comparables. Desconfía de cualquier cifra que llegue antes de hablar de tus procesos, tus sistemas y tus datos: es una suposición con formato de propuesta.

02

Los componentes del costo

Toda cotización seria separa seis bolsas de trabajo. Cuando un proveedor te da un solo número, pide que lo reparta entre estas seis:

  • Descubrimiento: entrevistas con quienes operan el proceso, revisión de documentos y exportaciones existentes, definición del alcance y criterios de aceptación escritos antes de programar. Se cobra una vez y es la partida que más dinero ahorra después.
  • Construcción: diseño de pantallas, desarrollo del sistema y reglas del proceso. Es la partida visible, la que todos presupuestan, y rara vez supera la mitad del esfuerzo total del proyecto.
  • Integraciones: conexión con tu ERP, tu facturación, tu CRM o el sistema heredado que nadie documentó. Un sistema con API documentada se conecta en días; uno que solo exporta archivos a mano puede tomar más tiempo que el resto del proyecto.
  • Aseguramiento de calidad: pruebas con datos reales, casos de error, carga y revisión de permisos. Un sistema que solo se probó con datos de ejemplo falla la primera semana en producción.
  • Infraestructura: servidores, bases de datos, respaldos, monitoreo y dominios. Escala con el volumen de usuarios y transacciones, y aparece todos los meses, no solo al inicio.
  • Operación continua: soporte, correcciones, mejoras y ajustes cuando el proceso cambia. Es la partida que más se esconde: muchos sistemas mueren al año porque nadie presupuestó quién los mantiene.

Ojo con las cotizaciones baratas: el descuento casi siempre sale del mismo lugar. Se recorta el aseguramiento de calidad, la documentación o el descubrimiento, las tres partidas invisibles en una demo y las tres que más cuestan cuando faltan. Pide el desglose por escrito antes de comparar totales.

03

Qué hace subir o bajar el precio

Estas son las variables que más mueven una cotización, en el orden en que las revisamos en una llamada de alcance:

  • Integraciones: cada sistema que el software debe consultar o modificar suma trabajo de conexión, manejo de errores y pruebas. Una integración con un sistema sin documentación puede costar más que toda la construcción visible.
  • Permisos y roles: que cada usuario vea solo lo que le corresponde implica diseñar la matriz de acceso, programarla y probarla rol por rol. Un sistema con un solo tipo de usuario es mucho más simple que uno con dirección, operación, finanzas y clientes externos.
  • Migración de datos: mover la información de hojas de cálculo o del sistema anterior con su historia completa. Hemos visto proyectos donde limpiar diez años de catálogos duplicados toma más tiempo que programar el sistema nuevo. Si tus datos viven en exportaciones desordenadas, una consultoría de datos previa ordena esa partida antes de construir.
  • Volumen: usuarios simultáneos, transacciones por día y tamaño de los archivos que se procesan. Cien usuarios y diez mil usuarios no exigen la misma arquitectura ni la misma infraestructura.
  • Tolerancia a fallos: qué pasa cuando el sistema se cae un lunes a las 9 de la mañana. Si la respuesta es "se reintenta al rato", el costo es uno. Si la respuesta es "la operación no puede detenerse", hay respaldos, redundancia y monitoreo que presupuestar.

La dirección contraria también aplica: un solo proceso, un solo rol, sin integraciones y con datos limpios baja el precio de forma considerable. Recortar alcance es la forma honesta de bajar un presupuesto; recortar calidad es la forma cara.

04

Piloto vs construcción completa

La decisión de presupuesto más importante no es cuánto pagar, sino cuánto comprometer antes de tener información. Un piloto compra información: prueba el proceso más importante con alcance fijo, usuarios reales y una métrica de éxito acordada, y te da números propios para decidir la construcción completa.

En Marduk los pilotos tienen alcance fijo y duran de 2 a 6 semanas. La primera semana se va en descubrimiento: revisar tus exportaciones y documentos existentes, elegir el proceso y acordar por escrito los criterios de aceptación antes de programar. Las semanas siguientes se construye, con revisiones semanales donde ves avances funcionando, no presentaciones. Al cierre, el piloto se evalúa contra los criterios acordados.

La construcción completa agrega los procesos restantes, los roles, las integraciones y la confiabilidad de producción. Una propuesta seria explica qué parte del piloto se reutiliza al desplegar. Si la segunda cotización vuelve a cobrar todo desde cero, pregunta por qué.

Este camino también protege tu presupuesto: si el piloto muestra que el proceso no rinde como esperabas, gastaste semanas en descubrirlo, no meses. Y si rinde, la construcción completa se cotiza con datos reales de uso, no con suposiciones de una llamada comercial.

05

Un ejemplo ilustrativo

Para darle forma a la conversación, aquí va un proyecto hipotético con números inventados. Es un ejemplo, no una cotización: ninguna cifra de esta sección aplica a tu caso, y los proyectos reales se cotizan con el alcance definido por escrito.

Imagina una distribuidora que controla pedidos en hojas de cálculo y quiere un sistema de control de operaciones: captura de pedidos, estatus de surtido, cortes de caja y reportes para dirección. Un desglose plausible podría verse así:

  • Descubrimiento (2 semanas): entrevistas con ventas, almacén y finanzas; revisión de las hojas actuales; alcance y criterios de aceptación por escrito. Costo hipotético: 15% del proyecto.
  • Construcción (8 a 10 semanas): captura, flujo de surtido, cortes y reportes, con revisiones semanales. Costo hipotético: 50% del proyecto.
  • Integración con el sistema de facturación: timbrar desde el pedido y conciliar pagos. Costo hipotético: 15%.
  • Migración de datos: catálogo de clientes y productos, con limpieza de duplicados. Costo hipotético: 10%.
  • Pruebas y puesta en marcha: datos reales, casos de error, capacitación. Costo hipotético: 10%.
  • Operación: infraestructura más soporte y mejoras bajo suscripción mensual después del despliegue.

Un proyecto así podría cotizarse, solo como ejemplo, en un rango total de 40,000 a 70,000 USD según el detalle de las integraciones y la migración, más una operación mensual hipotética de 800 a 1,500 USD. Repetimos: estos números son una ilustración para entender la mecánica, no precios de Marduk ni una promesa de rango. La mecánica sí es real: la mitad del costo vive fuera de la construcción visible, y la operación aparece todos los meses.

Fíjate también en lo que empuja el ejemplo hacia arriba o hacia abajo. Si la facturación resulta tener una API documentada, la integración baja de costo. Si el catálogo llega con tres versiones contradictorias del mismo cliente, la migración sube. Si dirección decide que cada sucursal ve solo sus números, aparece una matriz de permisos que no estaba en la primera plática. Por eso el rango existe: no es indecisión del proveedor, es el reflejo de variables que solo se resuelven revisando tu operación.

06

Cómo pedir una cotización de software útil

Una cotización de software solo es comparable con otra cuando ambas responden a la misma información. Con estos ocho datos, cualquier proveedor serio puede darte una cifra defendible:

  • El proceso que quieres resolver primero y por qué duele hoy.
  • Quiénes lo usarán: cuántas personas y con qué roles.
  • Los sistemas que debe consultar o modificar: ERP, facturación, CRM o el archivo que hoy hace de sistema.
  • Dónde viven los datos actuales y en qué estado están: hojas de cálculo, exportaciones, papel o un sistema anterior.
  • Volumen aproximado: transacciones por día y usuarios al mismo tiempo.
  • Qué pasa si el sistema falla: molestia o operación detenida.
  • Fecha objetivo y qué la motiva.
  • La métrica que determinará si el proyecto funcionó.

Con esa información, una llamada de alcance toma alrededor de 45 minutos y produce un plan de una página: alcance, plazos, supuestos y exclusiones por escrito. Ese documento es el que comparas contra otras propuestas, no el correo de tres líneas con un total.

Desconfía de las comparaciones por hora. "Esta agencia cobra 40 USD la hora y aquella 80" no dice nada: no sabes cuántas horas estimó cada una, qué seniority compra cada hora, si incluye pruebas y gestión, ni cuánto retrabajo trae cada equipo. Compara alcance, entregables y criterios de aceptación, no tarifas.

07

Cómo comparar dos propuestas

Compara alcance contra alcance, no únicamente el total. Pon ambas propuestas lado a lado y confirma línea por línea: mismas integraciones, misma migración, mismas pruebas, misma operación. Una cifra menor suele dejar fuera el trabajo que más riesgo concentra, y ese trabajo se cobra después como "extra".

Lee la sección de exclusiones antes que la de entregables. Ahí es donde viven las sorpresas: la migración de datos "no incluida", la capacitación "a cotizar por separado", las integraciones "sujetas a disponibilidad del sistema del cliente". Pide que cada exclusión tenga un precio estimado o salga de la comparación.

Y pregunta quién se queda con qué. Hay propuestas donde el código pertenece al proveedor y tú rentas el derecho de uso: el día que cambias de proveedor, empiezas de cero. En Marduk el código y los datos son de tu propiedad, y la operación posterior corre bajo suscripción con un alcance definido por escrito. Esa diferencia no aparece en el total y vale más que cualquier descuento.

Una prueba rápida: pide a cada proveedor que responda por escrito qué pasa si el proyecto se detiene a la mitad, quién actualiza el sistema en el mes seis y qué incluye exactamente la cifra mensual de operación. La calidad de esas tres respuestas predice la calidad del proyecto mejor que la presentación comercial.

08

Preguntas frecuentes

¿Cuánto cuesta un software a medida en México? No hay una cifra honesta sin alcance. Depende del proceso, las integraciones, el estado de tus datos y la confiabilidad que exige tu operación. Un piloto de alcance fijo cuesta una fracción de la construcción completa y te da números reales para decidir el siguiente paso.

¿Por qué las cotizaciones varían tanto entre proveedores? Porque rara vez cotizan lo mismo. Una propuesta barata suele excluir descubrimiento, pruebas, migración de datos u operación, y esas partidas aparecen después como cargos extra. Compara línea por línea y lee las exclusiones antes de mirar el total.

¿Conviene cobrar por hora o por proyecto? Para ti conviene alcance fijo con criterios de aceptación escritos: sabes qué recibes y cuándo. El esquema por hora sin techo traslada todo el riesgo de estimación a tu presupuesto. En Marduk el alcance y los criterios de aceptación quedan por escrito antes de programar.

¿Qué costos siguen después del lanzamiento? Dos: infraestructura según el volumen, y operación, es decir, soporte, monitoreo y mejoras. Un sistema sin operación presupuestada se degrada: el proceso cambia y nadie lo actualiza. En Marduk la operación corre bajo suscripción con alcance definido, y el código y los datos siguen siendo tuyos.

¿Cómo sé si el retorno justifica el gasto? Haz la cuenta con tus números. Si tu equipo dedica 30 horas semanales a capturar, cruzar y corregir información entre hojas de cálculo, son unas 1,500 horas al año. Multiplica por el costo cargado de esa hora y compara contra el costo total del sistema a tres años. Esa matemática, con tus cifras reales, es la que debe cerrar antes de firmar.

09

Siguiente paso

Revisa cómo planteamos el servicio de desarrollo de software a medida: el proceso, los entregables y los criterios que usamos para decidir si un piloto tiene sentido. Si todavía no tienes claro qué construir, la consultoría de software produce un diagnóstico y un plan de alcance antes de comprometer presupuesto de construcción.

Para recibir una propuesta, envíanos los ocho datos de la sección anterior. La respuesta separa alcance, supuestos, costos recurrentes y exclusiones para que puedas compararla con claridad. Solicitar una cotización de software.