El costo de un sistema no está en construirlo: está en los tres años siguientes. Cuatro decisiones tomadas al principio son las que determinan cuánto cuesta ese tramo.
Mantenemos once productos en operación con clientes dentro. Eso obliga a vivir con las decisiones que se tomaron al principio, y hay cuatro que aparecen una y otra vez como la diferencia entre un sistema que se puede seguir cambiando y uno que se vuelve intocable.
Esconder un botón no es un control de acceso: es una sugerencia. Un modelo de permisos que vive en la interfaz se rompe con una petición hecha a mano, y el día que eso importa ya hay datos de un cliente en la pantalla de otro.
La regla operativa: el servidor niega la operación, y la interfaz esconde el botón sólo para no ofrecer algo que va a fallar. Las dos cosas, en ese orden de importancia.
El corolario incómodo es que el alcance también se resuelve en el servidor. Si el cliente puede decir a qué empresa pertenece la petición, no hay aislamiento: el tenant efectivo se deriva de la sesión, nunca del formulario.
Si dos pantallas muestran el mismo saldo y cada una lo calcula, algún día van a diferir. No es una posibilidad: es cuestión de tiempo, porque una de las dos se va a actualizar y la otra no.
La regla: cada concepto —un saldo, un tope, una disponibilidad— se calcula en un solo lugar. Si una pantalla necesita ese número, lo pide; no lo recalcula. Cuesta más al principio y es lo que evita la clase de error más difícil de diagnosticar, porque ninguna de las dos cifras está «mal».
Qué cambió, quién y cuándo. Con el filtro de secretos aplicado antes de escribir el registro, no después.
La utilidad no es de auditoría —aunque también— sino de operación cotidiana. Sin bitácora, «¿quién cambió esta política?» es una investigación de dos días. Con bitácora es una consulta de dos minutos. La diferencia entre esas dos cosas, multiplicada por tres años, es una persona.
Un sistema en producción tiene información que no se puede perder. Eso descarta ciertas comodidades del desarrollo: no hay reinicios de base de datos, no hay seeds destructivos, y antes de cualquier operación irreversible hay respaldo.
Del lado del despliegue, la pregunta que importa no es cómo se sube una versión nueva: es cuánto tarda volver a la anterior. Si la respuesta es más de un minuto, el equipo va a evitar desplegar — y un equipo que evita desplegar acumula cambios, y los cambios acumulados son la causa del siguiente incidente.
No aparece la elección de framework, ni el lenguaje, ni la nube. No porque no importen, sino porque importan mucho menos de lo que se discute. Un sistema con las cuatro decisiones de arriba bien tomadas se puede migrar de stack; uno sin ellas no se puede ni cambiar dentro del mismo.
Las cuatro reglas están aplicadas en los productos de Botbi. No son teoría: son lo que nos permite seguir cambiándolos.
La primera conversación es de diagnóstico. Si el proceso no conviene tocarlo, también lo decimos.
Botbi Advisor
Información pública de Botbi