The way I approached this feature was by breaking down how recoveries actually work in practice, structuring it into a clear flow from operating expenses, to cost pools, to recovery rules, and finally to leases, making a complex and often opaque process much easier to understand and manage.
01
Problem
Recoveries are one of the most complex and frustrating parts of real estate modelling. Existing tools like Argus handle this through rigid, opaque workflows that are difficult to understand, even for experienced analysts, often requiring deep product knowledge with little visibility into how costs, rules, and leases connect. At Built AI this became a clear gap, users struggled to understand what costs were being recovered and why, there was no clear structure linking expenses to recovery logic and leases, and scaling this across portfolios only made things more confusing. This wasn’t just a usability issue, it directly impacted confidence in the numbers and ultimately in decision-making.
02
Challenge
This was a net-new feature with no real benchmark to follow. Argus is the industry standard, but its approach isn’t very intuitive, takes time to learn, and doesn’t scale well for modern workflows. That meant we couldn’t just copy and improve what already existed. We had to rethink it from the ground up, focusing on how to make complex financial logic easier to understand without losing the flexibility these type of users need. At the same time, it still had to handle real-world lease structures like caps, base years, and gross-ups, work across different units and lease types, and be solid enough for institutional investors like Howard Hughes Holdings.
03
Legacy Tools
Above, you can see the Argus Enterprise recoveries interface, where recovery logic is spread across multiple tables and inputs, requiring users to manually configure methods, link expenses, and define caps with little visibility into how everything connects, making the overall process difficult to follow and error-prone.
Fragmented Setup
Recovery logic is split across multiple sections, forcing users to piece together how everything works rather than seeing a clear flow.
Tenant-Level Only
All recoveries are defined per tenant, with no abstraction layer (like pools or reusable structures), leading to repetition and poor scalability.
Low Transparency
It’s difficult to understand what costs are being recovered and how, as rules, caps, and allocations are buried in different fields and tables.
High Cognitive Load
The interface requires prior knowledge of the system, making it hard to learn and increasing the risk of errors when setting up or modifying recoveries.
04
Solution
We introduced a structured, layered system that breaks recoveries into three clear parts: operating expenses, where all cost lines are defined and modelled; expense pools, where costs are grouped based on how they should be recovered; and recovery structures, where rules like method, caps, and base year are applied and then assigned to leases. This creates a clear mental model from costs → pools → structures → leases, replacing a black-box setup with something much easier to follow. As a result, users can clearly understand what is being recovered, control how it’s recovered, and apply the same logic consistently across a portfolio.
05
Operating Expenses
I've redesigned how operating expenses are defined and managed to better reflect how costs are handled in real-world scenarios. Instead of a rigid setup, users can add and structure costs at a granular level, assign clear categories like CAM, utilities, or non-recoverable, and control key variables such as time periods, growth, and variability over time. The focus was on balancing flexibility with clarity, allowing users to model detailed financial data while still understanding exactly what they’re inputting and how it behaves across the investment.
06
Expense Pools
Expense pools add a layer between costs and leases, allowing users to group expenses based on how they should be recovered instead of assigning them directly one by one. For example, costs like repairs, cleaning, and maintenance can sit under a single “Recoverable Operating Expenses” pool, while utilities, management fees, and taxes are handled separately. This makes the setup much easier to follow, as users are no longer mixing what a cost is with how it’s treated in recoveries. It also scales much better across assets, since the same pools can be reused and applied consistently, rather than redefining the logic for every lease.
07
Recovery Structures
Recovery structures are where users define how costs are recovered, building on top of the expense pools created earlier. From this screen, users can select which pools are included, set the recovery method (net, fixed, pro-rata), and configure rules like base year, caps, and gross-ups. Instead of spreading this logic across different areas, everything sits in one place, making it much easier to understand what’s driving the recoveries and to reuse the same setup across multiple leases.
08
Lease Assignment
Once a structure is defined, it can be applied directly to leases from the same screen. Users can select contracted or synthetic leases from the 'Assign Leases' table and assign them in bulk, while also seeing which leases are already linked at the top. This makes it easy to manage and update recoveries without jumping between different views, and reflects how the logic works in practice: define the rules once, then apply them consistently across the portfolio.
09
Outcomes
This system turned a previously opaque process into a much clearer and more structured workflow, creating a clean separation between costs, recovery logic, and lease application. It reduced the complexity of setting up recoveries for both new and experienced users, while improving confidence in the outputs by making the logic easier to follow. During feedback sessions, the C-suite at Howard Hughes Holdings highlighted that this approach will remove a significant amount of friction from their current workflows and make recoveries far easier to manage at scale.