La tecnología no se compra a ciegas

¿De verdad estás dispuesto a contratar un servicio si no sabes quién hay detrás y cómo trata a sus clientes?

En software, y especialmente cuando hablamos de servicios en la nube, una decisión rara vez es solo técnica. También es contractual, operativa y, en el fondo, de confianza. Se puede tener una aplicación que arranca rápido, que se ve bien y que promete mucho. Pero eso no basta. Lo importante no es únicamente si funciona hoy, sino si seguirá funcionando mañana, quién responde cuando algo falla y qué nivel de madurez hay detrás de cada decisión que afecta al servicio.

Esto en entornos normales ya es importante. En un contexto como el de las fallas, todavía más.

Cuando una solución se convierte en parte del día a día de miles de personas en un periodo muy concentrado de tiempo, el margen de error se reduce casi a cero. Hay picos de uso, hay dependencia del móvil, hay usuarios que no esperan y hay una ventana temporal en la que todo tiene que ir bien. No vale con decir que la aplicación “escala”. Hay que demostrarlo. Y no solo en una presentación comercial, sino en producción, con tráfico real, con presión real y con incidencias reales.

A menudo, desde fuera, se simplifica demasiado. Se habla de software como si todo dependiera de una interfaz bonita o de que la app responda bien en una prueba interna. Pero quien ha trabajado en IT, quien ha tenido que coordinar varios proveedores o quien ha vivido una incidencia en una noche crítica sabe que la pregunta importante es otra: ¿qué hay detrás de esta herramienta?

Porque detrás de una aplicación hay arquitectura, sí. Pero también despliegues, monitorización, seguridad, backups, gestión de accesos, trazabilidad, continuidad de negocio, atención a incidencias y una organización humana que tiene que estar preparada para responder. Si eso no existe, o existe solo sobre el papel, la herramienta es frágil aunque funcione en condiciones normales.

Los CIO y los responsables de tecnología lo saben bien.

Muchas veces el problema no es elegir entre una opción u otra, sino convivir con varias. Un proveedor para la web, otro para la integración, otro para el soporte, otro para la infraestructura, otro para el mantenimiento. Y entonces aparecen las zonas grises. El fallo “no es nuestro”. El retraso “viene de terceros”. La incidencia “está escalada”. Mientras tanto, el negocio espera. Y el usuario también.

He visto situaciones así más veces de las que me gustaría. Una plataforma externa que en pruebas iba sobrada y en el momento de la verdad empieza a degradarse. Un proveedor que tarda horas en reconocer un incidente porque no tenía un esquema serio de observabilidad. Un equipo que, ante una subida de carga, descubre que nadie había previsto un plan de contingencia real. O lo peor: soluciones que técnicamente son correctas, pero que dependen de una sola persona que “sabe cómo está montado todo”. Eso no es una arquitectura. Es una apuesta.

En software SaaS, la conversación debería empezar mucho antes de la compra. No solo con preguntas sobre funcionalidad, sino sobre operación.

¿Cómo se despliega? ¿Cómo se monitoriza? ¿Qué SLAs reales hay? ¿Dónde están los logs? ¿Qué pasa si cae un servicio crítico? ¿Quién atiende el incidente? ¿En qué plazo? ¿Cómo se comunica? ¿Qué experiencia tiene el equipo que lo mantiene? ¿Cómo se gestionan las actualizaciones sin romper el servicio?

Son preguntas incómodas, pero son las correctas.

Y hay otra cuestión que en sectores con mucha exposición pública conviene no minimizar: la seguridad. No se trata de poner un candado simbólico ni de decir que se usa HTTPS, como si eso cerrara el debate. Un sistema serio tiene que contemplar autenticación robusta, control de permisos, protección frente a accesos indebidos, cifrado donde toca, segregación de entornos, gestión responsable de vulnerabilidades y capacidad de reaccionar si algo se compromete. También trazabilidad. Porque cuando hay una incidencia, no basta con saber que algo falló. Hay que poder reconstruir qué ocurrió, cuándo y por qué.

Cuando una plataforma gestiona información de usuarios, gestiones y procesos sensibles, la exigencia sube todavía más. No basta con que “funcione”. Tiene que hacerlo con la máxima seriedad, con procedimientos claros y con una disciplina técnica que no deje huecos. Mira siempre quién hay detrás de los servicios que estás contratando, y asegúrate de que la empresa conoce y realiza ese trabajo con la máxima exigencia. No debería haber improvisación cuando se trata de sistemas donde se mueve información que merece protección, continuidad y una gestión impecable.

Para un responsable IT, esto cambia mucho el tipo de conversación con los proveedores. Ya no se trata de “qué hace la aplicación”, sino de “qué pasa cuando la aplicación no hace lo que debe”. Y ahí se separan muy rápido los proyectos sólidos de los que solo parecen sólidos.

En picos de uso, como los que viven muchos servicios ligados a fallas, la exigencia es todavía más alta. No basta con tener capacidad técnica. Hace falta previsión, pruebas de carga, arquitectura preparada para absorber picos, mecanismos de escalado y un seguimiento continuo de la experiencia real de usuario. Porque el usuario final no distingue entre un error de frontend, un timeout de backend o una base de datos saturada. Solo ve que la aplicación no responde. Y cuando eso ocurre en el momento menos oportuno, la percepción sobre la herramienta cambia por completo.

Por eso, cuando una organización contrata un SaaS, en realidad está contratando mucho más que software. Está contratando criterio técnico, capacidad operativa y compromiso con el servicio. Y eso debería estar claro desde el principio. No solo en el contrato, también en la forma de trabajar. Cómo se reportan incidencias. Cómo se priorizan. Quién da la cara. Qué tiempos son razonables. Qué niveles de soporte existen. Qué experiencia tiene el equipo que va a sostener la plataforma cuando el tráfico suba y las cosas se compliquen.

Las fallas, como cualquier entorno con alta visibilidad y uso intensivo, no deberían conformarse con menos. Si una aplicación se convierte en parte de la experiencia colectiva, tiene que estar a la altura no solo en el momento del lanzamiento, sino cada día que está en producción. Y eso exige madurez técnica, sí, pero también madurez organizativa.

Al final, la tecnología que de verdad sirve no es la que más promete. Es la que responde cuando más se le necesita. Y en eso, conocer quién está detrás importa mucho más de lo que algunos quieren admitir.