A publicly traded digital marketplace bank, one of the largest online lending platforms in the U.S., with over $10 billion in assets and nearly $1 billion in annual revenue, got to the point where further growth really needed a testing environment.
At that size, it’s unrealistic to implement a full code change every time you want to adjust a UX element.
Issues had also built up thanks to the company’s growing portfolio of backend services and the fragmentation between those services that made debugging painful.
Trio stepped in to provide the talent that not only allowed them to implement an experimentation framework and consolidate their logging infrastructure, but also to move forward in such a way that users could link external accounts.
What was actually slowing things down
Three distinct problems had developed, each blocking progress in a different part of the organization.
The first involved experimentation. The product team wanted to test things like different onboarding flows, promotional screens, and content-driven sequences with animations.
But since everything was built as a single-page app, they had no mechanism to serve dynamic UI from the backend, and every experiment required a code change, a QA cycle, and a deployment.
The second involved logging. Across the company’s backend services, different teams had built different logging implementations over time, leading to different formats, different metadata conventions, and different transport mechanisms.
When an incident crossed service boundaries, tracing what happened was very difficult. There was also no shared standard a new service could adopt, and no way to build dashboards that drew from a consistent data source across the portfolio.
The third involved financial connectivity. As the bank expanded beyond personal lending into a broader product suite, users needed to link external accounts. No integration existed to support this at the scale and reliability a production banking environment requires.
All of these issues were interconnected enough that they really needed to be addressed in parallel for the best results.
The experimentation platform, in concrete terms
The architectural challenge with experimentation in a single-page application comes down to coupling.
When UI components and the content they display are defined together at the code level, changing one means that you need to change the other.
That works fine for stable product surfaces.
If your team wants to do something like A/B testing to find out whether users engage more with one onboarding flow than another, or whether a particular animation sequence affects how far someone gets through a signup process, it becomes a real constraint.
Trio built a server-driven architecture that decoupled those two things. Custom API endpoints pulled structured content from Contentful, a headless CMS, and delivered it to the front-end at runtime.
The product team could create a new experiment in Contentful, push it live through the CMS, and see it served to real users without a single line of application code changing.
Related Reading: API-First Banking and Automating Processes
The logging package
Fragmented observability carries a compounding cost as your application scales.
When services emit logs in incompatible formats, debugging a cross-service incident requires engineers to constantly context-switch between systems that don’t share a common language.
Building shared dashboards means writing translation layers. Onboarding a new engineer means teaching them which logging pattern each service uses.
The npm package Trio, built and published to the company’s private registry, addressed this at the infrastructure level.
Framework-agnostic, it could be installed in any Node.js service, whether built on Express, Fastify, NestJS, or something else, with minimal configuration.
On top of that, this means that every new service added to the stack now has a logging standard it can simply adopt rather than improvise, stabilizing observability so the infrastructure doesn’t fragment further as the organization grows.
The Plaid integration
Integrating Plaid for financial account connectivity is a great tool, especially thanks to the surface area of edge cases.
- Institution-specific authentication flows behave differently across thousands of banks and credit unions.
- Error handling needs to account for partial failures, timeouts, and the ways different institutions respond under different conditions.
- Security requirements in a regulated environment constrain token handling, data storage, and what error messages can be exposed to users.
Getting this right at production scale allowed the company to start moving from a lending-focused product toward something closer to a full digital banking suite with checking, savings, and money movement support.
Related Reading: Scaling Payment Infrastructure
Final Thoughts
The bank had reached a point in its evolution where the original architecture had accumulated constraints that made the next phase of growth harder than it needed to be.
Rather than treating each problem as a ticket to be closed, the solutions were built for reuse.
The experimentation framework supports any future CMS-driven content, not just the experiments that prompted its creation. The logging package can be adopted by any new backend service. The Plaid integration handles the edge cases that tend to surface at scale, not just the happy path.
For engineering organizations at a similar stage, we can do the same.
Request a consult.
