Building Mortgage Software in the Real World
I’ve spent more than 10 years building software for the U.S. mortgage industry.
Over that time, I’ve worked extensively with Encompass, starting with its SDK and eventually working with its APIs and broader integration ecosystem. I’ve also been part of the gradual transition from systems built around Encompass to newer platforms such as Vesta.
After more than a decade in this space, I’ve accumulated quite a few stories.
Some are about architecture.
Some are about integrations.
Some are about production incidents that took hours to understand and minutes to fix.
And some are simply about learning the hard way.
That’s why I started this blog.
Why Mortgage Software Is Harder Than It Looks
From the outside, a mortgage application might look like just another business system.
It isn’t.
The U.S. mortgage industry has its own unique combination of technology, business rules, regulations, third-party systems, and constantly changing requirements. A seemingly simple change can sometimes touch half a dozen systems.
Encompass is a great example.
As one of the most widely used Loan Origination Systems (LOS) in the U.S. mortgage market, Encompass provides an enormous amount of functionality and flexibility. Its extensibility is one of its greatest strengths.
But that same flexibility can also become one of its biggest challenges.
Once you start extending Encompass, integrating with other systems, and building business processes around it, things can get complicated very quickly.
And Encompass is rarely the only system involved.
Over the years, I’ve worked with integrations involving platforms and services such as Docutech, ClosingCorp, MeridianLink, Surge, various CRM systems, and many other third-party services.
The real challenge isn’t simply getting one system to talk to another.
It’s making sure that the right data gets to the right system at the right time — and that everything still works when something inevitably goes wrong.
Data synchronization, inconsistent APIs, retries, timeouts, race conditions, unexpected data, partial failures, backward compatibility, and third-party outages are all part of the reality of building these systems.
And then there is the business itself.
When the Business Keeps Moving
Mortgage software doesn’t operate in a stable environment.
Interest rates change.
Regulations change.
Lenders change their processes.
Vendors change their APIs.
New requirements show up.
And sometimes all of that happens at the same time.
There are plenty of situations where a change that would normally take weeks has to be delivered in a matter of days.
That’s when software engineering becomes less about writing the perfect code and more about making good decisions under pressure.
How do you make a change without breaking an existing workflow?
How do you integrate with a system you don’t control?
How do you keep data consistent across multiple platforms?
How do you recover when a third-party API fails halfway through a transaction?
How do you design a system that can survive years of business changes instead of just passing today’s test cases?
These are the kinds of problems I’ve spent a lot of time dealing with.
What You’ll Find Here
This blog is not intended to be a textbook on mortgage software.
It’s a collection of real-world lessons, technical problems, architectural decisions, mistakes, and solutions that I’ve encountered throughout my career.
I’ll write about things such as:
- Encompass SDK and API development
- Encompass integrations and extensibility
- Migrating from legacy platforms to newer architectures
- Mortgage system architecture and integration patterns
- Data synchronization between multiple systems
- Third-party API integrations
- Handling failures, retries, timeouts, and inconsistent data
- Production troubleshooting and performance problems
- Designing software that has to survive constant business changes
- .NET and backend engineering
- Lessons learned from maintaining large, long-lived systems
Some posts may be highly technical.
Others may be about architecture or engineering decisions.
And occasionally, I may simply write about something that took me two days to figure out and that I wish someone had written about five years ago.
Why Write About It Now?
After doing this for more than a decade, I’ve realized that there are a lot of things I would have liked to know when I started.
Not everything can be learned from documentation.
Documentation can tell you how an API is supposed to work.
It doesn’t always tell you what happens when the API behaves differently in production.
Architecture diagrams can show you how systems are supposed to communicate.
They don’t always show you what happens when one of those systems goes down at 2:00 AM.
And experience teaches you things that are difficult to find in a search engine.
So this blog is my attempt to put some of that experience into words.
If you’re working with mortgage technology, Encompass, Vesta, integrations, distributed systems, or simply large business applications that have been evolving for years, I hope you’ll find something here that saves you a little time, prevents a future headache, or at least makes you feel better about the strange problem you’re currently trying to solve.
Because if there’s one thing I’ve learned after more than ten years of building mortgage software, it’s this:
The difficult part is rarely making the happy path work.
The difficult part is making everything keep working when the real world gets involved.