Depende del alcance, y cualquiera que te dé una cifra antes de entender tu operación te está dando una suposición. Lo que sí se puede explicar con precisión es qué determina ese número, cómo se estructura una cotización seria y cómo comparar propuestas que parecen iguales pero no lo son.
Por qué no publicamos una lista de precios
Es la primera pregunta de cualquier empresa que necesita un desarrollo, y merece una respuesta honesta en lugar de una tabla que suene convincente.
El problema con publicar precios es que bajo una misma frase caben cosas radicalmente distintas. Dos empresas pueden pedir un sistema de control de inventarios y una necesitar tres pantallas para un almacén, mientras la otra requiere trazabilidad por lote, cuatro perfiles de usuario con permisos diferenciados y conexión con su sistema contable. El nombre es el mismo; el trabajo, no.
Una cifra publicada obliga a asumir cuál de esos dos casos eres tú. Si el proveedor asume el escenario simple, atrae consultas y después aparece el trabajo adicional que nadie previó. Si asume el complejo, espanta a quien tenía una necesidad acotada. En ambos casos el número publicado no sirvió para nada.
Lo que sí podemos comprometer: que la propuesta llegue desagregada módulo por módulo, con el esfuerzo y el costo de cada uno, y que ese precio quede cerrado por escrito antes de escribir la primera línea de código. Los cambios posteriores se cotizan aparte y los apruebas tú.
Los cinco factores que determinan el presupuesto
Si entiendes estas cinco variables, puedes leer cualquier cotización, entender de dónde sale la cifra y detectar cuándo alguien está calculando sobre supuestos distintos a los tuyos.
1. La cantidad de módulos
Es el factor más evidente y el de mayor peso. Un sistema que solo controla inventario representa una fracción del trabajo de uno que además gestiona compras, ventas, despachos y facturación. Cada módulo suma pantallas, reglas de negocio, permisos y pruebas, y también las conexiones con los módulos que ya existían.
2. Las integraciones con otros sistemas
Es la parte más subestimada de cualquier presupuesto. Si el otro sistema expone una interfaz moderna y documentada, la integración se resuelve en días. Si hay que extraer información de un sistema antiguo sin documentación, o de un proveedor que no colabora, puede tomar semanas y convertirse en la tarea de mayor riesgo del proyecto.
Por eso una cotización responsable pregunta con qué sistemas debe conectarse antes de dar cualquier número.
3. Los perfiles de usuario y sus permisos
Un sistema donde todos ven lo mismo es sustancialmente más simple que uno donde el vendedor ve sus clientes, el jefe ve los de todo su equipo, el gerente ve el consolidado y el contador ve únicamente los montos. Cada regla de visibilidad hay que programarla, probarla y mantenerla.
4. El volumen de datos y la exigencia de disponibilidad
Un sistema para veinte personas y otro para dos mil no se construyen igual. Cuando el volumen crece, o cuando una caída de dos horas se traduce directamente en ventas perdidas, la arquitectura debe contemplar redundancia, monitoreo y respaldos. Eso es trabajo adicional y conviene decidirlo de forma consciente, no descubrirlo después.
5. El nivel de diseño de la experiencia
Una herramienta interna que usarán diez personas capacitadas puede ser funcional y austera sin que nadie se queje. Una aplicación de cara al cliente compite con todas las aplicaciones que esa persona usa a diario, y ahí el diseño deja de ser un adorno para convertirse en un requisito del que depende que la usen.
Los tres modelos de contratación
Antes de comparar cifras conviene saber bajo qué modelo se calculó cada una, porque cambian por completo quién asume el riesgo si la estimación falla.
| Modelo | Cómo funciona | Quién asume el riesgo | Cuándo conviene |
|---|---|---|---|
| Precio cerrado | Se define el alcance completo y se acuerda una cifra fija por entregarlo. | El proveedor. Si estimó mal, la diferencia la absorbe él. | Cuando el alcance está claro y no se espera que cambie mucho. |
| Por horas | Se factura el tiempo efectivamente trabajado, con reportes de avance. | El cliente. Si el trabajo se extiende, el costo sube. | Cuando el alcance es exploratorio. Exige siempre un tope acordado. |
| Por etapas | Cada etapa se cotiza y se cierra por separado, con precio fijo por etapa. | Repartido. Ambas partes reevalúan antes de comprometer la siguiente. | En proyectos grandes. Es el que usamos por defecto. |
El modelo por etapas tiene una ventaja que suele pasarse por alto: puedes detener el proyecto al terminar cualquier etapa, quedándote con lo construido hasta ese punto y sin penalidad. Eso reduce muchísimo el riesgo de la decisión inicial.
Qué debe contener una cotización seria
Una cotización de una sola página con una cifra global y la frase "desarrollo de sistema a medida" no es una cotización: es un número. Antes de firmar, verifica que el documento contenga al menos esto.
- El alcance desagregado por módulo, con los entregables de cada uno y su estimación de esfuerzo asociada.
- Lo que explícitamente no está incluido. Esta sección evita la mayoría de los conflictos posteriores y su ausencia es una mala señal.
- El cronograma por entregas, con fechas concretas y no solo una duración total.
- El tratamiento de los cambios de alcance: cómo se cotizan, quién los aprueba y cómo afectan al plazo.
- La propiedad del código y de los datos, indicada de forma expresa.
- Qué incluye el soporte posterior y durante cuánto tiempo, o desde cuándo empieza a cobrarse aparte.
- Los costos recurrentes de alojamiento, dominios y servicios de terceros, que no son parte del desarrollo pero sí de tu presupuesto anual.
Cinco señales de alerta al comparar propuestas
- Un precio muy por debajo del resto. Casi siempre significa que el alcance entendido es menor, no que el proveedor sea más eficiente. La diferencia reaparece después, como trabajo adicional.
- Ausencia de una etapa de descubrimiento. Quien cotiza sin haber entendido el proceso está adivinando, y esa incertidumbre la termina pagando alguien.
- Negativa a entregar el código fuente. Es una forma de asegurarse la permanencia del cliente por dependencia y no por calidad.
- Tecnologías propietarias del proveedor. Si el sistema se construye sobre una base que solo ese equipo domina, cambiar de proveedor deja de ser una opción real.
- Plazos que no contemplan tu participación. Todo proyecto requiere horas de tu equipo para validar y decidir. Un cronograma que lo ignora se incumplirá desde la segunda semana.
Cómo reducir el costo sin arruinar el proyecto
Hay maneras razonables de bajar el presupuesto y maneras que terminan costando más. Estas son las que funcionan.
- Recorta alcance, no calidad. Identifica el módulo que resuelve el problema más urgente y construye solo ese. Es preferible un sistema pequeño que se usa a diario a uno completo a medio terminar.
- Aprovecha lo que ya existe. Si una parte del problema la resuelve una herramienta del mercado por una suscripción mensual, intégrala en lugar de programarla desde cero.
- Ordena tus datos antes de empezar. Buena parte del costo de una migración se va en limpiar información inconsistente, y ese trabajo tu equipo puede adelantarlo.
- Asigna a una persona con capacidad de decidir. Los proyectos se encarecen cuando cada duda tarda una semana en resolverse.
Lo que no conviene recortar: las pruebas, la documentación y la capacitación. Son las tres primeras partidas que se eliminan para bajar el precio y las tres que más caro se pagan después, en errores en producción y en dependencia total del proveedor.
Cómo obtener una cifra para tu caso
El camino corto es una sesión de discovery, que en nuestro caso no tiene costo ni compromiso. Son unos cuarenta minutos en los que reconstruimos cómo opera tu empresa hoy, qué información se registra en cada paso y dónde se está perdiendo tiempo o margen.
De esa sesión sale un diagnóstico escrito con el problema priorizado. Con ese documento se construye una propuesta desagregada por módulos, con esfuerzo, plazo y precio cerrados por escrito. Y si concluimos que tu necesidad se resuelve con una herramienta que ya existe y cuesta menos que un desarrollo, te lo decimos en esa misma sesión.
Puedes revisar antes nuestra metodología completa, etapa por etapa, o el catálogo de servicios para ubicar qué tipo de proyecto es el tuyo.
¿Quieres una cifra para tu proyecto?
La sesión de discovery no tiene costo y termina con un diagnóstico escrito, contrates o no. La propuesta llega en menos de 48 horas.
Preguntas frecuentes
¿Por qué no publican una lista de precios?
Porque una cifra publicada sin conocer tu operación no es un precio, es una suposición. Dos proyectos que se describen con la misma frase pueden costar tres veces distinto según los módulos, las integraciones y los perfiles de usuario. Preferimos entender el caso primero y entregar una cifra que se sostenga por escrito, en lugar de un número atractivo que después haya que corregir.
¿Entonces cómo hago para presupuestar antes de decidir?
La sesión de discovery no tiene costo y de ella sale un diagnóstico escrito con el problema priorizado. Con eso ya se puede construir una propuesta desagregada por módulos, con esfuerzo, plazo y precio por cada uno. Ese documento sirve para presupuestar aunque decidas no contratarnos.
¿Se puede pagar en partes?
Sí. Lo habitual es dividir el pago en hitos asociados a entregables concretos: un adelanto al inicio y el resto contra la aprobación de cada etapa. Así el riesgo se reparte entre ambas partes y ninguna queda expuesta.
¿Cuál es la forma más segura de reducir el costo?
Reducir el alcance de la primera versión, nunca la calidad. Identifica el módulo que resuelve el problema más urgente, constrúyelo solo a él y amplía después, cuando el sistema ya esté generando valor y sepas mejor qué necesitas.