Por qué no existe un precio de lista
Desarrollar software a la medida se parece a construir una obra: el costo depende de lo que se construye y de las condiciones del terreno. Dos sistemas que en una frase suenan iguales, por ejemplo “un portal para que los clientes consulten sus pedidos”, pueden tener costos muy distintos según cuántos sistemas consulten, quién tenga acceso, qué tan estricta sea la seguridad y cuánto se espere del diseño.
Por eso las cifras genéricas que circulan en internet sirven poco para decidir. Lo útil es entender qué factores mueven el costo, para que puedas definir un alcance razonable y evaluar las propuestas que recibas.
Los factores que definen el costo
| Factor | Qué lo hace subir | Cómo controlarlo |
|---|---|---|
| Alcance | Muchas funciones, flujos con excepciones, requisitos que cambian a mitad del proyecto | Definir la primera versión con lo mínimo útil y dejar el resto en una lista priorizada |
| Integraciones | Conectar varios sistemas, sistemas antiguos sin API, datos inconsistentes entre ellos | Inventariar los sistemas desde el inicio y revisar qué forma de conexión ofrece cada uno |
| Usuarios y roles | Muchos perfiles con permisos distintos, aprobaciones en varios niveles, varias empresas o sucursales | Agrupar permisos en pocos roles y empezar por los usuarios que más se benefician |
| Seguridad | Datos personales o financieros, requisitos regulatorios, auditorías y registros detallados | Clasificar los datos que maneja el sistema y aplicar el nivel de control que cada tipo requiere |
| Diseño | Interfaces muy personalizadas, muchas pantallas, versiones distintas por dispositivo | Usar un sistema de componentes consistente y diseñar a detalle solo las pantallas de uso frecuente |
| Mantenimiento | Muchas dependencias externas, cambios frecuentes, código sin pruebas ni documentación | Exigir pruebas automatizadas, documentación y un acuerdo de soporte con alcance definido |
Alcance
Es el factor que más influye y el más fácil de inflar. Cada función parece pequeña por separado, pero todas juntas suman pantallas, reglas, pruebas y casos de error. La pregunta que ayuda a recortar es: “¿qué necesita hacer el sistema el primer día para que alguien deje de trabajar como hoy?”.
Integraciones
Conectar con un sistema que ofrece una API documentada suele ser directo. Conectar con un sistema antiguo, una hoja de cálculo compartida o una base de datos sin documentación exige más trabajo de análisis y pruebas. También influye la calidad de los datos: si el mismo cliente aparece escrito de tres formas en dos sistemas, alguien tiene que resolverlo.
Mantenimiento
El software sigue costando después del lanzamiento: infraestructura, actualizaciones de seguridad, correcciones y ajustes cuando cambian las reglas del negocio. Incluirlo en la evaluación desde el principio evita sorpresas y te permite comparar con alternativas como una suscripción SaaS, tema que tratamos en la guía para decidir entre software a la medida o SaaS.
Entregar por fases para controlar la inversión
Construir todo de una vez concentra el riesgo: inviertes el presupuesto completo antes de saber si el sistema resuelve el problema como esperabas. Dividir el proyecto en fases te da puntos de decisión:
- Descubrimiento. Se revisa el proceso, los sistemas involucrados y los usuarios. El resultado es un alcance escrito, una propuesta de arquitectura y una estimación por etapas.
- Primera versión útil. Se construye el flujo principal para un grupo reducido de usuarios. Debe resolver un problema real, aunque todavía no cubra todos los casos.
- Ampliación. Con el uso real, se agregan funciones, roles e integraciones según la lista priorizada.
- Estabilización y traspaso. Se completan pruebas, documentación y capacitación, y se acuerda el esquema de soporte.
Al final de cada fase puedes ajustar prioridades, pausar o continuar con información concreta. Esto también reduce el costo de los cambios: corregir el rumbo después de la primera versión es mucho más barato que hacerlo al final.
El costo de no construir
Para evaluar la inversión, compárala con lo que cuesta seguir como estás. Ese costo existe aunque nadie lo facture:
- Horas de trabajo manual. Captura, copia entre sistemas, armado de reportes y revisiones que repite tu equipo cada semana.
- Errores y retrabajo. Correcciones, notas de crédito, envíos equivocados y el tiempo de quien los resuelve.
- Decisiones lentas. Información que llega tarde o incompleta porque depende de consolidar archivos a mano.
- Límites para crecer. Procesos que funcionan con el volumen actual pero exigirían contratar más personas para atender más clientes.
- Dependencia de personas clave. Conocimiento que vive en la cabeza de alguien o en una hoja de cálculo que solo esa persona entiende.
Para estimarlo, multiplica el tiempo que toma cada tarea por su frecuencia y por el costo de las horas de quien la hace, y suma el costo de los errores que genera. No necesitas precisión absoluta: basta un orden de magnitud para saber si el proyecto tiene sentido. La guía sobre qué procesos automatizar primero ofrece criterios para identificar dónde está ese costo.
Qué debe incluir una buena propuesta
Una propuesta clara te permite comparar proveedores y evita discusiones a mitad del proyecto. Revisa que contenga:
- Objetivo del negocio que el sistema resuelve, escrito en tus términos.
- Alcance detallado por fase, con lo que incluye y lo que queda fuera de forma explícita.
- Supuestos sobre los que se basa la estimación, como accesos, calidad de datos o disponibilidad de tu equipo.
- Integraciones previstas, con el método de conexión de cada una.
- Entregables de cada fase y criterios para aceptarlos.
- Modelo de cobro y cómo se gestionan los cambios de alcance.
- Equipo asignado y tu participación esperada.
- Propiedad del código, acceso a repositorios y documentación.
- Soporte y mantenimiento después del lanzamiento, con su alcance.
- Riesgos identificados y cómo se piensan mitigar.
Si una propuesta no menciona supuestos ni riesgos, pregunta por ellos. Todo proyecto los tiene, y es mejor conocerlos antes de firmar.
Señales de alerta en una cotización
Algunas características de una propuesta anticipan problemas de costo o de calidad más adelante:
- Cifra cerrada sin descubrimiento. Si el proveedor da un monto definitivo sin conocer tus procesos ni tus sistemas, está asumiendo cosas que quizá no sean ciertas.
- Alcance de una línea. Frases como “sistema de gestión completo” no permiten saber qué se entrega ni cuándo termina el proyecto.
- Sin pruebas ni documentación. Ahorran al inicio y encarecen cada cambio posterior.
- Sin mención del mantenimiento. El sistema necesitará soporte desde el primer día; conviene saber cómo y con qué costo.
- Código sin acceso. Si no recibes acceso al repositorio ni a la infraestructura, dependes por completo del proveedor para cualquier ajuste.
- Cambios sin proceso. Sin un mecanismo claro para evaluar y aprobar cambios de alcance, el presupuesto pierde referencia.
Cómo avanzar
Antes de pedir cotizaciones, escribe el problema que quieres resolver, los sistemas que ya usas y quiénes usarían la herramienta. Con eso, cualquier proveedor serio puede proponerte una fase de descubrimiento. Si quieres ver cómo planteamos estos proyectos, conoce nuestro servicio de desarrollo de software a la medida: trabajamos por fases, con alcance y supuestos por escrito, para que sepas en qué inviertes en cada etapa.