Aplicaciones y SaaS

Una aplicación deja de ser una web en el momento en que tiene usuarios distintos que ven cosas distintas. Ahí aparecen tres problemas que no se resuelven con diseño: quién puede ver qué, qué pasa cuando dos personas editan lo mismo y qué ocurre con los datos de un cliente cuando deja de pagar.

Los permisos se resuelven en servidor. Una interfaz que esconde un botón no protege nada: la comprobación tiene que estar en el punto donde se lee o se escribe el dato, y tiene que seguir siendo cierta si alguien llama a la API directamente. Lo mismo vale para la separación entre clientes de un SaaS, que es una propiedad del modelo de datos y no una condición añadida en cada consulta.

La facturación recurrente se trata como estado del sistema, no como un correo de la pasarela de pago. Suscripción activa, periodo de gracia, impago y baja son estados con transiciones definidas; si el sistema no los modela, alguien acaba llevándolos en una hoja de cálculo y la aplicación deja de saber quién tiene acceso.

Este es el terreno de las herramientas internas: paneles que usa el equipo todos los días, procesos que antes eran un correo y un adjunto, integraciones con lo que ya hay. Es el tipo de sistema que hemos construido para plantillas de 30.000 empleados y el mismo que tiene sentido para un equipo de diez, con la diferencia de escala y ninguna de criterio.