Artículo · 2 min
Construir frontend para software regulado
Construir el frontend de un banco desde cero cambió mi definición de 'listo para producción'. En software regulado, la consistencia y la validación no son pulido — son el producto.
En Sophos Solutions construí el frontend completo en Angular, desde cero, para la plataforma de gestión de créditos de un banco. El dashboard interno que los analistas usaban para todo el ciclo de vida de un crédito — crear solicitudes, revisar información de clientes, verificar estado crediticio, validar documentación, aprobar o rechazar.
Software regulado, de misión crítica. Y ya había construido muchos frontends antes. Este me recalibró.
Lo que significa “desde cero” cuando los errores son caros
Empezar un frontend grande desde cero es mayormente un regalo — sin legado, decisiones de arquitectura limpias. En un dominio regulado también es una prueba: cada decisión que tomas a la ligera en el mes uno se convierte en política para el mes seis, y en software bancario el costo de la inconsistencia no es estético.
Tres cosas tenían que ser de primera clase desde el inicio:
- Consistencia. Un analista que procesa créditos todo el día no debería encontrarse nunca con dos pantallas que se comportan distinto para la misma operación. Componentes reutilizables y estándares, aplicados sin excepciones, son lo que hace eso verdad a escala.
- Validación de datos. Formularios pesados, con consecuencias financieras reales. La validación no es cortesía de UX; es un requisito de corrección, y tiene que ser uniforme.
- Manejo de estado. El ciclo de vida de un crédito es largo y lleno de estado. Equivocarse con el estado no solo causa bugs — le muestra a un analista información desactualizada o inconsistente sobre la solicitud de crédito de alguien.
El proceso no es el obstáculo
Todo pasaba por code review, CI/CD y QA antes de producción, con puertas de validación estrictas — el proceso definido del banco, no negociable por mí. Es fácil para los ingenieros vivir eso como fricción. Trabajar dentro de él cambió mi lectura: el proceso es el listón de calidad. Es la forma en que una organización regulada hace que “listo para producción” signifique algo específico en lugar de algo aspiracional.
Un hábito más de ese proyecto se me quedó: cuando el frontend necesitaba datos que las APIs existentes no exponían bien, colaboré en mejoras de backend en lugar de enterrar workarounds en el código del frontend. Los servicios de backend ya existían — ahí fui contribuidor, no dueño — pero negarse a enterrar problemas de backend en código de frontend mantuvo honestas a ambas capas.
La recalibración
Trabajar con estándares de grado bancario subió permanentemente mi listón de lo que significa “listo para producción”. La arquitectura frontend disciplinada y consistente no es sobrecosto en software regulado — es la diferencia entre entregar y no entregar. Y una vez que tu listón sube así, tampoco vuelve a bajar para los proyectos no regulados.