Desarrollo de software a medida: cuándo compensa y cuándo no

La pregunta que llega a serpixel casi nunca es “¿me hago un software a medida?”. Suele ser otra: llevamos meses peleándonos con una hoja de cálculo y ya no da más de sí. El desarrollo de software a medida es una respuesta posible a eso, pero no siempre es la correcta, y distinguir los dos casos antes de gastar nada es lo que separa un proyecto que se usa de uno que se abandona a los tres meses.

Este artículo no intenta convencerte de que construyas nada. Intenta darte el criterio para decidirlo tú.

Qué es exactamente el desarrollo de software a medida

El desarrollo de software a medida consiste en construir una herramienta específica para el proceso de una empresa concreta, en lugar de adaptar ese proceso a un programa que ya existe. La diferencia práctica no está en la tecnología. Está en quién se adapta a quién.

Con un producto estándar de suscripción, pagas una cuota por acceder a un programa que usan miles de empresas. Las funciones vienen dadas. Si tu proceso encaja en la mayor parte de lo que hace, funciona bien. El resto lo acabas resolviendo con hojas de cálculo paralelas, correos y llamadas, que es exactamente el punto en el que la mayoría de empresas empiezan a plantearse otra cosa.

Con desarrollo a medida, defines tú qué tiene que hacer la herramienta, el código se escribe para tu caso y el resultado es tuyo. No pagas por usuario ni por funciones que no vas a tocar. A cambio, asumes un proyecto de construcción, con su alcance, su plazo y su mantenimiento.

Ninguna de las dos opciones es mejor en abstracto. Lo que hay que averiguar es en cuál de las dos situaciones estás.

Las tres preguntas que deciden, antes de comparar presupuestos

Antes de pedir una sola oferta, contesta estas tres. Si las tres tienen respuesta clara, ya sabes hacia dónde vas.

¿Cuántas veces al mes ocurre el proceso? Un proceso que ocurre cinco veces al mes se gestiona bien a mano, por incómodo que sea. Uno que ocurre doscientas veces se come a una persona entera. El volumen es lo que convierte una molestia en un coste.

¿Cuánto cuesta un error dentro de ese proceso? No es lo mismo equivocarse al apuntar una reserva que se corrige con una llamada, que equivocarse en un presupuesto que se envía a un cliente con un precio mal calculado. Cuanto más caro es el error, más valor tiene que el proceso deje de depender de la memoria de alguien.

¿El proceso está documentado? Esta es la que más proyectos hunde. Si nadie ha escrito nunca cómo funciona, lo que hay no es un proceso sino una costumbre. Volveremos sobre esto al final, porque es el error más caro de todos.

Cuándo NO compensa un desarrollo a medida

Esta es la parte que las páginas de agencias no suelen escribir. Hay cinco casos en los que la respuesta honesta es que no construyas nada.

1. Cuando un producto estándar cubre el proceso tal como es. Nadie debería construirse un programa de facturación, de contabilidad o de nóminas. Son procesos regulados, iguales en todas las empresas y resueltos desde hace años por productos maduros y baratos. Construir ahí es pagar por reinventar algo que ya funciona.

2. Cuando el proceso todavía cambia cada mes. Si la empresa es joven o el modelo está en pruebas, el proceso de hoy no es el de dentro de medio año. Convertir en software un proceso inestable no lo ordena: lo congela. Primero se estabiliza, luego se construye.

3. Cuando nadie va a hacerse responsable. Una herramienta a medida necesita una persona dentro de la empresa que la conozca, que decida qué cambia y que recoja lo que el equipo pide. Si esa persona no existe, el proyecto se entrega, se usa dos semanas y vuelve la hoja de cálculo.

4. Cuando el volumen no justifica el proyecto. Si el trabajo manual son dos horas al mes, ninguna cuenta sale. El desarrollo a medida se paga con tiempo recuperado o con ingresos que hoy se pierden, y si no hay ni lo uno ni lo otro, no hay caso.

5. Cuando el criterio principal es el precio. Un producto de suscripción reparte su coste de desarrollo entre miles de empresas. Competir contra eso en precio no tiene sentido y nadie debería intentarlo. El desarrollo a medida se justifica por encaje con el proceso y por propiedad del resultado, nunca por ser la opción más barata. Si lo que buscas es lo más barato, el producto estándar gana, y decírtelo es parte del trabajo.

Cuándo sí compensa

El desarrollo a medida empieza a tener sentido cuando se cumplen dos o más de estas condiciones.

El proceso es parte de lo que te hace competitivo. Si la forma en la que gestionas reservas, presupuestos o pedidos es una de las razones por las que tus clientes te eligen, meterla dentro de un programa genérico la iguala a la de todos los demás.

Ya estás pagando el coste, pero en horas. El proceso manual no es gratis. Está pagado con el tiempo de personas que podrían estar haciendo el trabajo que solo ellas saben hacer: atender bien a un cliente, decidir un caso ambiguo, cerrar una venta.

Los sistemas no se hablan entre ellos. Cuando el mismo dato se pica tres veces, en la web, en la hoja de cálculo y en la facturación, el problema no se arregla con un producto más. Se arregla conectando lo que ya hay.

El estándar te obliga a trabajar peor. Es el síntoma más claro: has adaptado tu forma de trabajar al programa, no al revés, y el equipo ha desarrollado rutinas para esquivar sus limitaciones.

Tres ejemplos de trabajo entregado por serpixel, descritos sin nombres porque lo relevante es el proceso:

• Una granja escuela vende reservas y bonos regalo desde su web. El equipo valida el acceso con lector de código QR en la entrada y las ventas se comunican a su facturación.
• Un instalador solar ofrece un presupuesto orientativo al momento desde su web, y cada solicitud entra en su CRM con los datos del cálculo.
• Un restaurante de montaña gestiona reservas prepagadas online, con carta en cuatro idiomas y un resumen diario para cocina.

Ninguno de los tres encontró un producto del mercado que cubriera su caso sin obligarlos a trabajar peor. Puedes ver cómo planteamos este tipo de proyectos en software a medida.

Lo que casi nadie te cuenta del coste

Cuando una empresa compara dos presupuestos de desarrollo, suele comparar la parte visible: las pantallas. El coste real está en otro sitio.

Las integraciones. Conectar la herramienta con la facturación, el CRM o la pasarela de pago lleva habitualmente más trabajo que construir la interfaz. Cada sistema tiene sus reglas, sus errores y sus casos raros, y ahí es donde se va el tiempo.

La migración de datos. Lo que hoy vive en hojas de cálculo, cuadernos y correos tiene que entrar en el sistema nuevo, y casi nunca está tan limpio como se recuerda. Limpiar y migrar es un proyecto en sí mismo.

El mantenimiento. El software que nadie mantiene deja de funcionar: cambian las pasarelas de pago, cambian las versiones, cambian los requisitos legales. Un desarrollo entregado y abandonado tiene fecha de caducidad.

Un presupuesto que no menciona estas tres partidas no es más barato. Es que no las ha contado.

Qué exigir por escrito antes de firmar

Cinco puntos. Si alguno falta en la propuesta, pídelo antes de avanzar.

1. Alcance funcional cerrado: qué hace la primera versión y, sobre todo, qué se queda fuera a propósito.
2. Código y cuentas a tu nombre: repositorio, servidor, dominio y pasarela de pago. Si esas cuentas son del proveedor, no tienes un software propio, tienes un alquiler con otro nombre.
3. Documentación de uso y de operación: cómo se usa la herramienta y cómo se opera cuando algo falla.
4. Condiciones de traspaso: qué pasa y en cuánto tiempo si dejáis de trabajar juntos.
5. Cadencia de mantenimiento por escrito: qué se revisa, cada cuánto y quién responde cuando algo se rompe.

El error más caro: construir sobre un proceso que nadie ha escrito

De todos los motivos por los que un desarrollo a medida acaba sin usarse, este es el más frecuente y el más caro.

Cuando el proceso no está documentado, cada persona del equipo tiene su versión. El software acaba recogiendo la de quien estuvo en más reuniones, y el resto del equipo lo percibe como una imposición que no refleja cómo trabajan de verdad. La herramienta no falla técnicamente. Falla porque describe un proceso que no existe.

La prueba es sencilla: escribe el proceso tal como lo hace hoy una persona, con sus excepciones. Si no cabe en dos páginas, todavía no está listo para convertirse en software. Ese trabajo de escritura no es burocracia previa: casi siempre revela que una parte del proceso sobra, y eso es más barato descubrirlo en un documento que en un desarrollo.

Es también donde se decide qué parte del trabajo puede asumir una herramienta y qué parte necesita criterio humano. La capa mecánica (calcular, registrar, avisar, repetir) es la que se automatiza. La decisión ambigua, la relación con el cliente y el caso raro siguen siendo del equipo, y es donde su tiempo vale más.

Cómo decidirlo sin gastar de más

Si has llegado hasta aquí, ya tienes el criterio: volumen, coste del error, documentación y encaje con lo que te hace competitivo. Con esas cuatro respuestas, la decisión suele ser evidente en una conversación de media hora.

En serpixel el punto de partida es siempre esa conversación: una sesión de descubrimiento de 30 minutos para entender el proceso antes de hablar de nada más. Si la respuesta honesta es que un producto del mercado te sirve, te lo decimos. Y si el problema no es construir una herramienta nueva sino conectar las que ya tienes, eso se llama automatización de procesos y es un proyecto distinto, normalmente más corto.