FedNow is the Federal Reserve's instant payment system: real-time settlement at the wholesale-banking layer. Banks have to integrate to offer their customers real-time payment capability. The onboarding process this platform replaced was paperwork-heavy and bespoke; it took 60 days per bank. After: 7 days.
I was the single frontend developer for most of the project, building a brand-new onboarding application from the ground up on Salesforce with Lightning Web Components. 1,000+ banks have run through the flow. Another frontend engineer joined for ~6 months in the middle of the engagement; the rest of the two-year arc, I was the only frontend developer.
On-site embedded engagement with the Federal Reserve
The Federal Reserve's team was based in Boston. I traveled to co-locate with them at the Deloitte Lower Manhattan office, 4–5 trips per year over two years. Co-location wasn't optional decoration; it's how the work actually got done in a regulated, high-security environment where most of the substantive design conversations had to happen in-person.
What that looked like, day to day:
- Hands-on-keyboard pairing with customer engineers and product managers. Sitting next to Federal Reserve developers and PMs, working through implementation choices in real time on the same screens. Apex backend developers on their side were learning frontend ahead of the contract handoff, so part of the in-person work was informally mentoring them as they ramped on the codebase I was leading.
- Discovery and requirements gathering during planning sessions. Every co-location trip included planning sessions where we mapped the next several months of work. The roadmap that came out of those sessions wasn't dictated to either side; it was negotiated in person, against the actual constraints both teams were carrying.
- Regulated-environment delivery. High-security setting throughout. Decisions about what shipped, what got deferred, and what got reshaped to fit the security envelope happened on the customer's terms, in their building, with their people in the room.
Why the customer asked for me by name
The contract between Deloitte and the Federal Reserve was extended multiple times across the two-year engagement. The customer asked for me by name each time as their main frontend developer (and for most of the project, their only one). That kind of long-term customer relationship is the thing applied-AI roles ask for hardest, and it's not built on any single pull request. It's built on showing up in person, being the person the customer can talk to about tradeoffs without translation, and shipping what was agreed to in the planning sessions.
These skills (on-site embedded engagement, hands-on-keyboard pairing with customer engineers and PMs, discovery and requirements gathering, regulated-environment delivery, long-term customer relationships that lead to contract extensions) are the same skills product-engineer roles at AI-applied teams describe.
Picking up Lightning Web Components in two weeks
I came onto the project with zero Salesforce or LWC experience. Two weeks later I was pushing to production. LWC's ergonomics are closer to vanilla HTML, CSS, and JavaScript than to React (the framework leans on Web Component primitives) so I leaned hard on foundational JavaScript and ramped fast.
I earned the Salesforce JavaScript Developer certification during this period (since expired). A useful forcing function early on, and a signal that the JavaScript foundation transferred cleanly into the Salesforce ecosystem.
A reusable component library, built from scratch
Salesforce's out-of-the-box LWC base components couldn't meet the design team's spec. They're generic by design: fine for typical Salesforce admin surfaces, not fine for the highly custom flows FedNow needed. I built a reusable component library covering the visual and behavioral surface the design system asked for, owning each primitive end-to-end:
- Advanced data tables with multiple layers of inline error validation and the kind of cell-level interaction the stock LWC tables don't support.
- A step-by-step form wizard that drove the digital onboarding forms: the surface where banks supply the regulatory information the Federal Reserve needs to enable their instant-payment integration.
- Branching flow logic inside the wizard. Different banks see different screens depending on their answers, so each branch had to stay coherent and recoverable as the user moved through.
- An onboarding progress page spanning days of in-flight bank work: a dynamic vertical progress bar with collapsible sections and per-step completion states, surfacing exactly which step the bank was on, what forms and information were still outstanding, and what had already been submitted. The custom CSS to land that layout wasn't trivial.
By the end, almost every interactive surface in the onboarding flow was composed from this library.
The trade-offs
LWC has different ergonomics than React, and the integration surface to Salesforce's data model isn't optional. The job was to make the onboarding feel like a deliberately designed product on top of a platform that wants to dictate everything from form layout to validation behavior. Where the platform fought us, I built around it. Where it gave leverage, I used it. The customer outcome (onboarding that went from 60 days to 7 days for 1,000+ banks) got built in person, in regulated space, against a roadmap negotiated face-to-face every quarter.