Preguntas cuánto cuesta un sistema a medida y te responden «depende». Es cierto. También es inútil si nadie te dice de qué depende. Esta guía recorre los factores que mueven el costo en los proyectos que hemos construido, para que puedas influir en la respuesta antes de pedir una propuesta. No vas a encontrar tablas de precios, porque cada proyecto se cotiza por su alcance. Lo que sí vas a encontrar es en qué fijarte.
El tamaño de la primera versión
El primer factor es el más manejable: qué entra en la versión que vas a usar de verdad. La lista completa de lo que algún día quieres tener es el mapa. El alcance es lo que necesitas para operar el primer día. Confundir los dos es la forma más común de pagar de más.
Un directorio de servicios que construimos tenía en el plan un panel para negocios, cobros, reseñas y reservas. La primera versión publicó solo las páginas públicas por categoría y zona, con contacto directo, porque eso era el negocio. El panel de registro y la facturación llegaron después, cuando había con qué justificarlos. Una plataforma para un club de bienestar siguió la misma lógica: primero una versión vendible pequeña, luego el portal completo de miembros, luego la tienda.
Una pregunta que reduce el alcance a la mitad: ¿qué pasa el primer día si esta función no existe? Si la respuesta es «lo hacemos a mano una semana», va a la segunda fase.
Las reglas de tu negocio
Las pantallas casi nunca son lo caro. Sorprende, porque son lo que se ve. Lo caro son las reglas que las pantallas tienen que respetar, y hay tres tipos que pesan más que el resto.
Las reglas locales de dinero. Facturación electrónica, retenciones, validación de cédula y RUC, varios adquirentes de tarjeta con esquemas de liquidación distintos, libros de facturas manuales. En el sistema de un hotel, el módulo de finanzas (gastos, nómina como obligación a conciliar, importación de estados de cuenta, cadena de liquidaciones de tarjeta hasta el banco) fue el trabajo más largo del proyecto, y era el módulo que la herramienta anterior nunca tuvo.
Las reglas que ya viven en una hoja de cálculo. Una agencia de talentos calculaba métricas y tarifas en un archivo con fórmulas. Esas fórmulas eran la especificación real: se extrajeron, se validaron contra una fila de ejemplo y se convirtieron en un motor de cálculo con umbrales editables. Cuesta menos que inventar reglas nuevas, pero más que copiar un archivo. Si tienes ese archivo, llévalo a la primera reunión.
Las reglas que cambian seguido. Categorías, métodos de pago, canales de venta, tarifas por nivel. Si viven en el código, cada cambio es un desarrollo, con su tiempo y su costo. Si viven como datos editables en un panel, las cambias tú. Decidirlo al inicio cuesta un poco más; no decidirlo cuesta cada mes.
Las integraciones
Cada integración es un contrato con un tercero: una pasarela de pago, un servicio de mensajería, una hoja de cálculo en la nube, un proveedor de correo. Y cada una trae su propia forma de fallar, en el momento que ella decida.
Por eso las integraciones son lo primero que se recorta para lanzar. En el proyecto de la agencia de talentos, la sincronización automática con una hoja de cálculo se reemplazó por una carga manual de archivo, por decisión del cliente y por escrito, para tener el sitio antes. Meses después se retomó con un formato de importación que salía de la herramienta que ya usaban.
También conviene saber que no todas las integraciones cuestan igual. Un servicio de mensajería tiene una versión oficial, con costo, y librerías «gratis» no oficiales. Tentador. Pero para un negocio cuyo número de WhatsApp está impreso en todo su material, el ahorro de la versión no oficial no compensa el riesgo de perder el número. Ese análisis se hizo con evidencia antes de decidir, y la decisión fue la versión oficial.
| Factor | Sube el costo cuando | Baja cuando |
|---|---|---|
| Primera versión | Incluye todo el mapa | Incluye lo que se usa el primer día |
| Reglas de negocio | Involucran impuestos, bancos, tarjetas | Ya existen en un documento o una hoja de cálculo |
| Integraciones | Son varias y todas para el lanzamiento | Se recortan a una fase posterior, por escrito |
| Datos existentes | Vienen en archivos sin formato uniforme | Hay un archivo limpio con un identificador estable por fila |
| Roles y usuarios | Cada rol necesita su propia aplicación desde cero | Las aplicaciones comparten código y difieren solo en lo que cada rol ve |
| Tiempo real | Se pide en todas las pantallas | Se usa solo donde una demora cuesta dinero |
| Mantenimiento | Nadie lo decide antes de lanzar | Hay un responsable, respaldos y un panel para editar contenido |
Los datos que ya tienes
Migrar a un sistema nuevo implica cargar lo que ya tienes: clientes, productos, historial. Esa carga tiene dos costos escondidos, y los dos aparecen tarde si nadie los busca.
El primero es el formato. Un importador que funciona con datos de ejemplo se rompe con el archivo real del contador: encabezados en la fila tres, fechas en otro formato, números con formato contable. En el hotel, la primera carga real rechazó casi la mitad de las filas. Se descubrió a tiempo porque la carga se hizo temprano, con datos reales y con la intención de que se rompiera.
El segundo es la repetición. Tú sigues editando tu archivo mientras el sistema se construye, así que la carga se hace varias veces. Un importador que se puede correr las veces necesarias sin duplicar ni pisar cambios manuales cuesta más al inicio y ahorra cada vez que se usa.
Usuarios y roles
Cada rol distinto (administrador, recepción, vendedor, cliente) necesita ver cosas distintas y no ver otras. Precios internos que no llegan a la web pública, métricas que un rol ve y otro no, propuestas en PDF que nunca muestran el reparto interno. Todo eso se decide en el servidor, no escondiendo elementos en pantalla, y toma trabajo. ¿Por qué en el servidor? Porque lo que se esconde en pantalla, cualquiera lo puede ver.
Lo que no tiene que multiplicar el costo es tener varias aplicaciones. En el hotel, recepción, punto de venta y administración son tres aplicaciones que comparten el mismo código base; la de recepción tiene solo unos cientos de líneas propias porque las reservas, la caja y los clientes viven en un paquete común. La segunda aplicación sale casi gratis si la primera se construyó pensando en eso.
Tiempo real solo donde paga
«Que se actualice solo» suena a requisito básico. Es uno de los más caros de sostener. La pregunta útil es dónde una demora de un minuto cuesta dinero. En el hotel, el tablero de habitaciones y el de estadías se actualizan en tiempo real porque dos personas en recepción pueden asignar la misma habitación. Todo lo demás se actualiza cuando el usuario refresca, y nadie lo nota. Esa distinción baja el costo y la complejidad.
Lo que es gratis y lo que cuesta una conversación
Hay costos que la gente espera y no existen. Los mapas pueden usar datos abiertos sin clave ni cobro por carga. Los proveedores de nube tienen capas gratuitas que alcanzan para un negocio pequeño durante meses. El directorio de servicios corre con un mapa abierto y un servidor que escala a cero cuando nadie lo usa.
Y hay costos que la gente no espera y sí existen: los que se pagan en conversaciones. Cargar la oferta de un directorio con datos públicos exige guardar la fuente de cada dato y pedir permiso antes de mostrar una sola foto de un negocio. Un formulario que el cliente diseñó y que no estaba en el alcance firmado espera hasta que se apruebe. Las páginas cuyos datos el cliente no confirmó se quedan en borrador. Nada de eso es código, y todo mueve el calendario. Si quieres acortar un proyecto, empieza por esas conversaciones antes de firmar.
Después del lanzamiento
El costo no termina cuando el sistema sale. Alguien tiene que actualizar, respaldar y atender cambios, y conviene que ese alguien tenga nombre antes del lanzamiento. Cuando el cliente edita producción directamente, cada versión nueva tiene que empezar desde un respaldo fresco para no pisar lo que él cambió; esa regla se escribió después de que casi pasa. Cuando el mantenimiento llega como mensajes de una línea, convertirlos en tareas con causa raíz y evidencia cuesta menos que responder cada uno en el momento.
Si estás armando un pedido, lleva estas preguntas a la primera reunión: qué entra en la primera versión, qué reglas de dinero aplican, qué integraciones pueden esperar, qué datos hay que cargar y quién mantiene el sistema. Con eso, la propuesta deja de ser «depende». Cómo se ve ese proceso cuando el sistema reemplaza a uno existente está en el caso de la plataforma que sacamos de un proveedor externo y en la guía sobre modernizar un sistema legacy por etapas. Lo que construimos, en nuestras capacidades.
Preguntas frecuentes.
¿Cuánto cuesta un software a la medida?
No publicamos precios porque cada proyecto se cotiza a partir de su alcance. Lo que sí se puede saber de antemano es qué mueve el costo: el tamaño de la primera versión, las reglas del negocio, las integraciones, los datos a cargar, los roles y el mantenimiento. Esta guía recorre cada factor.
¿Qué es lo que más encarece un sistema a medida?
En los proyectos que hemos hecho, las integraciones con terceros y las reglas locales de dinero (impuestos, conciliación con bancos y tarjetas) son lo que más esfuerzo lleva. Las pantallas casi nunca son el problema.
¿Cómo bajo el costo sin perder lo importante?
Definiendo una primera versión que puedas usar, dejando las integraciones para una fase posterior por escrito, y guardando como datos editables las reglas que cambias seguido, para no pagar un desarrollo cada vez.
¿Un sistema a medida sale más caro que uno de paquete?
Al inicio, a veces. Con el tiempo, un paquete cobra licencias y te obliga a adaptar tu proceso al suyo. Un sistema a medida se paga por lo que necesitas y crece con reglas que tú controlas. La comparación depende de cuánto de tu operación es distinta a la de los demás.
