From Ambition To Dispute: Managing Risk In Technology Contracts
- RDS Project
- Oct 9
- 4 min read

In the realm of technology and IT service agreements, poorly defined obligations, ambiguous acceptance criteria and uncontrolled scope expansion can turn promising projects into costly disputes. The recent Court of Appeal decision in Skyworld Holdings Sdn. Bhd. v Neurogine Sdn. Bhd. [B-02(NCC)(W)-1312-08/2023] offers a cautionary case study on the structural weaknesses that frequently undermine such contracts.
The Dispute
In Skyworld, the Court of Appeal upheld the High Court’s ruling in a dispute arising from a contract to develop a mobile application ecosystem. Skyworld, the appellant, had engaged Neurogine to design and deliver the "Sky App", which was to be delivered in two phases: a chat module (Phase One) and an e-wallet with a payment gateway (Phase Two), all hosted on a cloud-based platform.
Skyworld alleged that the application, upon delivery for testing, was non-functional and failed to meet agreed specifications. On this basis, it sought a full refund of RM1.66 million, claiming a total failure of consideration.
Neurogine denied the allegations, arguing that Phase One had been completed, tested, and published to app stores, with only minor bugs outstanding. It contended that delays in Phase Two were caused by Skyworld’s own conduct, specifically, the refusal to make further payments and the revocation of developer access. Neurogine also pointed to change requests initiated by Skyworld, which had been separately quoted and partially paid. On that basis, Neurogine counterclaimed for RM 1.6 million in unpaid fees.
The High Court’s Findings
The High Court examined the contractual documents and technical evidence in detail. A key witness for Skyworld conceded under cross-examination that the quotation did not require delivery of the source code, nor did it specify a strict project timeline. The timeline that existed was internal and subject to change.
Evidence presented by Neurogine showed that Phase One had undergone two rounds of User Acceptance Testing (UAT) and two Factory Acceptance Tests (FAT), all of which were signed off by Skyworld’s technical advisor. The application had been published on both the Google Play and Apple App stores with only minor defects identified. Skyworld ultimately acknowledged that the functionality of Phase One substantially met the contract specifications.
Regarding Phase Two, the court accepted that development had stalled due to Skyworld’s revocation of access and non-payment, rather than any breach by Neurogine. It further found that additional features requested by Skyworld had led to a second quotation, for which part-payment was made. No objections were raised to the accompanying invoices, which contained a clause stipulating “deemed acceptance” after 15 days.
Skyworld’s claim based on “total failure of consideration” failed on both procedural and substantive grounds as it had not been properly pleaded and was inconsistent with the evidence that Phase One had been delivered. Accordingly, the court dismissed Skyworld’s claim and allowed Neurogine’s counterclaim.
The Court Of Appeal’s Position
The Court of Appeal affirmed the High Court’s decision, finding no basis for appellate intervention in the trial judge’s factual and legal findings. Skyworld’s appeal was dismissed.
Lessons For Technology Contracts
The Skyworld decision illustrates recurring vulnerabilities in technology-related contracts. These shortcomings are not novel, yet they continue to frustrate delivery and fuel disputes. Several key lessons emerge.
1. The Risk Of Vague Scope Definitions
Technology contracts often borrow from the language of general service agreements, an approach ill-suited to the technical complexity of IT delivery. Projects involving APIs, data flows, third-party integration, and cybersecurity require a clearly delineated scope. General descriptions (e.g. “develop an app that performs X”) are rarely sufficient.
Disputes often arise over hidden expectations about what “integration” or “completion” entails. To mitigate this, contracts should include a detailed Statement of Work (SoW) that defines both inclusions and exclusions. A contract-first API design approach where the API interface is specified before development begins can also help align expectations and reduce scope-related conflicts.
2. Fuzzy Acceptance Criteria Undermine Accountability
Ambiguously worded acceptance clauses such as “system must be functional” leave both parties exposed. Suppliers may press for premature sign-off; buyers lose leverage to demand necessary fixes.
Acceptance testing should be multi-layered and tied to objective metrics. For example, the contract should distinguish between integration testing (to verify module interoperability), user acceptance testing (to confirm real-world usability), and operational testing (to assess performance under load). Each phase should have defined criteria and allow for rejection or retesting in the event of defects including latent defects discovered post-deployment.
3. Uncontrolled Scope Creep Is A Silent Liability
Scope creep is almost inevitable in technology projects. Regulatory shifts, evolving user demands, and commercial pressures often necessitate changes midstream. The key is not to prevent scope creep, but to manage it effectively.
A robust change control process comprising formal change requests, documented impact assessments, and written approvals turns scope creep from a hidden risk into a manageable adjustment. Properly structured, this process ensures that both cost and timeline adjustments are transparent and agreed, preserving the commercial balance and reducing the risk of post-hoc disputes.
Conclusion
The failure of the Sky App project underscores a broader truth: technology contracts are often under-engineered for the complexities they govern. Clarity on scope, precision in acceptance, and discipline in managing change are not just best practices. Instead, they are essential safeguards. As the technology sector continues to mature, so too must the contractual frameworks that underpin it.
9 October 2025



