A recognized Senior Software Engineer, whose two independent Encompass integrations generated significant production volume and demonstrated Truv’s production-grade integration capability, on what it takes to build fintech infrastructure that holds under real conditions.
The mortgage industry is moving fast, but borrowers aren’t keeping up. Data from Cotality found that overall buyer confidence in navigating homebuying dropped from 83% in 2025 to 72% in 2026, and 55% of U.S. buyers now say they would prefer to work with a human to secure a mortgage, up nine percentage points from last year.
The gap isn’t trust in humans; it’s trust in the underlying infrastructure. Encompass, the US mortgage industry’s dominant loan origination platform, is a complex, enterprise-grade system with a deep partner ecosystem built over many years. Successfully integrating with it at production scale requires a level of domain expertise and engineering discipline that most teams underestimate. Dmitrii Fomichev, senior software engineer, has spent years solving exactly that problem at Truv, a fintech platform holding dual Fannie Mae and Freddie Mac certification, where the infrastructure underneath the mortgage market either holds or doesn’t, and where the difference between a demo and a production system is measured in real borrowers and real loans.
That same standard extends beyond the codebase. Fomichev has guided more than 40 developers through a structured curriculum built on his own unconventional path into the industry, with measurable outcomes: career switches, promotions, and first engineering roles. Before joining Truv, he spent three years doing what most engineers avoid: entering unfamiliar domains and delivering anyway. At Rubytech, a major IT integrator whose clients include government institutions and large corporations, he designed a web scraping infrastructure that processed 350+ unique sites per minute, an industrial-scale throughput built from scratch. At Simbirsoft, one of Russia’s largest software development firms, he inherited a broken MVP for an international financial holding operating in 14 countries and rebuilt the entire platform on his own. Both were shipped on deadline, without revisions or post-launch failures.
We spoke with him about what Encompass integration demands, why discipline built under pressure transfers directly into legacy infrastructure, and what the fintech industry’s real capability gap looks like from inside a platform the mortgage market depends on.
Dmitrii, the mortgage technology industry just had one of its most eventful conference seasons in years. AI tools are being announced faster than they can be integrated. You work at the infrastructure layer where those announcements either hold or fall apart. What’s happening?
What’s happening is that the industry is conflating speed with progress. Every conference produces announcements. What the announcements don’t show is the integration work beneath the surface, the underlying systems, the platform compatibility layers, and the technical debt that accumulates at the infrastructure level. That’s where the gap lives.
I work on Encompass integrations, Encompass being the dominant loan origination platform in the US market. When a new verification tool gets announced, the question that matters isn’t whether the product works in a demo. It’s whether it works inside the workflow of thousands of mortgage lenders who have no intention of leaving their existing platform. That’s the integration problem. That’s what I spend my time solving.
You’ve independently delivered two Encompass integrations, both now live in production and actively generating revenue. Encompass is known for its depth and complexity. What does successful integration at production scale actually require, and what do most teams underestimate going in?
Encompass is a mature, enterprise-grade platform with a deep partner ecosystem built over many years, which is precisely what makes it the dominant system in the US mortgage market. Successfully integrating with it at production scale requires understanding how that ecosystem behaves under real lender conditions, not just in a controlled sandbox.
What most teams underestimate is the degree to which edge cases in lender configuration, data state, and authentication only surface under real conditions, not in sandbox testing. The only way to develop a true understanding of the Encompass integration layer is to observe it in practice. You build, instrument, watch, and adjust. Both integrations I delivered required exactly that. Both are now generating orders at production scale.
One integration brought an asset verification product directly into the Encompass workflow, removing the adoption barrier for thousands of mortgage lenders. The second transformed a manual billing process into an auditable, automated system that the sales team now uses to win new business. You were the sole engineer on both. Where does your role end, and where does the product thinking begin?
Both integrations demanded the same thing: understand the legacy system before writing a single line of code and design for failure modes that only surface under real production conditions.
The asset verification integration was a distribution problem with a technical solution, removing the friction that kills adoption. The billing integration replaced a manual process that the company sought to make more accurate, auditable, and scalable. That system is now processing loans at scale and has strengthened the platform’s overall reliability. A back-office process became a platform capability.
That product thinking didn’t stop at the integration layer. You migrated an entire client base from a single-organization to a multi-organization architecture with zero disruption, preserving all existing workflows. That migration enabled the platform to support enterprise-scale clients, while new clients were onboarded through the self-service system you built. What do engineers miss when they approach a migration like this?
Treat migration as a product problem, not an engineering problem. Most migrations fail because they’re designed from the inside out; engineers focus on the data model, not the client’s experience, at every step of the transition.
The constraint was absolute: no disruption, no degraded workflows. The migration had to be invisible. The architecture had to support both models simultaneously, and observability had to be built before the first client moved, not after something breaks at 2 AM. The outcome: the new positioning of the platform for enterprise-scale growth, while making the platform ready to scale further. Infrastructure improvement became revenue unlock.
At Simbirsoft, one of Russia’s largest software development firms, you rebuilt an entire fintech platform for a financial holding operating across 14 countries. The platform launched clean, with no defects, and a written commendation from the client. What does that kind of ownership discipline look like when applied to Encompass-level complexity?
Being the only engineer is clarifying. No ambiguity about ownership, every decision, every tradeoff, every post-launch issue is yours. That removes coordination friction but replaces it with a different weight. You have to be right more often, because there’s no one to catch what you miss.
The project started as a modification request. I recognized early that modification was the wrong answer; the existing MVP had structural problems that would compound. I made the case for starting over. The client agreed. The zero post-launch issues weren’t luck. I treated QA as a first-class concern from day one. I wrote tests as I built. When we went live, there was nothing to discover. That discipline, owning the decision before you write the code, is exactly what Encompass demands. The platform doesn’t forgive assumptions. Neither does a solo deadline.
You’ve mentored more than 40 developers, many switching into backend engineering within a year. What are the two biggest mental shifts you force early, and how does domain ignorance make those gaps worse in mortgage infrastructure?
What breaks most engineers entering fintech is the gap between controlled conditions and the realities of production. Tutorials assume clean data. Production doesn’t. The first thing I fix is the failure-first instinct: before asking how something works, ask how it breaks. The second gap is domain ignorance. In mortgage infrastructure, not understanding the business context means you can’t anticipate where the system fails. What happens when a third-party API changes its schema in production? When your 50-millisecond query runs in eight seconds at scale? These aren’t exotic scenarios; they’re regular events. The platform surfaces every assumption you didn’t know you were making.
Buyer confidence in homebuying dropped eleven points in a single year. Most Americans now say they’d rather work with a human than trust the technology underneath. You build that technology. What actually needs to change, and is the industry willing to do it?
The trust gap isn’t a product problem. It’s an infrastructure problem that gets dressed up as a product problem at conferences. Borrowers don’t trust the process because it fails them in ways that go unnoticed until the loan doesn’t close. Fixing that requires engineers who are willing to go into the platform, the legacy layer, the inconsistent APIs, the undocumented edge cases, and build systems that hold under real conditions, not demo conditions. The industry has the tools. What it needs is the discipline to use them correctly. That’s a slower, less announced kind of progress. But it’s the only kind that actually reaches the borrower.
