Elegir entre una herramienta estándar y software a medida exige comprobar qué trabajo debe resolver el sistema. Una aplicación para clientes, un registro interno o un proceso comercial pueden necesitar soluciones distintas, aunque todas se describan como «necesitamos un software».
Una solución existente puede cubrir el recorrido con una configuración razonable. Conectar herramientas puede resolver el tramo que falta, a cambio de una integración que también necesita cuidado. Desarrollar permite construir funciones específicas, con un alcance, unas pruebas y una operación que hay que acordar.
El marco Configurar → Integrar → Desarrollar ayuda a formular las preguntas en ese orden. No obliga a contratar tres proyectos ni a agotar todas las herramientas del mercado: busca la alternativa menos compleja que resuelva el trabajo y permite pasar a otra cuando existe una limitación comprobada.
1. La respuesta directa: no siempre hay que desarrollar software
El principio que debe guiar la decisión es la proporcionalidad: usar la alternativa menos compleja que resuelva el trabajo con controles y continuidad suficientes. El desarrollo propio se valora cuando configurar o integrar soluciones existentes no permite sostener una necesidad diferencial y estable.
Antes de comparar las tres rutas, convierte la necesidad en un alcance con criterios de aceptación para que la decisión responda al mismo problema y no a etiquetas tecnológicas.
┌─────────────────────────────────────────────────────────────┐
│ PASO 1: CONFIGURAR (SaaS estándar) │
│ Comprobar primero la parametrización nativa. │
│ El proveedor opera el producto; la empresa configura su uso.│
└──────────────────────────────┬──────────────────────────────┘
│ Si el estándar no conecta datos
▼
┌─────────────────────────────────────────────────────────────┐
│ PASO 2: INTEGRAR (Conectores / iPaas No-Code) │
│ Conectar herramientas SaaS especializadas entre sí. │
│ Mantiene el SaaS estándar y añade lógica de enlace. │
└──────────────────────────────┬──────────────────────────────┘
│ Si existen límites insuperables
▼ en un proceso diferencial
┌─────────────────────────────────────────────────────────────┐
│ PASO 3: DESARROLLAR (Código a medida / Desarrollo propio) │
│ Construir software o módulos propios cuando el proceso │
│ es estable, diferencial y justifica inversión y operación. │
└──────────────────────────────┘
Las flechas representan preguntas de decisión, no la obligación de implantar cada opción antes de estudiar la siguiente.
Puedes examinar las tres posibilidades con estas preguntas:
- Configurar: Comprobar primero si una herramienta SaaS existente cubre el flujo sin forzar excepciones importantes.
- Integrar: Si una sola herramienta no cubre todo el flujo, conectar varias aplicaciones especializadas mediante conectores o capas de integración no-code/low-code.
- Desarrollar: Valorar código a medida para los bloques diferenciales y estables que las alternativas anteriores no resuelven con un coste y un riesgo aceptables.
Compara las tres vías con los mismos supuestos en la worksheet de decisión.
El Service Standard de GOV.UK plantea la misma disciplina sin prescribir una tecnología: justificar qué se compra y qué se construye, considerar el coste total de propiedad y conservar la capacidad de cambiar de dirección.
2. Paso 1 — Configurar: cuándo basta adaptar una herramienta estándar (SaaS)
El modelo SaaS (Software as a Service) permite acceder a aplicaciones maduras alojadas en la nube mediante el pago de cuotas periódicas de licencia.
Cuándo es la opción recomendada:
- Procesos comerciales estándar: La gestión de contactos, los pipelines de venta habituales, la emisión de facturas básicas o la gestión de tareas suelen compartir patrones entre empresas de servicios, pero el encaje debe comprobarse en cada operativa.
- Necesidad de empezar con una base ya operativa: La empresa configura un producto existente en vez de construir todas sus funciones. El tiempo real depende de datos, permisos, migración, integraciones y aceptación.
- Equipos que prefieren delegar la operación del producto: El proveedor mantiene el servicio común, mientras la empresa sigue siendo responsable de configuración, accesos, uso, datos, continuidad y encaje contractual.
Dónde están sus límites:
El inconveniente del SaaS es su rigidez estructural. Si tu empresa calcula sus tarifas mediante un algoritmo propio con decenas de variables interconectadas o gestiona la prestación de un servicio con reglas operativas muy particulares, intentar forzar esa lógica dentro de los campos personalizados de un CRM estándar puede resultar extremadamente farragoso o imposible.
3. Paso 2 — Integrar: cuándo el problema es que las herramientas no comparten datos
En muchos casos, la frustración de una pyme no se debe a que su software principal sea malo, sino a que funciona como una isla aislada del resto de la empresa. Aquí es donde entran las capas de integración y las plataformas no-code / low-code (como Make, n8n o conectores vía API).
Cuándo es la opción recomendada:
- Especialización por áreas: La empresa utiliza una herramienta excelente para captar formularios, un CRM probado para ventas y un programa especializado para la facturación.
- Eliminación de tareas administrativas manuales: Se busca evitar que los empleados tengan que copiar a mano nombres, teléfonos o datos de presupuestos de una pantalla a otra.
- Pruebas de concepto y automatizaciones ágiles: Permite conectar sistemas y comprobar una regla de trabajo antes de asumir un desarrollo propio más amplio.
Dónde están sus límites:
Una automatización no-code puede resolver bien un flujo acotado y seguir siendo frágil si acumula escenarios sin documentación, permisos, control de errores o responsable de mantenimiento. El límite no lo marca una cifra universal de ejecuciones: aparece cuando la lógica, el coste, la latencia, la observabilidad, la seguridad o la recuperación dejan de ser aceptables para el proceso.
Incluso las plataformas low-code empresariales requieren entornos, roles, políticas de datos y gobierno. La documentación de gobierno de Microsoft Power Platform sirve como ejemplo de esos controles; no implica que esa plataforma sea la opción adecuada para cualquier empresa.
4. Paso 3 — Desarrollar: señales de un proceso diferencial y propiedad técnica
El desarrollo de software a medida implica diseñar, programar y mantener una aplicación informática concebida exclusivamente para las especificaciones de tu empresa.
Señales operativas que justifican valorar el desarrollo a medida:
- Hay reglas propias que cambian el resultado: la forma de calcular, coordinar o entregar el servicio requiere un comportamiento concreto que las alternativas probadas no resuelven. Documenta esa diferencia; no basta afirmar que tu empresa es única.
- Barreras insuperables en el SaaS: Has intentado adaptar herramientas comerciales e integrar conectores, pero los límites de las APIs o la rigidez de las bases de datos imponen fricciones operativas inasumibles.
- Necesidad de activos y control definidos por contrato: La empresa necesita acordar propiedad del código específico, cuentas, datos, documentación, dependencias y capacidad de cambiar de proveedor. Encargar software no concede “control total” automáticamente.
Riesgos que debes ponderar:
Desarrollar software propio implica asumir el rol de "propietario de producto". La inversión no termina el día que se entrega la aplicación: requiere presupuestar mantenimiento continuo, corrección de errores, actualizaciones de seguridad y adaptaciones ante cambios tecnológicos.
5. Matriz cualitativa de comparación técnica y operativa
A la hora de sopesar las tres alternativas para un proceso concreto, evalúa esta matriz de impacto operativo:
| Criterio de decisión | 1. Configurar (SaaS) | 2. Integrar (No-Code / API) | 3. Desarrollar (A medida) |
|---|---|---|---|
| Inversión inicial | Configuración, migración y formación | Diseño, conectores, pruebas y control de errores | Definición, diseño, desarrollo, pruebas y despliegue |
| Coste recurrente | Licencias, soporte y cambios de plan | Operaciones, conectores, infraestructura y mantenimiento del flujo | Infraestructura, mantenimiento, seguridad y evolución |
| Tiempo de implantación | Depende de configuración, datos y adopción | Depende de APIs, reglas, pruebas y excepciones | Depende de alcance, incertidumbre, integraciones y aceptación |
| Encaje del proceso | Limitado por el modelo del producto | Amplía lo existente sin eliminar sus límites | Diseñado para el alcance acordado, no para cualquier cambio futuro |
| Mantenimiento técnico | El proveedor opera el producto; la empresa gobierna su configuración y uso | Responsabilidad compartida entre herramientas, integración y equipo | Debe asignarse por contrato y mantenerse después de la entrega |
| Riesgo de dependencia | Proveedor, formato de exportación y condiciones del servicio | Plataformas, conectores, credenciales y APIs | Equipo, documentación, arquitectura y componentes de terceros |
| Reversibilidad | Depende de exportación, contrato y alternativas | Depende de documentación, estándares y sustitución de conectores | Depende de propiedad, accesos, documentación y capacidad de otro equipo |
No conviertas esta matriz en una tarifa ni en un calendario. Para comparar propuestas reales, calcula por separado configuración o desarrollo, migración, licencias, infraestructura, mantenimiento, soporte, evolución y coste de salida. La guía sobre qué cambia un presupuesto de software a medida desarrolla esas partidas.
6. Errores habituales: sobredimensionar o forzar soluciones
- Error A: Encargar una aplicación sin concretar las reglas que debe sostener. Si todavía no están claros los responsables, estados o criterios de una decisión, conviene resolver esa parte del alcance antes de programarla. Algunas preguntas se pueden aprender con una primera capacidad pequeña; otras son necesarias para poder construirla y probarla.
- Error B: Querer resolverlo todo con hojas de cálculo y plugins gratuitos. Una combinación manual puede ser suficiente mientras tenga owner, copias, controles y alcance claros. Se vuelve un problema cuando nadie puede detectar errores, recuperar el proceso o sostenerlo al cambiar personas y herramientas.
- Error C: Ignorar la calidad del dato antes de elegir tecnología. Cambiar de herramienta no soluciona el desorden informativo. Si el equipo no registra datos consistentes, el problema se trasladará al SaaS, a la integración o al software a medida. Para profundizar, consulta el artículo sobre calidad de datos en el CRM.
7. Ejemplos hipotéticos de decisión operativa
Estos escenarios son ilustrativos y no describen clientes ni resultados observados:
Escenario Hipotético 1: Despacho profesional de servicios estándar
- Situación: Empresa que gestiona clientes con un ciclo de venta estándar (solicitud → reunión → propuesta → contrato).
- Decisión recomendada: Configurar SaaS. Contratar un CRM comercial probado en la nube, adaptar sus pipelines y campos personalizados, y formar al equipo en su uso. No se justifica ningún desarrollo a medida.
Escenario Hipotético 2: Pyme industrial con cotizador diferencial
- Situación: Empresa de mecanizado o servicios técnicos donde cada propuesta requiere calcular costes de materiales, tiempos de máquina y tolerancias mediante una fórmula propia desarrollada durante años.
- Decisión recomendada: Modelo Híbrido (Configurar + Desarrollar un módulo específico). Utilizar un CRM SaaS estándar para gestionar la relación comercial y los contactos (Configurar), y desarrollar a medida exclusivamente la herramienta interna de cotización técnica, conectando ambas partes mediante API (Integrar).
Un ejemplo que puedes usar para probar el encaje
Imagina un Cuaderno de equipo donde se registran decisiones de proyectos: título, motivo, alternativas y estado. Es un ejemplo ficticio. Una propietaria administra, una editora trabaja en el contenido y una lectora consulta. El equipo necesita guardar, encontrar y exportar lo registrado.
La pregunta inicial no es qué tecnología tiene mejores funciones. Es si puedes completar este pequeño recorrido:
- Crear un proyecto y una decisión con su motivo.
- Dar lectura a una persona sin permitirle modificarla.
- Corregir la decisión con un perfil que sí puede hacerlo.
- Encontrar esa decisión después de volver al sistema.
- Exportar el contenido que necesitarías conservar al salir.
| Alternativa | Prueba que haría | Qué podría cambiar la decisión |
|---|---|---|
| Configurar una herramienta de documentos o proyectos | Representar los campos, permisos y búsqueda; revisar una exportación | Un estado que no se puede expresar, permisos insuficientes o una exportación que pierde relaciones necesarias |
| Conservar la herramienta y añadir una integración o módulo | Resolver solo el tramo ausente, con datos de prueba | Dependencia de una API, duplicados, recuperación de fallos o coste de sostener dos sistemas |
| Desarrollar el Cuaderno | Acordar los recorridos, datos, permisos y aceptación de la primera versión | El esfuerzo de construir y operar no se justifica si otra solución ya cumple suficientemente |
La tabla no declara las capacidades de un producto concreto. Describe qué comprobar en cada opción. Si una herramienta cumple el recorrido y sus límites te sirven, esa es evidencia para configurarla. Si falla una condición esencial, escribe el fallo y prueba si puede resolverse sin crear una dependencia desproporcionada.
La guía de GOV.UK sobre productos estándar recomienda probar alternativas después de comprender la necesidad y evaluar el servicio completo, también cuando se compra un producto existente. Su contexto es el servicio público británico; la pregunta práctica aquí es si tu recorrido funciona en la opción elegida.
Comparar también lo que ocurre después
Una cuota mensual y un desarrollo inicial no se comparan solo con sus primeras cifras. Define el periodo que quieres estudiar y separa configuración o construcción, licencias, alojamiento, integraciones, mantenimiento, trabajo de tu equipo y salida. Si una partida no está concretada, déjala visible como pendiente.
También puedes escoger una solución provisional con una salida preparada. Por ejemplo, empezar con campos y estados sencillos, comprobar que se exportan y posponer reglas que aún no están claras. No se trata de prometer una migración sin coste: se trata de conocer qué conservarías y qué habría que transformar.
El asistente para elegir solución ordena estas preguntas. La matriz de comparación ayuda cuando ya tienes alternativas concretas; la guía para encargar software conecta elección, presupuesto y entrega.
8. Checklist de decisión para tu empresa
Utiliza este cuestionario para determinar qué ruta tecnológica exige tu proyecto actual:
Próximos pasos
Si tu empresa necesita analizar un proceso operativo o comercial para determinar qué alcance tecnológico le conviene (si basta con configurar un CRM, conectar herramientas o si se justifica un desarrollo específico), explora nuestro servicio de consultoria CRM.
Si tras el diagnóstico se confirma que la empresa cuenta con un proceso diferencial, estable y valioso que requiere la construcción de componentes propietarios, puedes consultar las capacidades de nuestro servicio de CRM a medida o desarrollo de software a medida, orientados siempre a proyectos con viabilidad técnica y operativa demostrada.
Si la decisión consiste en validar una primera versión acotada, revisa el enfoque de desarrollo MVP. Si el producto debe operar como una plataforma recurrente para usuarios o clientes, consulta los criterios de desarrollo SaaS. Son recorridos distintos y no deberían presupuestarse como si fueran el mismo proyecto.
Para entender cómo aplicar este marco desde la perspectiva del proceso de ventas, te recomendamos revisar nuestra guía de implantación de CRM para empresas.