SaaS and Software Development Agreements in Malaysia: What Founders Must Lock Before They Sign

A software development or SaaS agreement should say, in writing, who owns the code once it is built, what uptime the vendor is bound to deliver, who holds a copy of the source code if the vendor disappears, and how much either side can be liable for if it goes wrong. Malaysian law already sets a default answer to the first question — and it usually surprises the party paying for the work. This article covers the five terms a founder or in-house counsel should check before signing, and what each one costs to get wrong.

Most founders assume that if they paid for custom software, they own it. Malaysian copyright law actually agrees with that instinct by default — the problem is that most vendor-drafted contracts quietly override the default in the vendor's favour, and founders who never read past the payment schedule never notice.

Who owns the code once it is built?

Under section 26(2) of the Copyright Act 1987, where a work is commissioned by a person who is not the author's employer, copyright is deemed transferred to the person who commissioned the work — subject to any agreement between the parties excluding or limiting that transfer. In plain terms: if you pay an outside developer to build you software and there is no contract saying otherwise, the code is yours by default, not theirs.

The catch is the last six words. Most software development houses and SaaS vendors use their own paper, and standard vendor templates routinely displace the statutory default — granting the client a licence to use the software rather than ownership of it, while the vendor keeps the underlying code, any reusable components, and the right to build the same thing for a competitor next month. Neither position is illegal. The problem is founders who assume the statutory default protects them without checking whether the signed contract has already contracted out of it.

What to check: does the agreement assign copyright outright, or only grant a licence? If it is a licence, is it exclusive or non-exclusive, and does it cover modifications your team makes after delivery? Pre-existing tools and libraries the vendor brings to every project are usually excluded from any assignment — reasonably so — but the agreement should say exactly which components fall into that carve-out, not leave it to be argued later.

What must the vendor actually deliver, and by when?

A development agreement without a defined scope and acceptance process is not really an agreement — it is an invoice waiting to happen. Lock three things: a scope document detailed enough that both sides can point to it and agree whether a feature was delivered; milestone dates tied to payment tranches, so the vendor is not paid in full before the client has tested anything; and an acceptance testing window with a defined process for rejecting non-conforming work and requiring it to be fixed before final payment falls due.

Without an acceptance mechanism, a common dispute pattern emerges: the vendor treats delivery as complete once code is handed over, the client treats it as incomplete until it actually works, and the contract is silent on who is right. If the relationship then breaks down entirely, the termination mechanics in the underlying contract — not just this development-specific dispute — determine what either side can recover; see our guide to contract termination in Malaysia for how termination-for-cause and termination-for-convenience clauses interact with an unfinished build.

What happens if the platform goes down?

For a SaaS agreement specifically, the uptime commitment is the commercial heart of the deal. A service-level commitment should state a specific uptime percentage, how it is measured and over what period, what counts as an excluded outage (scheduled maintenance, force majeure, client-caused downtime), and what the client actually gets if the vendor misses the target — typically a service credit against future fees, calculated on a stated formula.

Where an SLA sets a pre-agreed service credit for a missed uptime target, that credit is functioning as a stipulated sum for breach, and Malaysian courts assess those under section 75 of the Contracts Act 1950. The modern position, following the Federal Court's decision in Cubic Electronics Sdn Bhd (in liquidation) v Mars Telecommunications Sdn Bhd [2019], is that a stipulated sum is recoverable without the claimant having to prove its actual loss, and will only be struck down as unreasonable if it is extravagant or unconscionable compared to the greatest conceivable loss from the breach — the burden sits with the party resisting the clause to show that. In practice, a service credit that is proportionate to the fees actually paid for the affected period is very unlikely to be disturbed.

Who holds the source code if the vendor disappears?

A SaaS platform a business depends on operationally should not be a single point of failure sitting entirely inside a vendor's infrastructure. A source-code escrow arrangement — a copy of the current source code held by an independent third-party escrow agent, released to the client on defined trigger events such as the vendor's insolvency, abandonment of the platform, or sustained failure to meet support obligations — is the standard commercial answer. It matters most where the vendor is a small or early-stage software house rather than an established platform, and it is a routine ask, not an aggressive one.

How much can either side be liable for?

Limitation of liability clauses are enforceable in Malaysia as a matter of ordinary contractual freedom for business-to-business agreements — there is no equivalent to the UK's Unfair Contract Terms Act controlling B2B liability caps here. The commercial question is not whether a cap is enforceable, but where it is set, and what carve-outs sit outside it. A cap set at 12 months' fees is standard; a cap that also excludes the vendor's liability for its own data breaches, IP infringement, or wilful misconduct is worth pushing back on, since those are exactly the failure modes a client cannot self-insure against once the platform is embedded in the business.

Undocumented ownership and an uncapped or under-capped liability position both tend to surface at the worst possible time — when a business is being sold and a buyer's lawyers are checking exactly this kind of paperwork; see our guide to red flags in legal due diligence for how gaps like these get priced into a deal.

What about the data running through the platform?

If the SaaS product processes personal data — customer records, employee data, or any information relating to an identifiable individual — the Personal Data Protection Act 2010, as amended by the Personal Data Protection (Amendment) Act 2024 (Act A1727), is directly relevant to the contract, not just to the business generally. Two obligations introduced by that amendment are worth flagging specifically: a mandatory Data Protection Officer appointment for organisations meeting the prescribed processing thresholds, and a data breach notification duty running on tight statutory timeframes. Multiple established Malaysian law firms — DLA Piper, Mayer Brown, and One Asia Lawyers, checked independently — confirm these took effect from 1 June 2025, gazetted under P.U.(B) 522/2024, with implementing guidelines issued by the Commissioner (JPDP) in February 2025.

The development or SaaS agreement should state which party is the data controller and which is the processor for data flowing through the platform, since the obligations attaching to each role differ, and should require the vendor to notify the client promptly of any breach affecting the client's data — not rely on the vendor's own regulatory notification timeline as the client's only warning.

What to lock before you sign

What it costs to get this wrong

The cost rarely shows up while the relationship is going well. It shows up when the vendor relationship ends and the business discovers it does not own the platform it has been running on for two years, or a customer sues over a data incident and the liability cap does not exclude that scenario, or a buyer's due diligence team flags the missing IP assignment and prices a discount into the deal three weeks before signing. Each of these is a documentation failure, not a technical one, and each is fixable in the contract before the relationship starts — not after it has already gone wrong.

Frequently Asked Questions

Who owns custom software built by an outside developer in Malaysia?

By default, under section 26(2) of the Copyright Act 1987, the person who commissioned and paid for the work owns the copyright — unless the contract says otherwise. Many vendor-drafted contracts do say otherwise, so the default is a starting point to verify, not a guarantee.

Do I need source-code escrow for a SaaS subscription, or only for custom-built software?

It is most relevant wherever the business is operationally dependent on the platform and the vendor is not a large, established provider. A subscription to a major platform with strong continuity of its own carries less need for it than a bespoke build from a small vendor.

Are limitation of liability clauses enforceable in Malaysian commercial contracts?

Yes, as a matter of ordinary contractual freedom between businesses. There is no general statutory control on B2B liability caps equivalent to consumer protection legislation. The negotiation is over where the cap is set and what is carved out of it, not whether a cap can be agreed at all.

Does a service credit for missed uptime need to reflect the client's actual loss?

No. Following the Federal Court's approach in Cubic Electronics v Mars Telecommunications [2019] under section 75 of the Contracts Act 1950, a reasonable, proportionate service credit is recoverable without proof of actual loss, provided it is not extravagant compared to the worst-case harm from the outage.

Does the Personal Data Protection Act apply to a B2B SaaS contract?

If personal data of individuals — customers, employees, or users — passes through the platform, yes. The contract should state which party is the data controller and which is the processor, and set out breach notification obligations between them, separate from each party's own regulatory duties.

Getting this documented properly

A software development or SaaS agreement is one of the few contracts a growing business signs where the biggest risks — who owns the product, what happens if the vendor fails, and how exposure is capped — sit outside the parts most founders actually read. Legal That Works advises Malaysian businesses on software development and SaaS agreements — from IP ownership and SLA drafting through to liability and data-handling terms — and on technology and IP licensing where the deal involves licensing the software itself rather than commissioning a build. If you are about to sign a vendor's standard paper, have it checked before you sign, not after a dispute starts.

This article is for general information only and does not constitute legal advice. Every transaction and every set of facts is different. Obtain specific advice from a qualified adviser before acting on any part of it.

Related guides

• Contract termination in Malaysia

• Breach of contract: remedies and options

• Red flags in legal due diligence