This browser is not actively supported anymore. For the best passle experience, we strongly recommend you upgrade your browser.
| 5 minute read

To develop or provide? Beta luck next time! Lessons from Corelogic v Landmark

This post is part of the Bristows’ SnippITs series, which pulls together the key practical takeaways from recent court decisions for the tech sector and beyond.

The TCC case of Corelogic U.K. Limited v Landmark Valuation Services Limited highlights the risks of ambiguity in relation to delivery obligations. In complex technology contracts that often run to hundreds of pages, it is key that the supplier’s core delivery obligations are clearly specified and not undermined by statements of intent or other provisions that could cut across such obligations.

Key Takeaways

The following takeaways are of particular relevance for customers of technology contracts and projects: 

  • Insist on clear supplier obligations: Ensure that provisions to deliver/implement or make software available are explicit and tied to relevant payment milestones where applicable.

  • Beware of permissive statements and agreements to agree: in this case, reference to Landmark “intending to produce” the API and to an “agreement… [being] reached at this stage” with regard to replacing the Beta interface called into question whether the API was required to be delivered at all.

  • Recitals matter: recitals should not be overlooked during negotiations. While they may not be viewed as enforceable obligations, courts will have regard to them when trying to support a particular construction.

  • Staff time and record keeping: where a supplier’s breach has resulted in the diversion of significant staff time, customers should keep contemporaneous records of time diverted from ordinary duties (even if time is not routinely recorded).

Background

Corelogic and Landmark both provided key software used adjacently within the UK mortgage valuation process. Landmark's DataWeb platform is used for every domestic mortgage valuation and Corelogic's SurveyHub is used by a very large proportion of mortgage valuation providers. The parties therefore shared largely the same customer base.  

In 2016, the parties entered into an agreement where Landmark would develop an Application Programme Interface (API) to allow SurveyHub to interoperate directly with DataWeb. This would also allow Corelogic’s customers to access DataWeb using the API. 

Pending the API's release, Corelogic was granted temporary access via a Beta interface. Landmark subsequently never took steps to develop and implement the API and Corelogic continued to operate via the Beta interface for the whole term of the Agreement (which was extended to March 2022) and was still using it at the time of the trial. 

In 2023, Corelogic asserted that Landmark was in breach of contract for failing to provide the API in place of a Beta interface during the term of the Agreement. Landmark accepted that it was required to develop an API under the terms of the Agreement but not that it was required to provide the API to Corelogic. Landmark further argued that Corelogic was estopped and/or had waived any breach by failing to demand the API for many years. 

Court Findings

  1. Develop or provide? 

Landmark argued that provision of the API to Corelogic was subject to further agreement between the parties, which had never been reached. In support of this, Landmark referred to Schedule 2 of the Agreement which stated that: 

“[Landmark] intends to produce a fully supported API which will provide the same levels of interoperability as the Beta Interface. The definition of this API will be shared with [Corelogic] and an agreement with regards to the replacement of the Beta Interface with the fully supported API reached at this stage. It is the intention of [Landmark] to remove the current milestone updates when the API is made available.” 

The court rejected Landmark’s argument. Reading the Agreement as a whole, Landmark was obligated to make the API available by the end of the term. The future agreement to agree contained in Schedule 2 concerned implementation mechanics and was not a precondition to providing the API (which would have required different express drafting). In coming to this decision, the court cited the following reasons: 

  • The recitals, definitions and operative provisions of the Agreement referred to: (i) the API being “made available” to Corelogic; (ii) Landmark notifying Corelogic when the API “is available”; (iii) Corelogic accessing the API “once developed” and “thereafter for the duration of the term”; and (iv) the Beta interface being a temporary interface. Landmark’s construction would rob these provisions of any real meaning. 

  • If Landmark truly believed that an API did not need to be provided, it was surprising it did not point this out to Corelogic, including during meetings in 2019 and 2022 when the parties discussed the desirability of an API.  

  • The Agreement included a £100,000 development fee. It would have been “most uncommercial” if this was payable by Corelogic without any certainty of a tangible result. 

  • Landmark had sought to rely on pre-contractual negotiations, including the removal of the word “provision” in one of the headings in the Agreement. The court found these discussions were inadmissible and, even so, there was no evidence that either party agreed the provision of an API was not required. 

  1. Waiver/estoppel 

According to Landmark, Corelogic benefited from the Beta interface and did not see the need for the API during the term of the Agreement. Landmark argued that a waiver or estoppel arose out of Corelogic’s continued performance of the Agreement for nearly eight years without protest and failing to allege a breach until 2023 (over a year after expiry of the term). Landmark produced evidence that by 2018 Corelogic knew that no API was being developed and had reported that “[Landmark] have not developed the API contemplated in the [Agreement] and as far as we are aware they are not intending to do so.”  

The court found that the non-waiver clause in the Agreement defeated Landmark’s waiver argument. It further rejected that Corelogic was estopped from asserting breach, citing the following reasons: 

  • While Corelogic did not raise the provision of an API extensively during the term, it was “clearly raised”. At no time did the parties share a common understanding that an API was no longer required. 

  • The provision of an API was not the most important issue on Corelogic’s mind while the Agreement was ongoing, however, Landmark had not demonstrated that Corelogic had expressly or impliedly abandoned the provision of an API. 

  • By 2022 Landmark had informed Corelogic that it would be developing a new Hub solution which would include an API. The court rejected Landmark’s argument that this was reference to a “new” API rather than the original/contractual API. The precise form of API to be provided was not identified in the Agreement. 

  • Landmark has failed to show any detrimental reliance (the court did not accept that being exposed to the present claim amounted to detriment for this purpose). 

  • Landmark’s estoppel argument was counterintuitive to its position that no API was required to be provided at all, creating a “certain air of unreality” to Landmark’s position.  

Outcome

The court ruled in favour of Corelogic. Of Corelogic’s claim of over £800,000, the court awarded damages of £332,405.44. This represented the costs of Virtual Machines necessary to run the Beta interface to the date of trial but excluded Corelogic’s claim for labour costs incurred in operating and maintaining the Beta interface. This aspect of the claim was an estimate for diverted internal staff time based on a blended rate of staff salaries and the court found that the costs had not been proved to the required standard (for example no time sheets or records were taken, even after the claim was threatened).

If it was intended that the further agreement was required before the API was made available, then in my judgment the wording of this part of Section 3 would have needed to be very different and the reference to "made available" in the Agreement would also have to be drafted differently... [T]he agreement to agree can only be properly interpreted as a matter of mechanics rather than a precondition to making the API available.

Subscribe to receive our latest insights - on the topics that matter most to you - direct to your inbox, at your preferred frequency. Subscribe here

Tags

snippits, bristowssnippits, commercial disputes, digital transformation, it disputes, technology, article