Article · 2 min
Building frontend for regulated software
Building a bank's frontend from scratch changed my definition of 'production-ready'. In regulated software, consistency and validation aren't polish — they're the product.
At Sophos Solutions I built the entire Angular frontend, from scratch, for a bank’s loan-management platform — the internal dashboard analysts used to run the full loan lifecycle: creating applications, reviewing client information, checking credit status, searching large volumes of data, validating documentation, approving or rejecting. Regulated, mission-critical software.
I’d built plenty of frontends before. This one recalibrated me.
What “from scratch” means when mistakes are expensive
Starting a large frontend from zero is mostly a gift — no legacy, clean architecture decisions. In a regulated domain it’s also a test: every decision you make casually in month one becomes policy by month six, and in banking software the cost of inconsistency is not aesthetic.
Three things had to be first-class from the start:
- Consistency. An analyst who processes loans all day should never encounter two screens that behave differently for the same operation. Reusable components and standards, applied without exceptions, are what make that true at scale.
- Data validation. Heavy forms, real financial consequences. Validation isn’t a UX nicety; it’s a correctness requirement, and it has to be uniform.
- State management. The loan lifecycle is long and stateful. Getting state wrong doesn’t just cause bugs — it shows an analyst stale or inconsistent information about someone’s credit application.
The process is not the obstacle
Everything went through code review, CI/CD, and QA before production, with strict validation gates — the bank’s defined process, not mine to negotiate. It’s easy for engineers to experience that as friction. Working inside it changed my read: the process is the quality bar. It’s how a regulated organization makes “production-ready” mean something specific instead of something aspirational.
One more habit from that project stuck with me: when the frontend needed data the existing APIs didn’t expose well, I collaborated on backend/API improvements instead of forcing workarounds into the UI. The backend services were pre-existing — I was a contributor there, not the owner — but refusing to bury backend problems in frontend code kept both layers honest.
The recalibration
Working to banking-grade standards permanently raised my bar for what “production-ready” means. Disciplined, consistent frontend architecture isn’t overhead in regulated software — it’s the difference between shipping and not. And once your bar has been raised like that, it doesn’t go back down for the unregulated projects either.