When a software project goes wrong, the argument is rarely about whether the developer can code. It is about expectations: what was included, who owns the result, whether a change is extra, when the project counts as finished, and what happens if either side wants out. A good contract answers those questions before anyone is upset.
This checklist is written for business owners hiring a software company or freelancer in Pakistan. It is practical guidance, not legal advice. For large contracts, have a lawyer review the final document.
1. Scope of work
The contract should reference a detailed scope document: features, user roles, platforms, integrations and what is explicitly excluded. “Build an ERP” is not a scope. A list of modules with their key functions is. Our software requirements checklist helps you prepare one, and how to write an RFP covers the bidding stage.
Check: Are exclusions written down? Common ones are data migration, content entry, hosting costs, third party licence fees and app store accounts.
2. Deliverables and milestones
Break the project into milestones, each with specific deliverables you can see and test: designs approved, module one working on a staging server, and so on. Avoid milestones like “50 percent development complete”, which nobody can verify.
3. Payment terms
Tie payments to accepted milestones, not to dates or effort. A typical structure has an advance, payments on milestone acceptance, and a final payment after launch and a short stabilisation period. Be cautious of contracts demanding most of the money upfront.
The pricing model matters too. See fixed price versus time and materials for which suits your project.
4. Change requests
Requirements always change. The contract should define how: you request a change in writing, the vendor estimates cost and time impact, you approve in writing before work starts. Without this, every change becomes a dispute about whether it was “in scope”.
5. Acceptance criteria and testing period
Define what “accepted” means for each milestone and how long you have to test, for example ten working days. State that bugs found must be fixed before acceptance, and what happens if you do not respond within the period, since deemed acceptance clauses are common.
6. Source code and intellectual property ownership
This is the clause businesses most often regret ignoring. Confirm:
- You own the custom code written for you, upon payment.
- Code is delivered to a repository you control, ideally continuously rather than only at the end.
- Any pre existing components or libraries the vendor reuses are licensed to you perpetually for your use.
- Third party and open source licences are listed.
If the vendor retains ownership, for example with a white label product, understand exactly what you can and cannot do. See white label software.
7. Confidentiality and data protection
The vendor will see your business data and possibly customer information. The contract should require confidentiality, limit data use to the project, require secure handling and deletion of data at the end. For apps handling personal data, see data protection for apps in Pakistan.
8. Warranty period
A reasonable contract includes a period after launch, often one to three months, during which bugs in delivered features are fixed at no extra cost. Distinguish bugs, where something does not work as specified, from new requests.
9. Support and maintenance
After warranty, what happens? Define support options, response times for critical issues, and costs, either as a monthly retainer or hourly rate. Our guide to software maintenance costs explains typical structures.
10. Handover and documentation
Require technical documentation, deployment instructions, credentials for every service, and a handover session. This protects you if the relationship ends. See what documentation you should get at handover.
11. Termination and exit
Either side should be able to end the contract with notice. On termination, you pay for accepted work plus work in progress on a defined basis, and you receive all code, designs and data produced so far. Without this, ending a failing project can leave you with nothing.
12. Dispute resolution and liability
Agree how disputes are handled: escalation between senior contacts first, then mediation or arbitration, and which jurisdiction applies. Check liability limits so neither side faces unlimited exposure, while the vendor remains accountable for serious negligence.
Red flags in a proposed contract
- No written scope or a one paragraph scope.
- The vendor owns the source code with no licence for you.
- Most of the payment due before any working software.
- No acceptance testing period.
- Hosting and domains registered in the vendor’s name only.
- No termination clause.
For warning signs that appear during the project itself, see software project warning signs.
Example clause language, in plain English
These simplified examples show what clear clauses look like. They are illustrations for discussion, not legal drafting. Have final contracts reviewed by a lawyer.
| Topic | Vague version to avoid | Clearer version |
|---|---|---|
| Scope | Developer will build the app as discussed | Developer will deliver the features listed in Annex A. Features not listed are out of scope and handled through change requests. |
| Acceptance | Client will approve work when satisfied | Client has ten working days to test each milestone against the acceptance criteria in Annex B and report defects in writing. |
| Ownership | Client owns the project | On payment of each milestone, the client owns all custom code, designs and documentation created for that milestone. |
| Change requests | Changes may cost extra | Changes are requested in writing. Developer provides a cost and time estimate within five working days. Work starts only after written approval. |
| Warranty | Developer will fix bugs | For sixty days after go live, developer fixes defects where delivered features do not meet the agreed specification, at no additional cost. |
| Termination | Either party may end the contract | Either party may terminate with thirty days written notice. Client pays for accepted milestones and documented work in progress, and receives all work product to date. |
Payment structures compared
| Structure | How it works | Suits | Risk to watch |
|---|---|---|---|
| Milestone based fixed price | Payments tied to accepted deliverables | Well defined projects | Scope disputes if requirements were vague |
| Monthly retainer | Fixed monthly fee for a team or hours | Ongoing product development | Unclear output without regular demos and reporting |
| Time and materials | Pay for hours actually worked | Evolving requirements | Budget overruns without caps and reporting |
| Hybrid | Fixed price discovery, then milestones or retainer | Complex projects with uncertainty | Needs clear transition between phases |
See fixed price versus time and materials for a deeper comparison.
International contracts
Pakistani businesses sometimes hire overseas developers, and Pakistani software companies often sign contracts with clients abroad. Extra points need attention:
- Governing law and jurisdiction: which country’s law applies and where disputes are resolved. Arbitration clauses are common for international work.
- Currency and exchange rate risk: which currency payments are made in, and who bears conversion costs.
- Payment methods and timelines that work reliably for international transfers.
- Tax and withholding obligations, confirmed with tax advisors in both countries where relevant.
- Data protection requirements from the client’s country, such as rules on personal data of European users.
- Time zone commitments for meetings, support and response times.
Negotiating without damaging the relationship
Many business owners hesitate to request contract changes, worrying it signals distrust. Experienced vendors expect negotiation and appreciate clarity. Helpful approaches include explaining the reason for each request, focusing on shared goals such as avoiding misunderstandings, prioritising the clauses that matter most, such as ownership, acceptance and exit, and being flexible on less critical points. A vendor who refuses reasonable protections like code ownership or a termination clause is revealing something important before the project starts.
Documents that should accompany the contract
- Scope and requirements document with features and exclusions.
- Milestone plan with deliverables, dates and payments.
- Acceptance criteria for each milestone.
- Technical assumptions: platforms, hosting, integrations, third party costs.
- Communication plan: meeting frequency, reporting, contacts on each side.
- Support and maintenance terms after warranty.
These annexes often matter more in day to day disputes than the main contract text. See software requirements document checklist.
Frequently asked questions
Is a contract necessary for a small project?
Even a short written agreement covering scope, payment, ownership and handover prevents most problems. It does not need to be long.
Should hosting be in our name?
Yes. Domains, hosting, app store accounts and third party services should be registered to your business, with the vendor given access.
Who writes the contract?
Vendors usually provide a draft. Read it against this checklist and request changes. Reputable vendors expect negotiation.
Should we sign an NDA before sharing our idea?
A simple non disclosure agreement before sharing detailed business information is reasonable. Most reputable software companies sign them routinely.
Who should own third party accounts created during the project?
Your company. Domains, hosting, app stores, payment gateways and analytics should be registered to you from the start, with vendor access granted.
The bottom line
A clear contract protects both sides and makes the project calmer. Focus on scope, milestone payments, change control, acceptance, code ownership, handover and exit terms.
Before you sign with anyone, read how to choose a software company in Pakistan or ask our team to walk you through how we structure scope and milestones.