Frontend Architecture of a Large-scale Fintech Platform

The Problem

When I joined the platform as Team Lead & Senior Frontend Engineer, the codebase was functional but not scalable. The frontend had grown organically — different engineers had made different choices, components had unclear responsibilities, and state was managed inconsistently across the application.

The business was growing fast and the team was growing with it. The architecture that worked at 2 engineers wasn’t going to work at 6. We needed to standardize before the inconsistency became a blocker.

What I Did

Audit and Root Cause Analysis

The first step was understanding the actual shape of the problem — not just “it’s messy” but specifically what categories of problems existed and which ones caused the most friction. I mapped the component tree, identified the boundaries that weren’t respected, and documented where state was leaking across layers it shouldn’t cross.

Component Architecture

I defined a clear component classification system — layout components, page components, feature components, and base UI components — with explicit rules about what each layer owns and what it doesn’t. Components that had been doing too many things were split. Shared logic that had been duplicated was extracted into composables.

State Management Standardization

The application had several competing patterns for state — local component state, Vuex modules (some of which were legacy), and ad-hoc reactive references. I migrated to Pinia with a consistent store structure: one store per domain area, clear action/getter patterns, and explicit boundaries between server state and client state.

TypeScript Adoption

TypeScript was partially adopted — some files had types, most didn’t. I prioritized the critical paths first (API layer, shared composables, store definitions) and worked outward. I wrote the base types and interfaces that the rest of the team built on, and established code review as the enforcement mechanism.

Engineering Standards

I documented the patterns we’d established — not as a style guide nobody reads, but as decision records that explain the why behind each choice. When a new engineer joins, they read these to understand the architecture, not just the code.

Outcome

The refactor was done incrementally — we didn’t stop shipping features to clean up. By threading the standards through new feature work and gradually migrating legacy areas, the codebase reached a consistent state without a big-bang rewrite.

The practical result: new engineers ramp up faster, code reviews focus on logic instead of structure, and the team can extend the application with confidence that they’re not making it harder to work with.