Experience detail · Feb – May 2022
Software Developer (Freelance) @ eXp Realty
Project overview
Real-estate commission calculations can vary significantly depending on taxes, commission tiers, listing and selling percentages, referrals, flat-rate agreements, and other transaction-specific conditions. Realtors were documenting these cases through a fillable PDF containing embedded formulas, but the density of fields, hidden calculations, and navigation made the form difficult to complete, particularly for older users.
I co-developed the second iteration of a web-based commission calculator designed to preserve the underlying business rules while making the process easier to understand and complete.
My role
I joined after an initial version of the calculator had already been built. My responsibility was to understand the existing implementation, incorporate a more complex set of calculation requirements from the client, redesign the interaction flow, and add PDF export.

Problem
The interface exposed all of the calculation’s complexity
The existing fillable PDF asked realtors to navigate a large collection of fields and embedded formulas even though many fields were irrelevant to a particular transaction. Which values were required depended on earlier decisions such as the tax option, commission structure, referrals, or whether a flat-rate agreement applied.
As the client introduced more calculations, simply adding fields risked making the experience even harder to follow and increasing the chance that users would miss information required later in the calculation.
Solution
Make the interface adapt to the transaction
I helped restructure the calculator around conditional workflows. Instead of showing every possible input at once, the interface revealed relevant fields based on earlier selections and used clearer labels, required-field indicators, button states, and validation messages to guide users through the transaction.
Behind the interface, I incorporated the client’s expanded calculation rules and preserved the ability to export the completed information into the required PDF format.
How I worked through it
A closer look at the process
- 01.
Understanding the System Before Changing It
Because I was working on the second iteration, I could not start by rebuilding everything around my preferred structure. I first needed to understand how the existing code handled inputs, conditional fields, and calculations and determine which pieces could support the new requirements.
I traced the existing calculation flow, identified reusable components, and separated areas that could be extended from those that needed revision. This allowed me to add new behavior without unnecessarily disrupting functionality that had already been implemented successfully.
- 02.
Turning Business Rules Into Executable Logic
The hardest part was not any individual formula, but understanding how the formulas depended on one another. The final commission could change according to taxes, number of tiers, listing and selling percentages, referrals, flat-rate agreements, and other conditions, so one misunderstood rule could affect several calculations downstream.
Before implementing the expanded logic, I listed the formulas, separated them into steps, and diagrammed how the conditions connected. I reviewed those interpretations with the client before translating them into code, reducing the risk of a technically correct calculation based on an incorrect understanding of the business rule.
- 03.
Showing Only What the User Needs Next
Supporting every commission scenario created a UI problem. Showing every field simultaneously would reproduce the crowded experience of the original PDF, but removing fields entirely would prevent the application from handling more complex transactions.
I redesigned the interaction around progressive disclosure. Inputs appeared when earlier choices made them relevant, while clearer labels, required-field indicators, selected-button states, and validation messages showed what was still needed. The complexity remained in the system, but the user no longer had to confront all of it at once.
Outcome
What changed — and what I learned
The second iteration expanded the calculator beyond its original set of simpler cases while making the growing number of conditions easier to navigate. I contributed new commission logic, conditional interface behavior, validation, usability improvements, and PDF export while working within an inherited application rather than starting from scratch.
The project taught me two lessons that have carried into later work: complex business logic should be modeled and validated before it is translated into code, and technical complexity does not need to become user-facing complexity. A well-designed interface can progressively reveal what a user needs while the application manages conditional logic underneath.

eXp Realty commission calculator