Cuándo desarrollar un software a medida: un árbol de decisión

Desarrolla un software a medida cuando el proceso es de verdad tuyo, cuando ningún producto del mercado lo cubre sin apaños, y cuando tienes horizonte para usarlo durante años. Compra cuando una herramienta estándar ya encaja, o cuando el proceso es común a todas las empresas de tu sector. Todo lo demás es cuestión de criterio, y ese criterio es lo que resuelves aquí abajo.

Nuestra guía principal del desarrollo de software a medida cubre coste, método y plazos de punta a punta; aquí profundizamos en una sola de sus preguntas, cuándo desarrollar un software a medida en lugar de suscribirte a algo que casi encaja. Lo que sigue es un árbol de decisión que puedes aplicar a tu situación real, cinco casos sacados de decisiones reales entre desarrollar y comprar, y una lista honesta de motivos para esperar.

El árbol de decisión desarrollar o comprar: cuatro preguntas en orden

Recórrelas en orden. Cada pregunta cierra la decisión o te pasa a la siguiente. Saltarse etapas es como las empresas se convencen de desarrollos que no necesitaban, o de suscripciones que les cuestan dinero en silencio durante años.

Pregunta 1: ¿es un proceso genérico?

Las nóminas, la contabilidad, el correo electrónico y las agendas son problemas resueltos. Los necesita todo el mundo y funcionan casi igual en todas partes. Si tu respuesta es sí, párate aquí y compra. Ningún desarrollo a medida gana a un producto maduro en un proceso donde nadie se diferencia.

Si el proceso es propio de cómo funciona tu empresa de verdad, pasa a la pregunta dos.

Pregunta 2: ¿una herramienta del mercado lo cubre al 90 % o más, y limpiamente?

No "lo cubre si adaptamos nuestro proceso al software". Lo cubre tal como tu proceso funciona ya, sin una hoja de cálculo paralela, sin un paso manual de exportar y reformatear, sin un apaño que alguien mantiene de memoria. Si una herramienta te lleva de verdad hasta ahí, cómprala y sigue adelante. Una capa fina a medida montada sobre un producto que encaja al 90 % suele salir más barata que un desarrollo completo, y merece un presupuesto aparte.

Si el hueco es el apaño en sí, la doble captura de datos, el paso de corrección manual, pasa a la pregunta tres.

Pregunta 3: ¿este proceso es tu ventaja competitiva?

Hay huecos que molestan pero que tus clientes no ven jamás. Otros son justo lo que hace que un cliente te elija a ti antes que al siguiente proveedor: tu rapidez presupuestando, tu fiabilidad preparando pedidos, tu capacidad de resolver la excepción con la que el software del competidor se atraganta. Si el hueco vive donde solo lo nota tu equipo de operaciones, inclínate igualmente por comprar, o prueba antes una capa low-code. Si el hueco vive en el proceso que te gana clientes, pasa a la pregunta cuatro.

Pregunta 4: ¿tienes tres años o más por delante para usarlo?

Un desarrollo a medida es un activo de varios años, no una compra puntual. Tiene que devolver su coste frente al apaño que sustituye, y esa cuenta necesita tiempo para salir. Si tu equipo, tu proceso o el rumbo de tu empresa pueden cambiar mucho en un año o dos, la respuesta aquí es todavía no, que no es lo mismo que nunca. Si el proceso seguirá existiendo más o menos con su forma actual dentro de tres años o más, desarrolla.

Cruza las cuatro puertas y la decisión es desarrollar. Falla una sola y la respuesta honesta es comprar, esperar, o parchear con una capa low-code. Los casos de abajo enseñan cómo se juega esto con peticiones reales.

Cinco casos: qué dice el árbol en la práctica

Caso 1: la herramienta de presupuestos de un distribuidor. Veredicto: desarrollar. Un distribuidor de 40 personas presupuesta a cada cliente contra rappels por volumen, condiciones pactadas cliente a cliente y recargos de transporte que cambian según la ruta. Ninguna herramienta estándar de presupuestación modela las tres cosas a la vez sin una hoja de cálculo mantenida detrás. El hueco es esa hoja: dos personas la actualizan a mano, y un tramo mal aplicado se come margen en cada pedido que toca. La rapidez y la precisión presupuestando son justo lo que los clientes notan, así que es un proceso de ventaja competitiva con tres años largos de vida por delante. Desarrollar.

Caso 2: nóminas y registro de jornada de una agencia de 15 personas. Veredicto: comprar. Nada de cómo esta agencia paga las nóminas se diferencia de cualquier otra empresa de 15 personas. El convenio marca las tablas salariales, la Seguridad Social marca las cotizaciones y los trámites, y la ley obliga al registro diario de jornada desde 2019. Un software de nóminas del mercado (A3, Factorial, Sage), con la gestoría detrás, cubre el ciclo completo (nóminas, cotizaciones, retenciones de IRPF, transferencias y control horario) sin un solo apaño. Nadie construye su propio cálculo de cotizaciones: la norma cambia cuando lo decide el legislador, y cargarías tú solo con el coste de cada actualización. Esto falla la pregunta uno de plano. Comprar aquí no es una concesión: es la respuesta correcta, y el dinero ahorrado vuelve al proceso que sí diferencia a la empresa.

Caso 3: un cuadro de mando interno alimentado por cuatro herramientas SaaS. Veredicto: todavía no, pasa por el low-code. Un equipo de operaciones quiere un solo cuadro de mando en lugar de cuatro accesos. La necesidad de reporting es real, pero nadie sabe todavía qué indicadores importarán una vez reestructurado el equipo el próximo trimestre, y las propias herramientas SaaS de debajo podrían cambiar. Esto supera la pregunta dos (ningún cuadro de mando del mercado cubre una mezcla propia de cuatro herramientas) y encalla en la pregunta cuatro: el horizonte es incierto. Una plataforma low-code (Retool, Power Apps y similares se mueven en un mercado que Gartner proyecta en crecimiento hacia los 44.500 millones de dólares en 2026) pone un cuadro de mando en marcha en unos días y se rehace a bajo coste cuando el equipo tome su forma definitiva. Revisa el desarrollo a medida cuando los requisitos de reporting hayan aguantado dos trimestres seguidos.

Caso 4: un panel de expediciones para una flota mixta. Veredicto: desarrollar. Un transportista regional usa un sistema de gestión de transporte (TMS) estándar que resuelve bien la expedición de un solo modo, pero se rompe con las excepciones multimodales que su flota vive a diario: una carga que pasa de camión a tren a mitad de ruta, un cambio de conductor que el software no sabe representar sin una nota manual. La precisión en la expedición es el diferenciador real de la empresa frente a competidores más grandes y menos flexibles. La composición de la flota no va a cambiar pronto. Todas las puertas pasan. Desarrollar. Si además opera cruzando frontera, conviene leer antes por qué falla el software fuera de su mercado, porque las fechas, las divisas y los documentos de aduana rompen desarrollos que en un solo país iban finos.

Caso 5: un portal de clientes para una startup de dos personas sin ingresos. Veredicto: todavía no. Un fundador quiere un portal de clientes pulido antes incluso de tener clientes de pago que validen qué funciones necesita ese portal. Los requisitos siguen moviéndose cada semana, nadie ha hecho rodar el flujo real con clientes el tiempo suficiente para describirlo con precisión, y aún no hay ingresos para financiar tres años de uso. Esto falla la pregunta cuatro por un motivo estructural: no existe un proceso estable sobre el que amortizar un desarrollo. Una herramienta gratuita o un simple formulario hace entrar a los primeros clientes; el portal de verdad se construye cuando el flujo deje de cambiar en cada sprint.

Señales de que aún no deberías desarrollar un software a medida

Un texto que solo te dice cuándo desarrollar no está jugando limpio contigo. Algunas de las señales de compra más claras se caen en cuanto las miras de cerca.

• Todavía no sabes describir el proceso en un folio. Si poner por escrito "cómo debería funcionar la presupuestación" saca a la luz un desacuerdo dentro de tu propio equipo, el software a medida no resolverá ese desacuerdo: lo grabará en piedra. Cierra el proceso en papel primero, aunque sea en una hoja de cálculo, antes de pagar por codificarlo.
• Desarrollas porque un competidor lo hizo, no por un dolor tuyo. Copiar la herramienta del vecino sin tener tu propio apaño, tu propio coste y tu propia queja de cliente detrás suele significar que estás resolviendo el problema de otro. Encuentra tu versión del hueco antes de encargar la solución.
• El apaño no te ha costado nada que sepas señalar. "Esto nos fastidia" no es lo mismo que "esto nos cuesta doce horas a la semana y una factura mal pagada al mes". Si no sabes nombrar el coste, probablemente tampoco puedas justificar el desarrollo. Mídelo durante un mes: el número te justifica el proyecto o te quita las ganas.
• Nadie tiene el mantenimiento asignado, ni en tu casa ni en la del proveedor. Después del lanzamiento alguien tiene que atender la siguiente petición de función, vigilar la próxima integración que se rompe y decidir qué cambia y qué no. En España eso significa decidir de antemano si lo asume alguien en plantilla con contrato indefinido, un autónomo de confianza (con cuidado si acaba dependiendo de ti casi en exclusiva y entra en terreno TRADE), o una consultora con un contrato de mantenimiento firmado. Un desarrollo sin dueño por ninguna de las dos partes se degrada en silencio hasta que nadie se fía de él.

Si dos o más de estas señales describen tu situación, espera. Arregla el problema barato (el proceso, la visibilidad del coste, la pregunta de quién lo mantiene) antes de arreglar el caro.

Preguntas frecuentes sobre desarrollar o comprar software

¿Cómo sé si debo desarrollar un software a medida o comprarlo?

Compra si una herramienta estándar cubre tu proceso sin apaños, o si el proceso es común a todas las empresas. Desarrolla cuando el proceso es propio tuyo, el hueco cuesta caro, ese proceso es tu ventaja competitiva y mantendrá su forma actual durante tres años o más.

¿En qué consiste el marco de decisión entre desarrollar y comprar?

Una secuencia de cuatro preguntas: ¿es el proceso genérico, lo cubre limpiamente una herramienta del mercado, es tu ventaja competitiva, y tienes tres años o más para usarlo? Desarrolla solo si cada pregunta apunta a desarrollar; un solo no apunta a comprar o esperar.

¿El software a medida siempre es más caro que comprar software estándar?

A lo largo del tiempo, no. Una suscripción parece más barata mes a mes, pero acumulada entre varias herramientas durante tres años supera a menudo un desarrollo a precio cerrado, sobre todo una vez contadas las licencias por usuario y las horas de apaño. La cifra de hoy y la cifra a tres años apuntan a menudo en direcciones opuestas.

¿Cuánto tiempo debo esperar antes de desarrollar un software a medida?

Espera a que el proceso que quieres codificar haya mantenido más o menos la misma forma durante un par de trimestres, y a que sepas nombrar un coste concreto que crea el apaño actual. Desarrollar contra un proceso que aún cambia cada semana suele significar rehacerlo en menos de un año.

¿Puedo empezar con software del mercado y pasar al a medida más tarde?

Sí, y muchas veces es la secuencia correcta. Una herramienta del mercado o low-code valida rápido y barato que un proceso merece un desarrollo. Cuando el coste del apaño esté claro y el proceso se haya estabilizado, el desarrollo a medida sustituye el parche por una herramienta tallada a la forma exacta de cómo trabajas.

Pasa tu propia situación por este árbol

Descríbenos el proceso, la herramienta que usas hoy y el sitio donde aparece el apaño, y te diremos con franqueza de qué lado del árbol caes. Si toca desarrollar, recibes un alcance cerrado, un paquete a precio cerrado y una fecha de entrega medida en semanas, con el método que describimos en cómo cerramos el alcance, construimos y revisamos. Si antes quieres calibrar cifras, mira lo que cuesta de verdad un software a medida. Si toca comprar, te lo decimos igual.

Pide un presupuesto cerrado →