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.

Un detalle que decide más de lo que parece: los roles y los permisos se resuelven en servidor, nunca ocultando botones en la interfaz. Una pantalla escondida es una sugerencia; una regla comprobada antes de tocar los datos es una garantía. Lo mismo vale para la facturación recurrente, que se trata como estado del sistema y no como el eco de un webhook: si el aviso de pago llega dos veces, o llega tarde, o no llega, la cuenta tiene que acabar igual de bien en los tres casos.