Software disputes almost never turn on code. They turn on whether the deliverable was defined, whether a change was authorised, and whether acceptance ever formally happened.
Those are contract questions, and they are decided by three or four clauses.
Development: fixed price or time and materials
Fixed price transfers risk to the supplier. It only works where the scope is genuinely defined, which in software it rarely is. Suppliers who price fixed against a vague specification lose money and then argue about variations.
Time and materials transfers risk to the customer, who needs governance — reporting, budget caps, and the right to stop.
Capped time and materials, with a change mechanism, is usually the workable middle.
Whichever is used, the contract must define scope in a schedule specific enough to argue about, and must say what happens when it changes.
The clauses that actually decide disputes
Change control. The most important clause in any development agreement. Written requests, written approval, agreed impact on price and timeline, before work starts. Without it, every dispute becomes "you agreed to that in a meeting".
Acceptance testing. Define the criteria, the test period, what constitutes a material defect, how many correction cycles the supplier gets, and — critically — what happens if the customer says nothing. Deemed acceptance after a stated period protects suppliers from projects that never formally end. Its absence is why final payments sit unpaid for years.
Milestones and payment. Tie payment to milestones, and make the final tranche payable on acceptance rather than on some undefined satisfaction.
IP ownership. Usually assigned to the customer on payment. Suppliers must carve out pre-existing tools, libraries, frameworks and know-how, licensed to the customer for use in the deliverable. Without that carve-out you assign the components you reuse on every project.
Open source. Disclose what is used and under what licence. Enterprise customers audit for copyleft obligations, and a discovery mid-project is expensive. See open source licensing compliance.
Third-party components — who pays for licences, and what happens if a vendor changes terms.
Warranty period after acceptance, and what is covered versus chargeable support.
Limitation of liability. A cap, usually tied to fees paid, and exclusion of indirect and consequential loss including loss of profit and data. Uncapped liability on a modest development fee is not a viable business.
Termination, and what happens to work in progress, code and payment.
Escrow of source code where the customer depends on a system a small supplier maintains. See escrow arrangements.
SaaS and subscription terms
A different animal: the customer never owns anything, and the supplier's obligations are continuing.
Licence and scope of use — named users or capacity, permitted affiliates, restrictions on resale and benchmarking.
Service levels. Uptime commitment, how it is measured, exclusions for maintenance, and service credits as the remedy. Suppliers should make credits the sole remedy for downtime; customers should insist on a termination right for sustained failure, because credits alone do not solve a business outage.
Support, with response times by severity — and note that response time is not resolution time. Say which you are promising.
Data. The customer's data remains the customer's. Say so expressly, and cover where it is hosted, who may access it, security standards, breach notification, and sub-processors. If the customer is in the EU or UK, their contract will require processing terms that flow through to you. See data protection for Pakistani businesses and responding to a data breach.
Exit and data return. How the customer gets its data out, in what format, over what period, and what happens after. This is the clause customers regret omitting and suppliers regret conceding loosely.
Price increases on renewal, with notice and a cap.
Suspension for non-payment, with notice — and for customers, protection against suspension over a disputed invoice.
AI features. Where the service uses AI, address whether customer data is used for training, and who owns and is responsible for output. See using AI in your business.
For Pakistani suppliers selling abroad
Governing law and forum. Foreign customers will push their own. What matters commercially is enforceability: a judgment from a foreign court is difficult to enforce in Pakistan, and vice versa. Arbitration with a properly specified seat usually serves both sides better. See drafting an arbitration clause and enforcing foreign judgments and awards.
Withholding tax on payments to you in the customer's country, and treaty relief. Address it in a tax clause, and decide who bears it — a gross-up clause is worth more than the argument later.
Currency and payment channel — proceeds must come through the proper channel and be documented. See setting up a software house and freelancers and IT exporters.
Non-solicitation of your staff, which foreign customers hiring your developers makes a live issue.
For Pakistani customers buying software
The mirror position. Insist on: acceptance criteria you have actually reviewed, IP assignment on payment, source code escrow where you depend on the system, a data export right, a cap you are comfortable with, and a documented change process.
And do the basic diligence: does the supplier exist as a legal entity, who owns the code they are reusing, and what happens if the two people who built it leave?
When a project fails
Before escalating, do four things:
- Read the contract — acceptance, change control, termination and notice
- Assemble the record — the specification, every change request, test results, and the correspondence
- Give contractual notice properly and on time
- Mitigate, and record it — take over the code, engage another supplier, and keep evidence of the additional cost
Then decide whether the claim is worth its cost. Software disputes are document-heavy and expert-driven; a commercial settlement is frequently the better outcome, and it is easier to reach when your paperwork is in order.
Watch the deadlines. See limitation and the deadlines that end claims and recovering money owed.
How the firm can help
We draft and negotiate development agreements, master services agreements, SaaS and licence terms and data processing addenda, for suppliers and customers, and we act in failed-project disputes — recovery of unpaid fees, defective delivery claims, IP ownership arguments and terminations.
See corporate and commercial, or contact the firm.