When I joined BMO after years of working in startups and consulting firms, I thought I knew what I was getting into. I had built complex Angular applications, been the technical reference for a front-end team, and shipped products under tight deadlines. Enterprise banking, I assumed, would be slower but not fundamentally different. I was wrong. And it took me several months to recalibrate my instincts.
This is not a post about which world is better. Both have real trade-offs. But if you are a developer considering a move from a startup or agency background into a large financial institution, I want to give you the honest picture of what changes: technically, culturally, and professionally.
Should You Make This Move? Three Signals
Before accepting an offer from a large bank, check whether these three match your actual preferences. If two or more are hard no, the transition will frustrate you regardless of title or compensation.
- You can tolerate process as load-bearing, not as waste. Approval chains in banking exist because the blast radius of a mistake is enormous. If you read every committee as drag rather than risk management, you will be fighting the environment every day.
- You value depth over velocity. Banking front-end rewards knowing your system deeply over shipping quickly. If your motivation comes from frequent greenfield work and rapid iteration loops, enterprise banking will feel like dragging through mud.
- You are willing to become a domain expert. Financial products are specific and regulated. The best banking front-end developers read product documentation voluntarily. If that sounds like a cost rather than an opportunity, reconsider.
The Approval Process Is Not Bureaucracy for Its Own Sake
In a startup, you push a feature and it is live within hours. Sometimes minutes. The feedback loop is tight, and iteration speed is the primary competitive advantage. In enterprise banking, a single UI change can take weeks to reach production. If you come from startups, your first reaction is frustration. It feels like organizational drag, committees slowing down progress for no reason.
Then you look at what approval layers in a bank exist to catch. A UI change on a banking portal might affect regulatory reporting. An accessibility shortcut could conflict with screen reader behavior on a specific assistive technology used by a segment of customers. A new API call pattern might have implications for fraud detection systems that operate in the background. The approval layers exist because the blast radius of a mistake is enormous. We are talking about people's money, their mortgages, their retirement savings.
I have not stopped wishing the process was faster. But I no longer think the process is arbitrary. That shift in perspective matters a lot for your day-to-day mental health in this environment.
Security Review Cycles Are a Full Part of the Development Timeline
In startups, security is often something you bolt on. You add HTTPS, you hash your passwords, and you ship. Security reviews, when they exist, are lightweight. In banking, security review is typically a mandatory phase that features go through, and it has real teeth.
What this means practically: I have to think about Content Security Policy headers from the very first line of component code. I have to think about how data is stored in browser memory, how long tokens live, what happens if a user walks away from their session. In an environment like this, every third-party library gets scrutinized. You cannot just npm install something because it has a lot of GitHub stars. Expect a vetting process that can include license review, vulnerability scanning, and sometimes architectural sign-off.
This changes how I write Angular code. I am more deliberate about what I put in component state versus what I pass through services. I think about whether sensitive data should ever touch localStorage at all. I structure interceptors differently because they are security-critical paths, not just convenience wrappers.
The Design System Is Non-Negotiable. And That Is Mostly a Good Thing
Startups love custom design. Every startup I worked with wanted their own unique look and feel, their own component library, their own animation language. At BMO I worked with the bank's design system, which another team owned. In a large bank, deviating from the design system is not a call a feature developer makes on their own.
My first instinct was to chafe against this. I am also a UX/UI designer, so having constraints imposed on front-end decisions felt limiting. But I have come around to seeing the value. The design system means I spend almost no time on visual bikeshedding. I do not debate button border radii or whether a modal should fade or slide in. Those decisions are already made, documented, and accessible to everyone. I can focus on what actually matters at my level: the interaction logic, the data flow, the accessibility implementation, the performance characteristics.
A mature design system also enforces accessibility standards consistently across the entire product surface. When its components have been tested with screen readers, ship with proper ARIA roles, and meet WCAG 2.1 AA, you inherit most of that compliance by using them. Most, not all: how you compose them can still break it. That is a significant engineering and legal benefit.
Legacy Code Is the Primary Technical Reality
No one told me this explicitly before I joined, but banking front-end is largely legacy management. Banks run systems that were built over decades. Across the industry you will find Angular applications that started on AngularJS and were incrementally migrated, with parts of the codebase that still bear the scars of that migration. That is a statement about banks in general, not about the codebase I worked in. You will find patterns that made perfect sense in 2015 but create real problems when you try to compose them with modern approaches.
In a startup, greenfield is common. You start fresh every one to three years when the product pivots or gets rebuilt. In banking, you are almost never starting fresh. You are inheriting. My job there was rarely to build something new from scratch. It was more often to extend, refactor, or stabilize something that already existed and that customers depended on.
This requires a different skill set than startup development. You need patience and humility. You need to be able to read code written by someone who is no longer at the company, understand why they made the choices they made, and decide whether to preserve or refactor those choices. And you need to make that decision based not just on code quality but on risk, because touching certain parts of the codebase can have cascading effects that are genuinely difficult to predict.
Team Structure Is Layered in Ways That Took Time to Navigate
At startups, the team structure is flat and fluid. You talk directly to whoever you need to talk to, and decisions get made quickly. In a large bank, the structure has more layers: architects, platform teams, security teams, design governance, product owners, business analysts, and more. Each of these groups has a role in what gets built and how.
Front-end code in a bank does not exist in isolation. Mine integrates with Java and Node.js services inside a micro-frontend architecture, and in a setup like that your code plugs into systems owned by other teams, consumes APIs designed elsewhere, and runs on infrastructure someone else maintains. Learning to work within this structure, and more importantly to build relationships across it, took real time and intentional effort.
The developers who succeed in enterprise banking are not the ones who are the best coders in isolation. They are the ones who can communicate clearly across organizational boundaries, who document their decisions, and who build trust with adjacent teams. That is a soft skill I have had to develop much more consciously here than I ever did in a startup.
What Actually Shocked Me
The demand for domain depth in banking front-end is larger than in any other environment I have worked in. In a startup, you can build what the product manager specifies, ship it, iterate. In banking, you cannot build good interfaces for financial products without understanding those products at a level that often surprises developers coming from consumer software.
What is the difference between a GIC and a term deposit in how a customer mentally frames them? How does a mortgage amortization schedule change what information a user needs at each step of an application flow? What regulatory disclosure requirements apply to this specific transaction? I was not hired as a domain expert, but learning the domain made me noticeably better at my actual engineering job. If you join banking expecting to only solve technical problems, you will plateau faster than you expect.
The Unexpected Benefits
I want to be honest about what I genuinely appreciate about enterprise banking development, because there are real benefits that I did not anticipate.
- Stability: nobody in a big bank worries about the company's survival, and for the full-time staff that extends to their paycheck. That mental overhead is real in startups and I had underestimated how much it was affecting me.
- Depth over breadth: In startups, you context-switch constantly. There, I worked on fewer products but I worked on them deeply. That depth produces better results and better engineering.
- Mentorship and cross-pollination: Large banks have people with decades of domain expertise. The knowledge available to me in informal conversations there exceeded anything I had access to in most startup environments.
- Structured career development: large banks typically give full-time staff formal paths, feedback cycles, and learning budgets. None of these were reliable in the startups I worked in.
- Accessibility maturity: The level of accessibility investment in banking has made me a significantly better front-end developer. I know ARIA, I know screen reader patterns, and I test with real assistive technology. That is a skill I am taking with me for the rest of my career.
The Honest Verdict
Banking front-end is not for everyone. If you need rapid feedback loops and frequent greenfield work to stay motivated, you will find enterprise banking difficult to sustain. If you are motivated by stability, depth, domain complexity, and the knowledge that the software you build is used by millions of people to manage their financial lives, this environment has a lot to offer.
For me personally, the transition required genuine recalibration. I had to let go of startup reflexes: the move-fast mentality, the skepticism toward process, the preference for individual autonomy over organizational alignment. In exchange, I have developed patience, precision, and a much deeper appreciation for the systems thinking that large-scale software actually requires.
The best front-end developers in banking are not the ones who resent the constraints. They are the ones who have learned to work brilliantly within them.
If you are considering this move: come in with curiosity, not judgment. The things that look like obstacles are usually load-bearing. Understanding why something works the way it does here is almost always more useful than criticizing it from the outside. The developers who thrive have made that switch explicitly. The ones who do not end up either leaving in six months or spending years resenting the environment.
References
- OSFI Technology and Cyber Risk. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
- WCAG 2.1 guidelines. https://www.w3.org/WAI/WCAG21/Understanding/