Custom Operational Mortgage Apps

Hey there,

Welcome to the new subscribers who joined our mortgage tech newsletter last week.

Today, let's talk about custom apps in mortgage operations.

Not so long ago, custom app development was prohibitively expensive. Only enterprise mortgage companies could justify the investment into a custom app.

But with the advance of developer tools, the cost and speed of custom app development have significantly reduced. Lower development costs make custom apps accessible to a much wider audience. And what was unfeasible for a small company 10 years ago can now make a sound business case.

The fact that more companies can now build custom apps for less is good. But what to do with it? What problems can a custom app solve in mortgage operations that neither automation nor operational analytics can?

In this issue, I'll share an overview of custom operational apps, how they work, and how they can be applied in mortgage operations.

Below, you can find my analysis of:

• What operational mortgage app is and is not
• How it relates to operational data, analytics, and automation
• How operational mortgage apps work
• How it can be applied to improve mortgage operations

What's an operational mortgage app

All apps are software, but not all software is an app. And while Spotify is definitely an app, it's far from operational.

So, let's start by defining what an operational mortgage app is.

An application or app refers to a subset of software that provides humans with a user interface (UI) to interact, access, or manage data.

An operational app is designed to manage and interact with data that enable the execution of workflows in day-to-day business operations.

An operational mortgage app is designed specifically to enable workflows in the operational aspects of mortgage lending. It focuses on loan processing, underwriting, servicing, and default management workflows.

How operational apps relate to analytics and automation

Operational mortgage apps are closely intertwined with operational automation and analytics. Understanding their similarities and differences helps to see what unique problems a custom app can solve.

Technically, analytics and workflow automation can also be considered apps, just different types of apps.

But for lack of a better word to describe this type of app, I use the term "operational app" to differentiate them.

Operational Mortgage Apps, Analytics, and Automation help build more efficient mortgage operations.

The main difference lies in how they help achieve this goal:

• Analytics helps to answer questions based on operational data.
• Automation reduces the number of manual tasks humans must perform in the workflow.
• Operational apps enable humans to execute manual tasks more effectively.

Also, analytics and automation rely on the same operational data as operational apps.

Thus, operational apps often serve as a means of capturing and managing data consumed by analytics and automation.

How operational mortgage apps work

Most operational apps can be distilled down to five key concepts:

• Input UI (User Interface)
• Tasks
• Workers
• Data source
• Output UI

Through the Input UI, the end user creates Tasks for Workers. Workers (software) process Tasks. Workers often rely on the Data source to complete the Task. The end user sees the result of the completed Task through the Output UI.

Below is a more in-depth overview of each concept.

Input UI

Input UI consists of user interface components allowing users to enter data, make selections, or initiate workflows without deep technical knowledge.

Input UI serves as a means for the end user to create Tasks for Workers.

There are many different UI mediums to provide input, such as forms, audio, chat, video, etc.

Operational apps predominantly rely on form-based UIs, which usually include:

1. Text Fields: Users can enter text for inputs like names, addresses, or other textual data.
2. Buttons: Used to submit data, initiate actions, or navigate through the app.
3. Toggle Switches: Enable users to choose between two opposing states: on/off or yes/no.
4. Checkboxes: Allow users to select one or more options from a set.
5. Radio Buttons: Permit the selection of a single option from multiple choices.
6. Dropdown Menus: Provide a list of options for users to select one.
7. Sliders: Let users choose from a range of values by moving the slider thumb.
8. Date Pickers: Offer an easy way to select dates without manual typing.
9. File Upload Inputs: Enable users to upload files from their devices.

Tasks

Tasks are the means to get Software Workers (pieces of code running on the backend) to take action. The end user creates Tasks through the Input UI.

A single Task can be described by:

• Action type: What to do
• Action input: Input needed to take an action
• Action output: Output produced as a result of the action
• Task status: The state of the task

Here are a few common action types in operational apps:

• Create a new entity: Initiate the creation of a new record, such as a loan or borrower profile.
• Find one or multiple entities: Searching for specific records within the database.
• Update existing entity: Modifying details of an existing record.
• Delete existing entity: Removing a record from the system.
• Run automated workflow: Executing a predefined sequence of tasks automatically.

Operational apps predominantly use tasks to manage entities in operational data, such as:

• Loans
• Borrowers
• Rate locks
• Products
• Documents
• Etc.

Workers

In the App context, a Worker refers to a piece of code running on the servers that processes the Task queue.

Workers execute Actions defined by the Tasks. They take an input from the task, perform an action based on that input, and then produce an output.

Workers possess a skill set that defines which Actions they can perform. Their primary skill set in operational apps is interacting with the Data source.

Here are a few Tasks examples that illustrate how it all comes together:

1. Create a new loan

• Action type: Create a new loan
• Action input: New loan information
• Action output: New loan ID
• Task status: Todo

2. Find multiple loans

• Action type: Find loans
• Action input: Time frame and other filters
• Action output: List of loans that meet the filter criteria
• Task status: In progress

3. Run automated underwriting

• Action type: Run automated underwriting
• Action input: Loan details to be underwritten
• Action output: Underwriting findings
• Task status: Completed

Data source

The data source is where Workers retrieve the operational data needed to complete tasks.

Typically, it consists of either a Database or the APIs of another app.

In the context of an operational mortgage app, the data source usually contains entities such as:

• Loans
• Borrowers
• Products
• Documents
• Etc.

Output UI

Output UI refers to the user interface components designed to present data to the user.

When Workers take an action, they produce an output. The Output UI is how the end user consumes this output.

The most common UI components for displaying outputs in an operational app include:

• Tables: For displaying lists of entities, such as loans or borrowers, simultaneously providing a clear overview of multiple items. Tables often feature sorting and filtering capabilities to help users navigate large datasets efficiently.
• Detail Pages: For showing detailed information about a single entity, such as a specific loan or borrower. These pages typically organize data into sections or fields, allowing users to review comprehensive details in a structured format.

How to use custom operational apps to improve mortgage operations

Automation eliminates manual tasks within a workflow.

A custom operational app enables individual team members to complete manual tasks within the workflow more efficiently.

Below is my analysis of how operational apps achieve this.

Consolidate data and tools

To complete a task, individuals executing the workflow typically need access to operational data and tools to take action.

Data is often siloed across multiple applications, and actions must be taken in various places. This fragmentation requires jumping from one tool to another, resulting in significant context switching.

Context switching takes a toll on the productivity of the operations team. It slows the workflow and increases the risk of errors as team members lose focus and momentum.

A custom operational app can consolidate the necessary data and tools into a single interface, allowing individuals to execute their workflows more efficiently.

By reducing the need for context switching, a custom app significantly increases a person's productivity and streamlines the entire operational process.

Remove IT dependencies

Some workflows include tasks that need technical expertise.

When the person carrying out the workflow lacks these technical skills, they must depend on someone who has them.

This reliance on others can introduce delays in the workflow execution process, slowing operations and increasing the time needed to finish tasks.

A custom app can provide the end user with a user interface (UI) that allows them to complete these tasks without needing technical skills.

Doing this significantly reduces the need for assistance from others, thus speeding up the workflow execution.

Remove data dependencies

Like IT dependencies in a workflow, there can be data dependencies.

When the person executing the workflow doesn't have the data they need to finish it, they have to rely on someone who does.

This often happens due to different permission levels for various apps, lack of physical access (like being unable to access a desktop app while on the go), or because it's not cost-effective to add another user to a product just to access a small part of the data.

Having to depend on others for data slows the workflow execution process and increases the chance of mistakes.

A custom app can give the end user a user interface (UI) that provides the data they need to complete the task without compromising security or purchasing extra licenses.

Removing data dependencies has a ripple effect on team productivity.

Everyone involved in the process gets time to focus on their work:

• A person who needs the data can finish their part without delay
• A person who has the data can concentrate on their tasks without interruptions.

Data dependencies can also be external, such as when a borrower needs access to information about their loan.

While removing external data dependencies might not significantly impact internal operations, it can improve the experience for external parties.

How to build custom operational mortgage apps

Not so long ago, the only option to build a custom operational app was through custom coding. It was prohibitively slow and expensive.

Today, new developer tools significantly increase speed and reduce custom app development costs. First, because developers don’t need to spend time on boilerplate. And second, because of lower stakes, less time is spent planning everything up front.

Despite significant advancements in the tools for custom app development, the foundational process remains unchanged.

Here’s a high-level overview of the process of building a custom operational app:

1. Identify the workflow you’re looking to improve
2. List manual tasks that compose the workflow and the people involved
3. Define what data and tools are needed to complete the task
4. Design a prototype of the UI that will enable users to complete them
5. Test the prototype with the end user and make edits if required
6. Build, test, and deploy the app

Here are some of the modern dev tools for building custom apps:

• UI → Retool
• Workflow Automation → Retool/Windmill.dev
• Database for Entities → Supabase
• Database for Events → ClickHouse
• Serverless functions → Supabase
• Managed event streaming platform → Kafka by Upstash

An in-depth article on building operational mortgage apps is coming soon.

What’s next?

I hope this post gave you insight into Custom Operational App development and how it can be used in mortgage operations.

If you’d like to stay on top of the latest mortgage tech and how it can be applied to mortgage operations, consider joining our mortgage technology newsletter.

‍