Escrito por
Nacho Seoane
Publicado el
Compartir
Conviene empezar por un SaaS cuando una herramienta existente resuelve el proceso esencial y sus límites son aceptables para tu equipo. El software a medida merece evaluarse cuando una necesidad importante queda sin resolver, el proceso está definido y puedes sostener su operación. Entre ambos caminos, una integración puede evitar que tengas que construirlo todo.
La decisión se aclara al ejecutar el mismo trabajo con cada opción. Esta guía propone una matriz para hacerlo: qué debe ocurrir, dónde queda el resultado y cuánto trabajo manual permanece.
TL;DR — Comprar, integrar o desarrollar
- Describe el trabajo antes de comparar productos. Una lista de funciones sin contexto no demuestra que el proceso termine bien.
- Prueba una herramienta existente. Puede resolver el núcleo aunque necesites ajustar alguna tarea secundaria.
- Evalúa una integración acotada. A veces falta conectar dos sistemas, no sustituirlos.
- Reserva el desarrollo para una necesidad concreta. Que un proceso sea diferente no significa que esa diferencia aporte valor.
- Compara el coste completo. Incluye configuración, migración, licencias, soporte y trabajo interno.
- Comprueba cómo seguirás operando. Exportación de datos, documentación y mantenimiento forman parte de la decisión.
Qué estás comparando realmente
Estás comparando formas de resolver un proceso, con distintas responsabilidades y restricciones. Un SaaS es un servicio de software ofrecido por un proveedor. Un desarrollo a medida se diseña para un alcance específico. Una solución integrada combina herramientas existentes con conexiones o componentes propios.
La guía de compras tecnológicas de GOV.UK distingue entre necesidades cubiertas por productos comerciales y situaciones que requieren construir, adaptar o integrar. También considera la capacidad de la organización para sostener la solución. Es una referencia de contratación pública británica; utilizamos ese criterio técnico de evaluación, no sus reglas de contratación como obligación para una empresa española. GOV.UK: estrategia de compra tecnológica.
Supongamos una empresa de servicios que recibe encargos, solicita materiales y recoge aprobaciones. Puede que su gestor de proyectos ya resuelva la coordinación interna y que solo falte una pantalla sencilla para el cliente. Antes de sustituirlo, conviene probar esa combinación. Es un ejemplo hipotético, no un caso de cliente.
Si esa es tu necesidad concreta, también puedes revisar cuándo crear un portal de clientes. Aquí nos centraremos en la decisión de compra y en cómo comprobar las alternativas.
Matriz para comparar las opciones con el mismo caso
Completa la tabla observando una prueba, en lugar de marcar funciones que aparecen en una presentación comercial. Copia una columna por candidato y registra una evidencia junto a cada respuesta.
| Prueba | Qué debe demostrarse | Respuesta que conviene registrar |
|---|---|---|
| Recorrido principal | Un encargo avanza desde su entrada hasta su cierre | Pasos completados y pasos manuales |
| Excepción habitual | Se resuelve un material incompleto o una aprobación rechazada | Quién interviene y dónde queda registrado |
| Acceso del cliente | Cada persona ve los elementos que le corresponden | Resultado de la prueba con dos cuentas |
| Conexión necesaria | La información llega al otro sistema sin copiarla a mano | Campos transferidos y tratamiento de errores |
| Cambio pequeño | Se modifica una regla frecuente del proceso | Responsable, esfuerzo y dependencia externa |
| Recuperación de datos | Se obtiene una exportación utilizable del alcance necesario | Archivo, relaciones y limitaciones comprobadas |
| Operación posterior | Hay una forma de atender fallos y actualizar la solución | Responsable y condiciones de soporte |
Marca cada resultado como resuelto, requiere adaptación, no resuelto o no comprobado. El último estado importa: una función anunciada no debe contar como verificada si nadie ha podido probarla.
No hace falta convertir la tabla en una puntuación pretendidamente científica. Señala primero los requisitos imprescindibles. Una alternativa que no cubre uno de ellos necesita una solución viable antes de competir por precio o presentación.
Cuándo suele encajar una herramienta existente
Una herramienta existente merece ser la primera prueba cuando el trabajo es común y el equipo puede operar con sus reglas. Gestión de tareas, reservas o seguimiento comercial pueden tener alternativas maduras, pero el encaje se demuestra con tu recorrido concreto.
Durante la prueba, observa dónde aparecen hojas de cálculo paralelas, dobles registros o pasos que solo conoce una persona. Pueden ser una configuración incompleta, una necesidad de formación o una limitación real. No atribuyas todo problema al producto antes de distinguir esas causas.
También importa el coste de adaptar tu organización. Un pequeño cambio de hábito puede ser razonable. Mantener indefinidamente una operación manual crítica para compensar una limitación exige una decisión consciente. Registra qué cambia, quién lo hace y con qué frecuencia; así podrás comparar alternativas sin depender de impresiones.
Cuándo tiene sentido desarrollar una parte a medida
Desarrollar merece estudiarse cuando puedes explicar qué necesidad importante sigue abierta y cómo comprobarás que la solución la cubre. El argumento no debería quedarse en “queremos algo nuestro”.
Antes de definir pantallas, dibuja los componentes que ya tienes y la información que intercambian. El Service Manual de GOV.UK propone mapear el entorno tecnológico para entender qué construir y qué comprar, y mantener control sobre los datos. GOV.UK: elegir tecnología.
En el ejemplo de encargos, quizá el componente propio sea únicamente una pantalla de aprobación conectada al gestor actual. Para decidirlo, el prototipo debe permitir al cliente revisar una entrega, aceptar o pedir cambios y comprobar que el equipo recibe la decisión donde trabaja.
Nuestra recomendación es empezar por el fragmento que permite validar la necesidad pendiente. El alcance de esa primera entrega puede presupuestarse siguiendo la guía de coste de un MVP. Un producto completo con funciones todavía hipotéticas dificulta evaluar si acertaste con el problema.
Cómo comparar el coste sin olvidar el trabajo interno
Compara las opciones durante el mismo periodo y con los mismos supuestos de uso. El importe inicial de desarrollo y una mensualidad de software representan partidas diferentes.
Puedes preparar una hoja con esta cuenta de trabajo:
Coste del periodo = puesta en marcha + licencias e infraestructura + soporte y cambios + trabajo interno + transición prevista.
La puesta en marcha puede incluir configuración, migración y formación en cualquiera de las alternativas. Para el trabajo interno, utiliza horas observadas o una estimación claramente identificada. Para los cambios, describe qué incluyen las condiciones contratadas y qué se presupuestaría aparte.
Completa dos escenarios con tus propios datos: el volumen actual y un volumen mayor que tenga sentido para tu negocio. Revisa si cambian usuarios, almacenamiento, operaciones o necesidades de soporte. No existe una cifra universal de empleados o una mensualidad a partir de la cual desarrollar resulte automáticamente más barato.
Qué hay que prever después de la entrega
La solución necesita una persona responsable de cambios, pruebas y continuidad, sea propia o de un proveedor. Comprar software no elimina toda tarea operativa; desarrollar sobre una plataforma tampoco evita el mantenimiento.
Microsoft describe la gestión del ciclo de vida de aplicaciones en Power Platform mediante gobierno, desarrollo y mantenimiento, incluyendo pruebas, despliegue y seguimiento. Esto ayuda a entender por qué una aplicación creada con herramientas visuales también necesita un proceso de operación. Microsoft: ciclo de vida de aplicaciones.
Pide una demostración de la exportación que necesitarías al cambiar de solución. Comprueba qué ocurre con adjuntos, relaciones y estados, además de la lista principal de registros. Para un desarrollo, aclara dónde están el código, la documentación y las cuentas necesarias. Son preguntas para definir la entrega y la continuidad; las condiciones concretas deben quedar acordadas en la propuesta.
Preguntas frecuentes
Estas preguntas evitan convertir una decisión de proceso en una preferencia tecnológica.
¿El software a medida es siempre más caro?
No puede decidirse comparando solo el desarrollo inicial con una mensualidad. Necesitas el mismo alcance, periodo y volumen. Incluye el trabajo manual que permanece y las adaptaciones. Sin esos datos, decir que una alternativa será más barata es una hipótesis.
¿Puedo empezar con un SaaS y desarrollar después?
Sí, si preparas la continuidad desde el principio. Comprueba cómo recuperar los datos y qué integraciones necesitarás. Documenta las reglas del proceso para que no queden únicamente en configuraciones que nadie entiende. La migración futura sigue siendo un trabajo que habrá que planificar.
¿Una herramienta no-code equivale a un SaaS listo para usar?
No necesariamente: puede ser la plataforma con la que construyas tu propia aplicación. En ese caso alguien tendrá que definir el modelo de datos, las reglas, las pruebas y las actualizaciones. Evalúa esas responsabilidades aunque no escribas código tradicional.
¿Cuántas funciones debe cubrir la herramienta para elegirla?
Importa cuáles cubre, no un porcentaje fijo. Una función secundaria ausente puede ser aceptable; un requisito imprescindible sin resolver puede invalidar el encaje. Usa la matriz para separar necesidades esenciales de preferencias y comprobar las adaptaciones necesarias.
¿Qué hago si todavía estamos cambiando el proceso?
Reduce primero la incertidumbre con una prueba limitada. Documenta qué decisiones cambian y por qué. Puedes ensayar el recorrido con una herramienta existente o un prototipo antes de desarrollar una solución amplia. El objetivo es aprender qué necesitas sostener, no convertir cada versión provisional en software definitivo.
Recomendación final
Prueba una alternativa existente y una solución acotada para la necesidad que no cubre, utilizando la misma matriz. Si la herramienta resuelve el trabajo con una adaptación razonable, esa es una opción válida. Si aparece una limitación esencial, tendrás evidencia concreta para diseñar y presupuestar el componente propio.
En resumen
- Empieza por el recorrido de trabajo. Debe tener una entrada y un resultado verificable.
- Prueba las alternativas con el mismo caso. Así la comparación deja de depender de una demostración comercial.
- Separa lo imprescindible. Una función crítica pesa más que varias comodidades.
- Considera integrar. Puede bastar con conectar lo que ya funciona.
- Compara el coste completo. Incluye operación y trabajo interno.
- Comprueba la continuidad. Los datos y el conocimiento del proceso deben seguir siendo utilizables.
- Desarrolla con una necesidad demostrada. El primer alcance debe resolver una carencia concreta.
Fuentes y referencias
Las referencias aportan criterios de compra y operación; la matriz es una propuesta propia para comparar proveedores. Consultadas el 5 de noviembre de 2026.
- GOV.UK: estrategia de compra tecnológica.
- GOV.UK: elegir tecnología.
- Microsoft: ciclo de vida de aplicaciones.
El siguiente paso
Trae el proceso que hoy resolvéis con herramientas y tareas manuales. Desde desarrollo de producto podemos definir la prueba y el alcance que falta. Cuéntanos qué necesitas resolver.
