Desarrollo de software a medida: cuándo hacerlo

Una empresa no suele buscar desarrollo de software a medida porque quiera código. Lo busca cuando una parte importante del negocio ya no cabe en las herramientas que usa: hojas de cálculo que se pisan, procesos que dependen de una persona, datos repartidos entre sistemas o un CRM que obliga a trabajar al revés.

El riesgo está en confundir el síntoma con la solución. «Necesitamos una aplicación» puede significar muchas cosas: automatizar una cola, ordenar datos, sustituir una plataforma antigua, construir un panel interno o integrar sistemas que no se hablan.

Desarrollar software a medida merece la pena cuando el proceso que quieres resolver es propio, estable y suficientemente importante como para diseñar una herramienta alrededor de él; no cuando solo buscas una versión más barata de una herramienta estándar.

Qué significa desarrollar software a medida

Desarrollar software a medida no es empezar una aplicación desde cero por orgullo técnico. Es construir un sistema alrededor de una forma concreta de trabajar.

La diferencia no está solo en la pantalla. Está en las reglas que el sistema aplica, en los datos que guarda, en cómo se integra con lo que ya existe y en qué decisiones deja fuera porque no puede sostenerlas.

Una herramienta estándar parte de un modelo general: un CRM genérico, un ERP, una tienda, un gestor de contenidos. Eso puede ser suficiente si tu proceso encaja razonablemente bien. Un desarrollo a medida empieza por otra pregunta: cómo trabaja realmente tu empresa y qué parte de ese trabajo no debería depender de memoria, Excel, correos o apaños.

Por eso, en software a medida no lo planteo como «hacer una app», sino como diseñar sistemas: herramientas internas, CRM propios, modernización de plataformas, integraciones y capas de datos que resuelven una necesidad concreta.

Cuándo tiene sentido construir algo propio

Hay señales bastante claras. No todas obligan a construir; pero cuando se acumulan, conviene mirarlo en serio.

• El proceso es diferencial. No es administración genérica: es la forma en que vendes, produces, atiendes, apruebas, reservas, evalúas o entregas.
• La herramienta estándar te obliga a trabajar peor. El equipo pasa más tiempo rodeando el sistema que usándolo.
• Hay reglas propias. Estados, exclusiones, permisos, cálculos, colas o validaciones que no caben sin forzar la herramienta.
• El dato tiene que quedar bien guardado. No basta con ver algo en pantalla: necesitas historial, trazabilidad, evidencias o una fuente de verdad.
• Hay varios sistemas conectados a mano. Se exporta, se copia, se pega y se vuelve a comprobar.
• La plataforma actual se ha quedado pequeña, pero conserva años de datos, enlaces o procesos. En ese caso, muchas veces el trabajo no es tirar, sino modernizar sin perder lo que funciona.

También hay señales de lo contrario. Si el proceso es estándar, cambia cada semana o todavía no sabes cómo debería funcionar, quizá conviene configurar una herramienta existente, documentar el flujo y esperar. Ya lo defendí en el software debe adaptarse a la empresa: se construye a medida donde aporta, no por costumbre.

Ejemplo: un CRM cuando el proceso comercial no cabe en un CRM

Gustela CRM es un buen ejemplo de cuándo un desarrollo propio tiene sentido. No se trataba de tener «un CRM» en abstracto, sino de sostener un proceso comercial concreto: leads de fuentes públicas, campañas por lotes, tareas de seguimiento, plantillas, estados y reglas de exclusión antes de encolar envíos.

La clave no era la pantalla del pipeline. Era que el cumplimiento viviera en el servidor: nadie dado de baja, rebotado o marcado como no contactar podía volver a la cola. También era importante poder probar el flujo completo con el SMTP desactivado, simulando envíos y dejando registro sin mandar correos.

Este es el tipo de caso donde un CRM estándar puede quedarse corto: no por falta de funciones, sino porque el proceso importante está justo en las reglas que la herramienta genérica no conoce.

Ejemplo: modernizar sin perder años de contenido

A veces el desarrollo de software a medida no empieza en una idea nueva, sino en una plataforma antigua que ya sostiene el negocio.

En Rocio.com, el problema no era publicar otra web. Era reconstruir una propiedad digital con un archivo editorial desde 1992, un WordPress con unos 15 años de historia, 11.596 noticias publicadas, 169 hermandades con ficha propia y 47.401 archivos multimedia migrados.

Ahí la decisión importante fue normalizar antes de construir encima. Si el contenido está atrapado en metadatos, fechas como texto y estructuras difíciles de consultar, cualquier función nueva hereda el problema. Primero se diseña el modelo de datos; después vienen el panel editorial, las redirecciones, la búsqueda y el asistente sobre el archivo.

Esto conecta con la modernización de sistemas heredados: conservar lo valioso, aislar lo frágil y reconstruir lo que impide evolucionar.

Cómo plantearía un desarrollo a medida

Antes de estimar pantallas, conviene ordenar la decisión. Un buen inicio no es un listado infinito de funcionalidades, sino un mapa claro de proceso, datos y riesgos.

1. Escribir el proceso real. Qué ocurre hoy, quién interviene, qué se decide y dónde se atasca.
2. Separar lo crítico de lo cómodo. No todo lo que se puede construir debe entrar en la primera versión.
3. Definir la fuente de verdad. Qué dato manda si hay discrepancias y qué historial hay que conservar.
4. Diseñar reglas de servidor. Lo importante no puede depender de que alguien pulse bien un botón.
5. Decidir qué no se va a calcular. Si el dato no existe o no es fiable, el sistema no debe enseñarlo como si lo fuera.
6. Construir una primera versión operativa. Pequeña, pero real: con usuarios, datos, permisos, errores y mantenimiento.

Este orden evita uno de los errores más caros: desarrollar una interfaz bonita sobre un proceso mal entendido.

Qué riesgos debe evitar un proyecto así

Un desarrollo a medida falla cuando se comporta como una maqueta eterna. Para que sea un sistema de verdad, tiene que poder mantenerse.

Eso implica decisiones poco vistosas: nombres claros en la base de datos, permisos pensados desde el principio, copias de seguridad, tests en las reglas críticas, colas para procesos lentos, registros de errores y documentación suficiente para que el sistema no dependa de una sola cabeza.

También implica no meter IA, automatización o integraciones porque suenen bien. Si una regla es clara, probablemente debe ser determinista. Si una decisión necesita criterio humano, el sistema debe preparar la evidencia, no fingir que decide solo.

En Zentia, por ejemplo, la separación entre agencias no se dejó en manos de la interfaz: cada fila pertenece a una agencia y el aislamiento vive en la base de datos mediante Row Level Security. Esa es la clase de decisión que no se ve en la portada, pero decide si el sistema es serio.

Preguntas que conviene responder antes de empezar

Antes de encargar un desarrollo de software a medida, yo intentaría responder a estas preguntas:

• ¿Qué proceso concreto queremos mejorar?
• ¿Qué parte de ese proceso nos diferencia de una empresa cualquiera?
• ¿Qué herramientas usamos hoy y por qué no bastan?
• ¿Qué datos existen ya y cuáles habría que empezar a registrar?
• ¿Qué decisiones debe tomar el sistema y cuáles debe dejar a una persona?
• ¿Qué integraciones son imprescindibles desde el primer día?
• ¿Qué pasaría si el sistema no estuviera disponible durante unas horas?
• ¿Quién lo va a mantener cuando cambie el negocio?

Si estas respuestas no están claras, el primer trabajo no es programar. Es diseñar el sistema.

El desarrollo a medida no empieza cuando alguien escribe código. Empieza cuando entiendes qué parte del negocio no puede seguir viviendo en herramientas genéricas.

Si tienes un proceso que ya sostiene ventas, operaciones, contenido o datos y las herramientas actuales se han quedado cortas, en software a medida explico cómo trabajo: revisar lo que existe, separar lo que merece construirse y convertirlo en un sistema que puedas usar y evolucionar.