Mortgage Rate Calculator

This particular company already had a custom-built WordPress site, but was looking to add a feature to increase conversions by helping its visitors calculate mortgage rates. We were then tasked to build out this user interface (UI), which matched up with a mortgage rate calculator API they had “already” built. They also wanted us to send each one of these calculations, and its associated user data, to a 3rd-party customer relationship manager (CRM), which will allow them to immediately reach out to the visitor for more info.

As previously mentioned, this site built with WordPress. So our options were to either leverage some type of form builder plugin, such as Gravity Forms, or handle everything client-side with JavaScript. Due to some on the challenges / constraints I’ll mention later on, we ended up going for the latter.

Since user provided data needs to be persisted as they proceed through the mortgage rate questionnaire, we needed a solution that prevented data loss as someone continued from one “page” to the next. We also didn’t want force a refresh of the page as we were fetching their calculations and sending off their data. To us, this sounded like a great reason to use React.

While the UI was being built, a custom WordPress API endpoint was also being worked on to handle the calculator and CRM submissions. This was done in order to keep the API credentials safe and away from any users. It also allowed for the data to be parsed and mapped to any appropriate value the API needed.

The primary challenge of this project was when and how we were sending the calculations to their CRM. When someone stopped filling out the form and left, be it after the calculation or right after they agreed to get started, the client wanted whatever data we’d collected up to that point to be sent. This would have been a simple task if their CRM allowed for updating or records on an unassigned account, but that wasn’t the case. We were limited to only creates.

The solution to this problem required us to create two event listeners: one for when the user finalized the calculation and another when they closed their window. The former is how it’s done in any other situation, so we proceeded without issue there. The latter, however, proved to be more difficult. We needed to tap in the browsers “unload” event, which gets triggered when someone closed out of the window or leaves the page. This allowed us to send what we had, if it hadn’t been sent already.

I built out both the UI and WordPress (PHP) endpoints for this project, though did not build out any WordPress specific functionality. The calculator continues to evolve to this day, adding / updating the initial functionality I put in place. My involvement, however, dropped off after the initial build was finalized and in production for 6 months.