Elegir una empresa de desarrollo de software a medida no consiste solamente en comparar portafolios, tecnologías y precio. La decisión define cómo se traducirá un proceso del negocio en reglas, datos, permisos, interfaces y responsabilidades que deberán mantenerse durante años.
Un proveedor puede escribir código correctamente y aun así construir una solución difícil de adoptar. Otro puede ayudar a reducir alcance, probar primero el riesgo principal y dejar una base operable. La diferencia aparece en el proceso de descubrimiento, la claridad de los entregables y la forma de tratar seguridad, propiedad, pruebas y continuidad.
Antes de solicitar propuestas, conviene preparar el problema y saber qué evidencia debe producir el proveedor en cada etapa.
Primero: confirma que necesitas desarrollo a medida
El software propio suele tener sentido cuando:
- el proceso es estable y relevante para el negocio;
- las reglas particulares no caben razonablemente en una herramienta existente;
- varias adaptaciones y tareas paralelas ya generan fricción recurrente;
- se necesitan integraciones, permisos o trazabilidad específicos;
- existe una persona responsable de priorizar el producto;
- la empresa puede sostener operación y evolución después del lanzamiento.
No todo problema requiere construir. También puedes ordenar el proceso, configurar un SaaS o integrar herramientas existentes. La guía software a medida vs. SaaS compara esas rutas con un horizonte de costo total.
Evidencia de capacidad
Qué debe demostrar el proveedor
- Entiende el problema operativo
- Reduce incertidumbre por etapas
- Define aceptación y propiedad
- Prepara mantenimiento y adopción
1. Define el problema sin describir la solución
Un buen brief inicial explica síntomas y consecuencias:
- “tres equipos capturan el mismo pedido en sistemas distintos”;
- “no podemos saber qué versión de una autorización está vigente”;
- “la preparación de cada cotización requiere consolidar cinco archivos”;
- “el cliente no puede consultar estado sin llamar”;
- “las reglas de asignación ya no caben en la herramienta actual”.
Evita comenzar con “necesitamos una app con inteligencia artificial”. Esa frase adelanta una solución antes de conocer usuarios, datos, excepciones y resultado esperado.
Para cada problema, registra:
- personas afectadas;
- frecuencia y volumen;
- costo o riesgo operativo;
- flujo actual;
- sistemas involucrados;
- restricciones;
- resultado observable que indicaría mejora.
2. Evalúa el descubrimiento del proveedor
Una empresa seria no debería cotizar un sistema complejo solo con una llamada superficial. Necesita descubrir:
- objetivos y límites;
- usuarios y permisos;
- etapas del proceso;
- reglas y excepciones;
- datos existentes;
- integraciones;
- requisitos de seguridad;
- condiciones de aceptación;
- responsables del lado del cliente.
El descubrimiento puede ser una fase pagada y separada. Eso no es necesariamente un costo adicional improductivo: puede producir mapa de proceso, alcance, riesgos, prototipo y plan que reduzcan incertidumbre antes de comprometer el desarrollo completo.
Pregunta qué entregables recibirás y si podrás utilizarlos aunque decidas no continuar con el mismo equipo.
3. Compara experiencia por tipo de problema
Un portafolio visual muestra interfaces, pero no siempre revela complejidad operativa. Busca evidencia relacionada con:
- roles y permisos;
- flujos de aprobación;
- integraciones;
- migración de datos;
- reportes;
- operación con fallas;
- seguridad;
- mantenimiento.
No es indispensable que el proveedor haya trabajado en tu industria exacta. Sí debe demostrar cómo entiende procesos, restricciones y riesgos parecidos.
Cuando revises un caso, pregunta cuál era el problema, qué parte construyó el equipo, cómo midieron aceptación y quién mantiene la solución. Evita tomar logotipos sin contexto como prueba suficiente.
4. Revisa cómo propone reducir riesgo
Una propuesta sólida separa el proyecto en resultados verificables. Puede comenzar con:
- prototipo para validar flujo;
- prueba de integración;
- migración de una muestra sintética;
- módulo prioritario;
- piloto con un grupo de usuarios;
- versión mínima con un proceso completo.
Un MVP no es una colección de pantallas incompletas. Debe resolver de principio a fin un problema acotado y producir aprendizaje útil.
Pregunta qué incertidumbre reduce cada etapa y qué decisión podrá tomarse al terminarla.
5. Exige un alcance verificable
El documento de alcance debería identificar:
- usuarios y roles;
- funciones incluidas;
- reglas principales;
- datos y fuentes;
- integraciones;
- ambientes;
- criterios de aceptación;
- entregables;
- exclusiones;
- dependencias del cliente;
- proceso para cambios.
“Panel administrativo” no es un requisito verificable. “Un usuario con rol supervisor puede reasignar una solicitud y el sistema registra responsable anterior, nuevo responsable, fecha y motivo” sí permite diseñar y probar.
6. Entiende el modelo de trabajo y precio
Los modelos comunes incluyen:
Precio fijo por alcance
Ayuda a presupuestar cuando los requisitos son estables. Los cambios necesitan un mecanismo explícito.
Tiempo y materiales
Permite ajustar prioridades durante el desarrollo. Requiere visibilidad de horas, avance y presupuesto.
Equipo o capacidad mensual
Puede servir para evolución continua. Debe aclarar roles, disponibilidad, gobierno y resultados esperados.
Ningún modelo elimina la incertidumbre. Compara también licencias, infraestructura, migración, soporte, monitoreo, seguridad y costo de salida. Una cotización inicial baja puede trasladar responsabilidades al mantenimiento.
7. Revisa propiedad y acceso
Antes de firmar, define por escrito:
- propiedad o licencia del código;
- propiedad y portabilidad de los datos;
- acceso a repositorios;
- cuentas de nube y servicios externos;
- dominios y certificados;
- documentación;
- componentes de terceros y sus licencias;
- procedimiento de entrega al terminar.
La empresa no necesita operar cada herramienta desde el primer día, pero debe saber qué controla, qué licencia y de qué proveedor depende.
8. Incluye seguridad desde la compra
La guía Secure by Demand de CISA propone incorporar requisitos de seguridad a la adquisición, en lugar de tratarlos solo después de comprar. Para un desarrollo empresarial, pregunta:
- ¿cómo se gestionan usuarios y privilegios?
- ¿cómo se protegen secretos y credenciales?
- ¿qué registros de actividad existen?
- ¿cómo se corrigen vulnerabilidades?
- ¿qué dependencias se utilizan y actualizan?
- ¿cómo se separan desarrollo, pruebas y producción?
- ¿qué respaldo y recuperación se contempla?
- ¿cómo se notifican y atienden incidentes?
- ¿qué datos sensibles procesa el sistema?
Los requisitos exactos dependen del riesgo y del sector. Si el sistema trata información regulada o crítica, incorpora una revisión especializada.
9. Define pruebas y aceptación
“El sistema funciona” necesita evidencia. Un plan de aceptación debería cubrir:
- flujo normal;
- permisos por rol;
- validaciones;
- duplicados;
- errores de integración;
- concurrencia cuando sea relevante;
- restauración de respaldo;
- rendimiento bajo volumen esperado;
- accesibilidad de las interfaces;
- dispositivos o navegadores soportados;
- migración y conciliación de datos.
Cada entrega necesita criterios acordados, un ambiente de prueba y un procedimiento para reportar y corregir defectos.
10. Considera adopción y cambio operativo
El software altera responsabilidades. Define:
- quién capacita;
- qué documentación reciben los usuarios;
- quién administra catálogos y permisos;
- qué proceso anterior deja de usarse;
- cómo se migran pendientes;
- qué canal recibe dudas;
- cómo se incorporan mejoras.
Mantener indefinidamente hojas y sistemas paralelos puede destruir la fuente de verdad. La transición debe tener reglas y fecha.
Si el punto de partida son archivos compartidos, revisa cuándo Excel deja de ser suficiente. Algunas señales justifican software; otras se resuelven con mejor gobierno o una herramienta estándar.
11. Evalúa mantenimiento y soporte
Después del lanzamiento habrá:
- altas y bajas de usuarios;
- cambios en reglas;
- actualizaciones de dependencias;
- incidentes;
- ajustes de infraestructura;
- nuevas integraciones;
- mejoras solicitadas por usuarios.
Aclara:
- horario y canal de soporte;
- severidades y tiempos de respuesta;
- garantía por defectos;
- qué se considera mejora;
- frecuencia de actualizaciones;
- monitoreo y respaldos;
- capacidad mensual disponible;
- proceso de priorización.
No confundas garantía con evolución. Corregir una función que no cumple el criterio acordado es distinto a cambiar la regla del negocio después del lanzamiento.
Preguntas para entrevistar proveedores
- ¿Cómo convertirán el problema operativo en alcance?
- ¿Qué entregables produce el descubrimiento?
- ¿Qué riesgo proponen validar primero?
- ¿Cómo documentan reglas, datos e integraciones?
- ¿Qué verá el cliente durante el desarrollo?
- ¿Cómo gestionan cambios y presupuesto?
- ¿Qué criterios se usarán para aceptar cada entrega?
- ¿Cómo incorporan seguridad y privacidad?
- ¿Quién controla repositorio, infraestructura y datos?
- ¿Qué incluye soporte y qué se cotiza aparte?
- ¿Cómo se transfiere la solución a otro equipo?
- ¿Qué necesita aportar nuestra empresa para que el proyecto avance?
Señales de alerta
- Cotizar de inmediato sin preguntar por usuarios, datos o excepciones.
- Elegir tecnología antes de entender el proceso.
- Prometer un sistema completo con alcance ambiguo.
- Omitir pruebas, seguridad, migración o soporte.
- No proporcionar acceso al avance o al repositorio acordado.
- Depender de una sola persona sin documentación.
- Usar componentes sin aclarar licencias.
- No definir propiedad y salida.
- Presentar IA como requisito aunque el problema sea una regla estable.
- Aceptar todos los cambios sin explicar impacto en tiempo y costo.
La mejor empresa ayuda a decidir qué construir
Un buen socio de desarrollo no maximiza el número de funciones. Ayuda a entender el proceso, reducir incertidumbre, escoger un primer alcance útil y construir una base que pueda probarse, operarse y mantenerse.
Internal Organic diseña software para operaciones que necesitan estructura propia. La revisión inicial parte del proceso, los usuarios, los datos y las integraciones antes de definir una solución.