In many real-world cases, several serious technical problems often end up accumulating simultaneously. While these issues might each be reasonable on their own, together they end up creating a situation where progress on any one feels like it comes at the expense of the others.
That is what happened to a Sequoia-backed consumer fintech that ended up turning to Trio for assistance.
The company serves over three million active subscribers in the U.S. with cash advances, unsecured credit cards, and personal finance tools.
Let’s take a look at the different issues that they faced with a legacy system, expanding services, and code merger that came from a recent acquisition, and how Trio’s engineers were able to onboard rapidly and take initiative to solve these issues.
The situation
There were a couple of different issues compounding at the time.
The company’s core platform had split into two parallel systems over time. A Python-based monolith handling roughly 70% of traffic, and a .NET platform covering the rest.
The .NET side had a lot of bugs and reliability issues, but still handled critical financial operations, so any consolidation decision needed to be careful.
While dealing with this, the company had also just completed the acquisitions of two other fintech companies, each of which came along with its own codebase and its own technical debt.
As if this wasn’t enough, new cash-back credit cards were launching. A rewards system needed to be built and scaled. A cashback initiative involving over 200,000 users needed to be executed. And their core payment integrations still ran on SOAP.
Any potential hires that they were going to make in order to improve their engineering capacity were going to run into issues. The new team members faced a steep learning curve with limited documentation to lean on.
Related Reading: Overcoming Fintech App Development Challenges
Why traditional staffing approaches struggle here
Bringing in contractors to work through a defined spec works reasonably well when the scope stays stable.
But when requirements shift mid-sprint, when engineers need to make architecture calls without always having someone available to consult, and when the work spans multiple interconnected systems at once, that model tends to slow things down rather than speed them up.
What this company actually needed were engineers who could embed deeply enough to take actual ownership.
Trio’s contribution
Trio’s engineers did exactly this, and embedded across the organization and took ownership of nine distinct areas of work.
In practice, that meant simultaneous progress on the rewards system architecture, the cashback user integration, legacy platform stabilization, SOAP-to-REST migration, acquired codebase consolidation, performance optimization, cross-platform data consistency, fintech domain documentation, and adaptive planning support.
A Trio engineer took full design and delivery ownership of the card and rewards architecture.
The 200,000-user cashback integration ran into early planning problems that caused multiple pivots mid-execution, which shifted Trio’s role partly into execution leadership, driving the project toward delivery despite the earlier planning gaps and helping establish better processes for large-scale financial onboarding going forward.
On the legacy side, the .NET platform needed incremental stabilization while the team evaluated longer-term consolidation options. Our work focused on reducing reliability issues in critical financial flows without forcing premature decisions.
The documentation work deserves more attention than it usually gets
Fintech domain documentation is essential for future growth as it gives developers context and is often used in regulatory audits to reference decisions.
Trio engineers built glossaries, system flow diagrams, and domain knowledge guides that reduced the team’s reliance on a handful of senior engineers as the single source of context.
In doing this, our developers set the organization up to scale quickly in the future.
The SOAP migration
Legacy payment integrations running on SOAP are a common kind of technical debt that we see in fintech companies built before REST became the obvious default.
These SOP protocols work, but connecting them to modern systems requires translation layers that slow development and create points of failure.
Migrating to REST APIs removes that friction. It also makes the integration layer easier to maintain, easier to test, and easier for new engineers to understand without deep context about why things were built the way they were.
If teams are already managing dual platforms and two acquired codebases, reducing that kind of hidden complexity can provide a lot of value.
Related Reading: Engineering Principles for Building Resilient Fintech Solutions
What the outcomes actually measured
Rewards system shipped and stabilized, 200,000-plus users integrated, platform usage distribution clarified, legacy bugs reduced, payment infrastructure modernized, and documentation was created.
But the thing that made those outcomes possible was the team’s ability to adapt.
Where the platform stands now
While the platform has been stabilized, the consolidation question is still open today. Maintaining two parallel systems long-term carries real costs in complexity and maintenance overhead, but migrating three million users off a working system carries its own risks.
The platform visibility data and legacy stabilization work that Trio contributed is going to give the team a stronger foundation for making that call than they had before, and has set them up for further expansion of their existing product line.
For fintech teams in similar positions, the practical takeaway may be less about any specific technical solution and more about the kind of engineers the situation actually calls for.
For engineers with genuine fintech experience who have the knowledge and skillset to be able to take ownership and help you move forward in the most realistic way possible, request a consult.
