Project Zoolander: Navigating the Integration of Trulia and Zuora: Enabling Market-Based Pricing by Zip-code

In the face of complex challenges posed by Trulia's evolving pricing model and the limitations of the Zuora billing system, my colleague Nico Raffo and I embarked on a mission to find a solution. Our goal was to seamlessly transition thousands of customers to a new pricing model while accommodating a myriad of pricing variations. Here's how we tackled the problem:

Zillow + Zuora = Zoolander

The Complexity of Zuora: Zuora, our chosen billing and accounting system, is a robust but generic solution designed to cater to the needs of various enterprise customers. While it served as an excellent system of record for transactions, its inherent complexity presented a hurdle for us.

Zuora's Black Box: Zuora provided APIs to interact with its system, but our pricing model was far too intricate for its capabilities. Trulia's pricing involved base prices, discounts, and variable pricing based on the desirability of each zip code, which could change monthly. Additionally, we offered various subscription options and discounts. Zuora's architecture, which assumed a fixed set of prices, didn't align with our dynamic needs.

Challenges in Communication with Zuora: Engaging with Zuora's team, we expressed our requirements: the ability to create new prices for each zip code whenever pricing changed, canceling old subscriptions, issuing refunds, and initiating new subscriptions with prorated pricing—all while maintaining accurate accounting. However, Zuora had not considered this use case and needed time to assess its feasibility.

A Looming Deadline: With a tight project deadline, our situation became critical. Trulia was experiencing rapid growth after going public, and any disruptions in this phase could be detrimental. After consulting with our manager, we decided to move forward, assuming we had to work within Zuora's existing capabilities and limitations.

Our Solution: We devised a solution that relied on adapters and building our own system to emulate Zuora's functionality. This approach allowed us to maintain our pricing model independently and provided flexibility to switch to Zuora if they eventually supported our requirements. Although this path came with some risks, we had direct access to Zuora engineers and were confident in our ability to collaborate effectively.

Architectural Considerations: Our system became the primary repository for the complex pricing model, encompassing every new zip code and monthly price. Custom fields in Zuora's subscriptions played a crucial role in referencing this data in invoices. However, this added complexity required us to perform calculations ourselves, considering previous subscriptions, invoice status, and future subscriptions. Zuora now functioned primarily as a system of record and payment processor.

The Adapter Pattern: Anticipating Zuora's eventual support for our use case, we implemented the adapter pattern. We assumed that Zuora would offer an API to retrieve necessary pricing information, execute transactions, and generate invoices when customers proceeded with their purchases.

Hiring a Contractor: The edge cases with Zuora began to show. We realized that it was not designed to handle this many product prices. Our Zuora instance's performance degraded significantly, and we had to hire a contractor to help us to understand the Zuora architecture and optimize our implementation. We also had to work with Zuora's engineers to resolve these issues. The contractor had been working at Zuora and was familiar with its architecture and inner workings. He helped us to think through ways to optimize our implementation and resolve the performance issues.

The Final Stretch: In the end, our approach allowed us to navigate the complex landscape of pricing models and billing systems effectively, ensuring Trulia's continued growth and success. Eventually, more engineers joined in varying degrees of involvement, and business, analytics, quality assurance, product, and design teams all played a role in the project's success. We were able to deliver the project on time and with minimal disruption to our customers... even if it did mean a few late nights and weekends.

Zoolander Team

Just months after we completed our integration, Trulia was acquired by Zillow. Zillow used Zuora. After the merger, Nico, Tejas, and I became responsible for integrating with Zillow. Zuora remained the system of record for several years. After the merger, we handed over the Zuora integration and our custom pricing system to the Zillow team. We went on to build the Premier Agent CRM.

Zoolander Jacket

Lessons Learned:

  • When working with third-party systems, it's essential to understand their limitations and plan accordingly.
  • For large scale complex issues, hire a contractor who has experience with the system. This will help you to understand the system's architecture and inner workings and optimize your implementation.
  • When faced with a complex problem, it's best to break it down into smaller, more manageable pieces.
  • Replace systems iteratively in small chunks. The Zuora project took nine months, plus more for polishing off the rough edges. In the end Trulia was acquired by Zillow, who had their own billing system. Moving in smaller chunks would have meant we could have delivered value sooner and handed over a more polished product to Zillow.
  • Reduce complexity wherever possible. In our case, we simplified the pricing model by removing discounts and offering a single subscription option, as well as limiting the cases where a contract could be canceled.