udae
Notas técnicas/EstrategiaDesarrolloDecisión

Plataforma o desarrollo a medida: cómo se decide

La respuesta se suele improvisar según lo que el proveedor sepa hacer, que es exactamente el criterio equivocado. Hay una forma de razonarlo antes de gastar.

Álvaro Urra··8 min

Hay una pregunta que separa los proyectos que salen bien de los que se encarecen a mitad de camino, y casi nunca se formula a tiempo: ¿resolvemos esto con una plataforma que ya existe o construimos algo propio? La respuesta se suele improvisar según lo que el proveedor sepa hacer, que es exactamente el criterio equivocado.

Merece la pena aclarar de qué hablamos. Una plataforma es cualquier producto que ya está construido y en el que uno configura: una herramienta de automatización, un CRM, un gestor de proyectos, un software vertical del sector. Desarrollo a medida es escribir código propio para un problema concreto. Entre ambos extremos hay un terreno intermedio grande, y ahí es donde acaba la mayoría de los proyectos sensatos.

Por qué la plataforma gana casi siempre al principio

Empezar por producto existente sale más barato, se entrega antes y no genera deuda de mantenimiento. Alguien ya ha resuelto los casos raros que tu empresa todavía no ha encontrado, y ese trabajo invisible es la mayor parte del valor de un software maduro. Además, si la herramienta no encaja, cambiarla cuesta bastante menos que tirar código propio.

Por eso nuestra postura por defecto es intentar resolverlo con lo que ya existe, incluso cuando el resultado es menos elegante. Un proceso que funciona en una plataforma estándar y aburrida es mejor que un proceso perfecto que depende de que alguien mantenga un desarrollo cada vez que cambie una API de terceros.

¿Cuándo deja de compensar la plataforma?

El punto de inflexión no llega por volumen ni por número de usuarios. Llega cuando el coste de doblar la herramienta para que haga algo que no fue diseñada para hacer supera el coste de construirlo.

Se reconoce por señales bastante claras. Cuando la configuración empieza a acumular apaños encadenados que nadie sabe explicar en una frase. Cuando hay que pagar tres productos distintos porque ninguno hace el conjunto y la factura mensual sumada empieza a parecerse a una cuota de desarrollo. Cuando el proceso más importante de la empresa depende de un límite del plan contratado. O cuando el negocio hace algo que ninguna herramienta del mercado contempla, porque es precisamente eso lo que lo diferencia de la competencia.

Si lo que te hace ganar dinero es justo lo que ninguna herramienta sabe hacer, ahí es donde tiene sentido construir. En el resto, configura.

El error de calcular solo el precio de entrada

Las comparaciones que circulan por internet enfrentan una cuota mensual contra un presupuesto de desarrollo y concluyen lo obvio. Esa cuenta está incompleta en las dos direcciones.

Por el lado de la plataforma faltan el coste de las licencias cuando el equipo crece, el de los conectores intermedios que hacen falta para pegarla al resto de sistemas, y el riesgo de que el precio suba o el producto cambie de rumbo sin avisar. Por el lado del desarrollo a medida falta lo que casi nadie presupuesta: mantener eso vivo cuesta cada año entre un quince y un veinte por ciento de lo que costó construirlo. Un desarrollo de veinte mil euros implica un compromiso implícito de tres o cuatro mil al año, y quien no lo planifica acaba con un sistema abandonado en dos ejercicios.

El terreno intermedio, que es donde acaba casi todo

En la práctica, la mayoría de los proyectos bien planteados no eligen un extremo. Usan producto existente para lo que el mercado ya resuelve bien (facturar, cobrar, enviar correo, guardar documentos) y construyen una capa propia y pequeña justo en la parte que es específica del negocio. Esa capa suele ser mucho menor de lo que la empresa temía: no es una aplicación entera, son unos cuantos procesos y una base de datos que manda sobre las demás herramientas.

Este enfoque tiene una ventaja que no se ve hasta el segundo año. Como lo propio es poco, se puede sustituir sin drama. Y como lo estándar es estándar, se puede cambiar de proveedor sin reescribir nada.

Preguntas que conviene responder antes de decidir

  • ¿Este proceso va a cambiar mucho en los próximos dos años? Si la respuesta es sí, la plataforma da más margen de maniobra.
  • ¿Es este proceso lo que nos diferencia, o es administración que cualquier empresa del sector hace igual? Solo lo primero justifica construir.
  • ¿Quién lo va a mantener y con qué presupuesto anual? Si no hay una respuesta concreta, no toca desarrollar todavía.
  • Si mañana quisiéramos irnos, ¿qué nos llevamos? Con producto existente te llevas los datos. Con desarrollo propio te llevas todo, siempre que esté documentado y el código sea tuyo.

Nuestra posición

Somos agnósticos de herramienta y lo decimos sin épica: no ganamos nada por recomendar una plataforma concreta ni cobramos comisiones de ningún fabricante. Eso permite que la conversación empiece por el problema y no por el catálogo.

En la mayoría de los encargos que recibimos, la respuesta correcta resulta ser conectar bien lo que la empresa ya paga y construir muy poco. Cuando hace falta construir, se construye, se documenta y se entrega con las llaves. Pero llegar a esa conclusión el primer día, sin haber mirado lo que ya hay, es casi siempre un síntoma de que alguien está vendiendo horas.

Las dos vías están detalladas por separado: automatización sobre lo que ya existe y desarrollo a medida.

Plataforma o desarrollo a medida: cómo se decide — udae