Building fintech applications at Rail
Rail · Senior Frontend Engineer · 2022–2026
Rail built B2B payment infrastructure connecting traditional banking rails with stablecoins, enabling fintech companies and other businesses to move money globally through a unified platform.
I joined Rail in late 2022 as its first dedicated frontend engineer. My initial challenge was to turn an existing prototype, a new design, and a rapidly evolving API into a production-ready customer platform. The first MVP shipped in roughly two weeks, and its core architecture remained in place throughout the lifetime of the product.
As Rail evolved, I took ownership of frontend engineering across the company and built three production applications serving customers and internal teams.
01 / Product ecosystem
Three applications, one product ecosystem
01 / Customer
Management UI
The main customer-facing application turned Rail's underlying payment infrastructure into an interface customers could use to manage financial operations without relying exclusively on the API. It covered payment workflows, accounts, customers, custodians, applications, documents, settlements, and other operational entities.
02 / Onboarding
Onboarding UI
A dedicated self-service application for customer and compliance onboarding. I eventually rebuilt the original contractor-developed Flutter application in React and TypeScript, bringing it onto the same technology stack as the rest of our frontend ecosystem.
03 / Operations
Internal Admin UI
A data-heavy operational application for Support, Compliance, and Operations. It moved many day-to-day workflows from manual API interactions in Postman into a dedicated web interface, making internal operations more accessible and efficient.
02 / Ownership
Owning frontend end-to-end
As the sole frontend engineer, I owned technology and architecture decisions, implementation, testing, and end-to-end feature delivery across all three applications.
For customer-facing products, I worked closely with Product and existing designs to translate complex financial requirements into usable workflows. For the Internal Admin UI, where we had no dedicated UI/UX designer, I also owned much of the interface and UX decision-making.
I collaborated directly with Product, Backend, Compliance, Support, and Operations — from refining requirements and designing technical solutions to shipping features and resolving production issues.
03 / Engineering decisions
Engineering decisions
Decision 01 / Standardization
One frontend stack instead of two.
The original Onboarding application had been built in Flutter by an external contractor. While I could have continued developing it, maintaining a separate technology stack offered little benefit for a web-only product.
I chose to rebuild it in React and TypeScript, aligning it with Management UI. This reduced maintenance overhead, allowed us to reuse tooling and engineering patterns, and made it easier for a single frontend engineer to own the entire UI ecosystem.
Decision 02 / Pragmatism
A mature component library instead of a custom design system.
For Internal Admin UI, I chose Material UI rather than building a custom component and design system. It was an internal, data-heavy application with no dedicated designer, so a mature component library gave us a consistent foundation, accelerated delivery, and reduced long-term maintenance costs.
04 / Technical execution
Technical execution
Built and maintained three production applications with React and TypeScript, establishing shared patterns for API integration, state management, authentication, complex forms, error handling, and data-heavy interfaces. The products included advanced tables and filtering, entity management, role-based workflows, Auth0/Okta authentication, and BFF integrations built with Node.js and Express.
- React
- TypeScript
- Redux Toolkit
- RTK Query
- Material UI
- Node.js
- Express
- Jest
- Webpack
- HTML
- CSS
- SCSS
- Auth0
- Okta
- OAuth/OIDC
- GitHub Actions
- GitHub Copilot
- Claude code
- Figma
05 / Reflection
What I learned
01 / Architecture
Design for the domain you understand.
One of the most valuable lessons came from the Onboarding application. Early requirements were still evolving, and the initial architecture optimized well for speed but became increasingly difficult to maintain as the number of fields and workflows grew. Eventually, even small changes required modifications across too many parts of the application.
Once the domain became clearer, I redesigned that part of the application around a simpler model. Today, I would identify the variable parts of the onboarding flow earlier and design a more data-driven, configuration-based architecture around them.
02 / Product thinking
Access to users is an engineering advantage.
I would also involve the users of Internal Admin UI earlier and more systematically. Having direct access to Support, Compliance, and Operations created an opportunity for tighter discovery and feedback loops that I didn't fully use at the beginning.
That experience changed how I approach engineering today:
Understand the user problem,
validate the direction,
then design the technical solution.
Rather than treating implementation as the starting point.