Proprietary Lending Platform

The broker-facing website supports the full cycle of online mortgage application processing. Brokers can initiate loan registration, select loan programs (including CONV, FHA, VA, USDA), and submit applications directly through the platform. The system dynamically adapts subsequent form steps and validation rules based on user input and selected loan parameters, supporting over 50 loan statuses and various program types such as Standard, Construction, Renovation, and Streamline.

Our team migrated the front end from AngularJS to Angular 8. We refactored legacy components and implemented a modular architecture with reusable form logic, state management, and business rules abstraction. We also added new workflows for task notifications, which enabled brokers to assign and track borrower responsibilities in real time.

The borrower-facing website was similarly upgraded from AngularJS to Angular 8. This application allows borrowers to submit loan requests, upload supporting documents, and provide personal, employment, and financial information through guided multi-step forms.

Leobit implemented advanced form validation mechanisms, secure document upload flows, and real-time loan status tracking powered by SignalR for a dynamic user experience. The borrower portal also includes features for submitting eConsent, selecting loan types, and receiving automated notifications based on broker-assigned tasks.

Leobit redesigned and modernized the client’s mortgage rate comparison website, which enables users to generate real-time loan estimates based on personalized financial data. The original application, built on AngularJS, was fully reengineered and migrated to Angular 8 to improve performance, maintainability, and user experience. Our team adopted a component-based architecture and introduced a centralized state management system using RxJS.

At the core of the application is a custom-built mortgage calculator engine that processes inputs such as loan amount, property value, credit score, income, and debt-to-income ratio. The calculator dynamically fetches rate data and loan program parameters from the back end and Azure SQL Database, and generates side-by-side comparisons of available mortgage options (e.g., fixed vs. adjustable rates, FHA vs. CONV loans).

To ensure high performance and data accuracy, we implemented debounced form input handling, client-side validation, and API throttling for real-time requests. The calculator also integrates with the customer’s Mortgage Pricing Engine to reflect the latest rates, overlays, and eligibility rules in real time.

The customer’s platform was originally built on Microsoft Azure, but to meet the evolving demands of performance, scalability, and maintainability, it required significant architectural enhancements. Leobit modernized the system by using a broad set of Microsoft Azure technologies within an Azure-first infrastructure approach.

We used Azure SQL Database to ensure reliable, high-performance relational data storage with intelligent autoscaling, geo-replication, and automated backup and restore. To enable real-time data interactions, such as instant form validation, loan status updates, and broker notifications, we integrated Azure SignalR Service. Azure Functions power many serverless, event-driven processes, including back-end triggers, automated workflows, and document processing, significantly reducing infrastructure overhead.

For monitoring and diagnostics, our team embedded Azure Application Insights across services to provide real-time visibility into application health and performance metrics. And to ensure continuity during the migration phase, we supported legacy components and testing environments through Azure Virtual Machines.

Sensitive documents and assets are securely stored using Azure Blob Storage, with encryption and lifecycle management in place. To protect sensitive data and ensure compliance, Leobit implemented Azure Key Vault for secure secret, key, and certificate management, and Azure Entra ID (formerly Azure Active Directory) for managing user identities, Single Sign-On (SSO), Multi-Factor Authentication (MFA), and Conditional Access policies.

We used Azure AD Privileged Identity Management (PIM) to enforce least-privilege access principles, allowing secure role elevation only when necessary. To manage asynchronous communication and ensure loosely coupled service integrations, our team introduced Azure Service Bus and Azure Event Grid.

To ensure continuity during the migration phase, we supported legacy components and testing environments through Azure Virtual Machines. We also used Azure Blueprints to provide governance and configuration standardization across environments.

To address the complex and dynamic educational needs of brokers and lenders, Leobit developed a custom content management system (CMS) from the ground up. This bespoke platform powers a centralized hub for mortgage professionals to access the latest industry updates, loan program guidelines, overlays, delivery options, and essential forms.

We used Angular for the front end and .NET Core for the back end. The CMS supports real-time updates, dynamic cross-linking between related content, and personalized content delivery based on broker type or delivery channel. Unlike off-the-shelf CMS solutions, which failed to support the company’s interconnected mortgage guidance structure, the custom solution provides the flexibility and performance needed to serve a broad and evolving user base. The result is a significant reduction in onboarding time and support inquiries, as well as a more intuitive and informative experience for brokers engaging with the company’s educational content.

The customer previously relied on a Third-Party Originator (TPO) platform and required brokers to submit PDFs, which the company’s staff manually processed. Leobit replaced this workflow with dynamic, automated web forms hosted in Azure and integrated with internal systems. This new centralized platform significantly simplified how brokers interact with the company. It offers them access to instant loan registration, real-time condition tracking, seamless document uploads, and direct messaging with the company’s staff.

Internal departments now receive structured data inputs and pre-filled 1003 forms ready for review, which significantly eliminates manual data entry and reduces processing time. As a result, brokers now experience a faster, more transparent, and more efficient workflow than what most competitors provide. These improvements have translated into tangible business outcomes: year-to-date, the company has funded 65.6% more loans, compared to the same period last year.

The platform runs across ten Azure environments in three subscriptions, with roughly fifty application resource groups per environment and thirteen application repositories deploying through shared pipeline templates, around 500 deployments in total. Provisioning was built on Azure Blueprints, which Microsoft has deprecated. The customer needed a replacement that would adopt hundreds of live resources without recreating them, without downtime, and without the configuration drift that years of portal edits had introduced.

Leobit designed and led the migration to Azure Deployment Stacks and Bicep. Our team replaced four blueprint definitions with two Bicep orchestrators built on a library of 26 reusable modules covering App Services, Function Apps, WebJobs, Key Vaults, storage, networking, messaging, and role assignments. Each application keeps one typed parameter file per environment that compiles locally in seconds, so misconfiguration is caught on the engineer’s machine rather than in Azure.

The migration runs through DevOps practices designed for zero-surprise releases. A parallel set of Azure DevOps pipeline templates lets every application switch to the new deployment engine by changing a single reference, while the legacy path stays available as rollback insurance.

Every deployment runs a What-If preview and a drift gate before anything is applied. The gate compares live application settings against the planned state and blocks any deployment that would silently drop a key.

Adoption was done live and non-destructively: our engineers took existing resources under management in place, verified them against before-and-after snapshots, and rehearsed the process in a disposable sandbox environment that mirrors a real one and is created and destroyed by script. Because Deployment Stacks tracks resource state, resources no longer defined in configuration can now be identified and removed safely. Deployment previews replaced guesswork across the platform.

Leobit built a system for downloading large volumes of documents from third-party providers, replacing a fully manual workflow in which employees entered the external system, downloaded the required files, created folders with specific names, and distributed the files among them by hand.

The solution runs on the same Azure Durable Functions foundation as the rest of the background task system. The platform specifies which documents are required; once they are available, Azure Event Grid signals that the files have been downloaded. The files are temporarily stored in Azure Blob Storage, and the background task system picks them up and distributes them into the appropriate folders automatically. The workflow now runs at high volume in production.

The platform’s background processing ran on a legacy system with three limitations: very little concurrency, almost no observability, and an SDK slated for deprecation. A background task exposed only three statuses — new, in progress, and finished — and when something failed, there was no way to see where.

Our team redesigned the system around Azure Durable Functions, which preserve state at every step of a workflow. When a task fails, the exact failure point is identifiable, and the process resumes from the relevant step rather than from the beginning. Events are generated continuously as a task runs and stored for analysis, giving a complete record of every step performed. Leobit also developed an Angular-based UI that presents this trace: when a customer reports a problem, support specialists see exactly what the system did and where it failed. The team is now migrating the remaining legacy background tasks onto the new architecture.

Document uploading is a background process: a user uploads a document to the customer’s system, and the platform then transfers it to the third-party services used for loan processing. Users previously could not tell whether a document had merely reached the customer’s system or had actually arrived at the external service, and loans failed to close because documents everyone believed were uploaded had never reached the third-party platform.

Our team introduced task events that continuously report changes in upload status. The system now distinguishes whether a document is still processing, has not yet reached the third-party platform, has uploaded successfully, or has failed, and displays these statuses in the UI, so users see problems immediately.

Failed transfers retry automatically, since the document data already sits on the customer’s servers. Scheduled .NET jobs scan the database for documents with no associated background task or a failed one and restart processing, while Azure Service Bus queues problem documents for a dedicated worker to reprocess one by one.

Concurrency is managed through a custom queue-partitioning mechanism. Task queues are normally tied to a specific loan and processed sequentially, but tasks with no ordering dependency, such as document uploads, run through a dedicated partitioned queue. Sixteen queues are available, incoming tasks are assigned to whichever has the lowest load, and processing is capped at 16 simultaneous uploads. Previously, with around 500 active loans and users continuously uploading files, the system could initiate hundreds of parallel uploads and hit rate limits imposed by third-party providers. The cap eliminated those failures.

The new system also stopped blocking work. Where the legacy system halted a loan’s queue while a user was actively working with that loan, the new one waits for an event signaling that work can continue, configurable up to about a day. Durable Functions also scale automatically with load — most important at the end and beginning of each month, when large volumes of new loans previously forced manual task restarts.