¿Cuánto cuesta un software a medida?

No vas a encontrar aquí una cifra, y desconfía de quien te la dé antes de haber hablado contigo. Lo que sí te contamos es qué mueve el precio de un programa a medida, cómo bajarlo sin que el resultado sea peor, cómo compararlo con un programa de cuota mensual y qué tiene que traer un presupuesto para que puedas ponerlo al lado de otro.

Por qué la pregunta no tiene una respuesta corta

«Software a medida» nombra cosas que no se parecen. Un panel para que el dueño de un taller vea qué coches tiene en el foso y cuáles salen hoy es un programa a medida. Un sistema para un distribuidor de alimentación con almacén, lotes, caducidades, rutas de reparto y comerciales que hacen pedidos desde el móvil también lo es. El segundo puede costar muchas veces lo que el primero, y los dos están bien presupuestados.

Por eso las cifras «desde» que circulan por internet sirven de poco: nadie sabe a cuál de los dos casos se refieren. Lo útil es entender de qué depende el precio, porque eso sí lo puedes controlar.

Lo que mueve el coste

Cuando presupuestamos un programa miramos seis cosas. Están ordenadas de la más visible a la que menos se ve, que suele ser la que más pesa.

Pantallas y tipos de usuario

Cada pantalla distinta (una lista de pedidos, la ficha de un pedido, el formulario para crear uno) hay que diseñarla, construirla y probarla. Y cada tipo de usuario multiplica: si el gerente ve todo, el comercial solo lo suyo y el cliente solo el estado de sus envíos, son tres versiones de la misma información con permisos distintos. Un programa con cinco pantallas y un tipo de usuario es un proyecto pequeño; con veinte pantallas y cuatro tipos de usuario, ya no.

Reglas de negocio

Es lo que de verdad hace que un programa sea tuyo y no de otro. «Si el pedido supera tal importe, lo aprueba el jefe de ventas.» «A los clientes de la zona norte se les reparte martes y jueves.» «Un presupuesto caduca a los quince días salvo que lo renueve el comercial.» Cada una de esas frases hay que descubrirla (muchas viven en la cabeza de una persona y no están escritas), programarla y probar qué pasa en los casos raros. Un negocio con pocas reglas claras cuesta menos que uno con muchas excepciones, aunque tengan las mismas pantallas.

Integraciones

Casi ningún programa vive solo. Tiene que leer los clientes de la facturación, avisar por WhatsApp, cobrar con tarjeta o volcar los pedidos en la tienda online. Cada conexión supone entender cómo habla ese programa externo, pedirle permisos y tratar lo que pasa cuando falla (porque fallará alguna vez). Conectar con un servicio moderno y bien documentado es rápido; sacar datos de un programa de gestión antiguo sin forma oficial de hacerlo puede ser la parte más cara de todo el proyecto.

Datos que migrar

Si hoy trabajáis con hojas de cálculo o con otro programa, esos datos tienen que pasar al nuevo. Y los datos reales están sucios: clientes duplicados, fechas en columnas de texto, productos que ya no existen. Limpiarlos y cargarlos es trabajo, y cuantos más años de historia queráis conservar, más. A veces compensa migrar solo lo vivo (clientes activos, stock actual) y dejar el histórico en un archivo consultable.

Lo que ya existe hecho

Esta es la palanca que más baja el precio. Cobrar con tarjeta, enviar correos, firmar documentos, gestionar calendarios, generar PDF: todo eso existe como pieza estándar y se integra en vez de construirse. Cuando hicimos Precita, nuestro producto para que un paciente firme el consentimiento desde el móvil antes de la primera cita, la firma digital, las cuentas por clínica y el envío del PDF se montaron sobre piezas que ya existían. Lo que se construyó a medida fue el flujo concreto: el enlace que recibe el paciente, qué rellena, dónde acaba el documento. Ahí está el valor, y ahí se concentró el trabajo.

Mantenimiento

Un programa entregado no se acaba. Hay un gasto fijo pequeño (el alojamiento y los servicios que use) y un gasto opcional: alguien que lo revise, actualice las piezas con avisos de seguridad y haga los cambios que el negocio vaya pidiendo. Lo segundo lo decides tú. Lo que no es opcional es saber cuánto es cada cosa antes de firmar: un proyecto barato con un mantenimiento obligatorio caro es un precio alto disfrazado.

Cómo abaratarlo sin estropearlo

Hay formas de bajar el precio que dejan un programa peor (quitar pruebas, saltarse el diseño, meter prisa) y formas que no. Estas son las segundas.

• Empieza por la parte que más duele. En casi todos los negocios hay una tarea que se come las horas: pasar los pedidos del WhatsApp a la hoja, cuadrar el stock a mano, perseguir a quien no ha pagado. Si el programa resuelve solo eso en la primera fase, ya estáis ganando tiempo mientras se construye el resto. Y a veces resulta que el resto no hacía falta.
• Divide en fases que se usan. Pagar tres fases y usar la primera a las pocas semanas cuesta parecido en total que pagar un sistema completo que nadie toca hasta dentro de seis meses, pero reparte el gasto y permite corregir el rumbo con lo aprendido en cada fase.
• Aprovecha lo que ya está hecho. Pagos, firma, correos, calendarios, mapas, lectura de códigos de barras. Pedir que se haga a medida algo que ya existe como pieza fiable es pagar dos veces: una por construirlo y otra por los fallos que la pieza estándar ya tiene resueltos.
• No hagas a medida lo que un estándar resuelve bien. La contabilidad, la facturación con sus exigencias fiscales y las nóminas tienen programas que llevan décadas y que cambian cuando cambia la ley. Lo sensato es conectar tu programa con uno de ellos, no reemplazarlo. Lo explicamos con calma en programa a medida o ERP.
• Trae las reglas escritas. Si antes de la primera reunión alguien del negocio apunta cómo se hacen las cosas y qué excepciones hay, el trabajo de descubrirlas se acorta mucho, y es trabajo que pagas.

Coste total frente a cuotas por usuario

La comparación que casi nadie hace bien es la de un programa a medida con un programa de suscripción (lo que se llama SaaS: pagas una cuota mensual y lo usas desde el navegador). La cuota parece poca cosa y el proyecto a medida parece mucho, porque uno se mide en meses y el otro de golpe. Hay que ponerlos en el mismo plazo.

Imagina un programa estándar que cobra una cuota al mes por cada persona que entra. Sois diez. En un año habéis pagado 120 cuotas; en cinco, 600. Si en ese tiempo contratáis a cuatro personas más, el número sube solo. Y si la función que os falta está en un plan superior (casi siempre lo está), cada cuota crece. No es un reproche al modelo: para muchos negocios es lo correcto.

El programa a medida va al revés: el gasto grande está al principio, en el proyecto, y después solo pagas el alojamiento y el mantenimiento que decidas. Da igual si entran diez personas o cuarenta. A partir de cierto número de usuarios y de años, la línea del a medida pasa por debajo de la del SaaS. Dónde se cruzan depende de vuestra cuota, de cuántos sois y de lo que cueste vuestro proyecto, así que la cuenta la tienes que hacer con vuestros números, a cinco años, no a un mes.

Hay un factor que no entra en la cuenta y pesa: si el estándar os obliga a seguir haciendo una parte a mano o en una hoja aparte, ese tiempo también es coste.

Qué pedir en un presupuesto para poder compararlos

Dos presupuestos con cifras distintas pueden estar describiendo proyectos distintos. Para comparar, pide que los dos respondan a lo mismo:

• Qué hace cada fase y qué deja fuera. Una lista de pantallas y funciones, no «módulo de gestión».
• Qué tecnología se usa y por qué. Que sea estándar y que otro programador la pueda coger sin empezar de cero.
• De quién es el código y en qué momento pasa a tu nombre. Lo correcto es desde el primer día.
• Dónde se aloja y cuánto cuesta ese alojamiento, a nombre de quién están las cuentas y qué servicios externos usa.
• Qué pasa con vuestros datos actuales: si se migran, cuáles y cómo.
• Qué incluye el mantenimiento, cuánto cuesta, si es obligatorio y con qué preaviso se deja.
• Qué ocurre si dejáis de trabajar juntos: con qué os quedáis y qué documentación hay.
• Fechas de cada fase y qué necesita de vosotros para cumplirlas.

Con esas ocho respuestas delante, la diferencia de precio entre dos presupuestos suele explicarse sola. Y si alguien no quiere responder a alguna, eso también es información.

Señales de un presupuesto peligroso

Nos enseñan bastantes presupuestos ajenos cuando piden una segunda opinión. Estas son las señales que más se repiten en los que acaban mal.

• Precio cerrado sin haber hablado con vosotros. Si nadie ha preguntado cómo trabajáis, el precio es para otro proyecto, no para el vuestro.
• Todo en una fase y pago entero por adelantado. Meses sin ver nada en uso y sin forma de parar si no va bien.
• El código o el alojamiento quedan a nombre del proveedor. Es la forma más habitual de atar a un cliente: para irse, hay que volver a empezar.
• Mantenimiento obligatorio y caro. El precio del proyecto es un gancho; el negocio está en la cuota.
• Tecnología propia o muy rara. Si solo ellos la conocen, solo ellos pueden tocar el programa.
• Sin lista de funciones. «Módulo de clientes» puede ser una lista con tres campos o un CRM entero. Después, cada cosa que falte será «un extra».
• Promete hacerlo todo a medida, incluida la contabilidad. Suele ser señal de que no conocen lo que ya existe o de que les interesa facturar más horas.

Cómo lo presupuestamos en Arume

Primero una conversación sobre cómo trabajáis hoy y qué os quita más tiempo. Después un prototipo que se puede tocar, para que veáis el programa antes de que exista y corrijamos lo que no encaje. Con eso damos un presupuesto cerrado por fases, con fechas, y la primera fase siempre es algo que ya se usa. El código, la base de datos y las cuentas quedan a tu nombre desde el primer día. Lo contamos entero en la página de desarrollo de software a medida y, si estás en la ciudad y prefieres que lo veamos en persona, en la de desarrollo de software en Salamanca.

Un ejemplo propio de proyecto pequeño: la consola con la que seguimos nuestras propuestas comerciales. Reúne cada propuesta con su estado y avisa cuando una lleva diez días sin respuesta. Ningún CRM hacía justo eso sin pagar por funciones que no íbamos a usar, así que se construyó a medida en una sola fase. Un programa no tiene por qué ser grande; tiene que ser el justo.

Preguntas frecuentes