Arabic Web Development Contract: Every Clause Explained

Almost every client-developer dispute I have seen started with a missing clause, not with bad faith. I am Khaled Ahmed, a freelance Full Stack developer in Cairo. Across 5+ years and 39+ shipped production projects in eight countries, I have signed contracts with individuals, agencies and large organisations. This article gives you the full clause set for a web development contract, written out in usable language, with what each clause actually protects and what happens when it is missing.

1. The verdict first: a contract is an exit map, not a trust ritual

Most clients treat the contract as paperwork that happens before the real work. That is an expensive misunderstanding. A good contract is not read on signing day. It is read on the day something goes wrong: the delivery slips, the client asks for something outside scope, the developer vanishes after milestone two, or an account closes and the entire chat history goes with it.

The rule I work by: every clause must answer the question "what happens if this goes wrong?" If a clause has no answer to that question, it is filler. If a realistic failure has no clause covering it, your contract is incomplete no matter how many pages it runs to.

Three failures I see repeatedly in the Egyptian and Gulf market, and they are the same three in the UK and EU:

• Agreeing to "a website" with no written specification. That word covers a landing page and a multi-tenant platform, and the gap between the two is at least tenfold in cost. Missing detail is the root of most of the disputes clients have described to me.
• Paying 100% up front or 100% on delivery. The first kills the incentive to finish. The second makes the developer work without security, so they slow down or hold the code hostage.
• Never naming the code owner. That single clause deserves its own read: who actually owns your website code after handover.

2. What clauses must a web development contract contain?

These are the fourteen clauses I will not sign without, and the real-world consequence of each omission. The right-hand column is the price of skipping it.

3. Clauses one and two: parties and scope

Identifying the parties

Name who is contracting with whom, precisely. For a freelancer: full legal name, national ID or passport number, address, email, phone. For a company: trading name, commercial registration number, tax number, and the name and title of the signing representative. Ask for a copy of the document and check the name matches the bank account that will receive the money. That single check is the cheapest fraud screen available to you.

One detail that is almost always skipped: make the email addresses in the contract the formal notice channel. Add: "Notice sent to the email addresses stated above constitutes valid service. Each party must notify the other in writing of any change within three days." That sentence saves you the fight over whether a warning was ever delivered.

Scope: the annex is the real contract

Keep the scope clause in the body short and point it at an annex. The annex is the specification, and it is what settles every later disagreement. Do not accept "a professional responsive website". That is marketing copy, not a specification.

1. A numbered list of pages or screens, with the sections inside each one.
2. Functions written as user stories: "a registered user can upload a PDF up to 10 MB and delete it within 24 hours."
3. The admin panel and exactly what the client can edit alone. This is the single most misread item in the market: the client assumes everything, the developer assumes text only.
4. Languages, who supplies translation, who supplies copy and images, and whether RTL support covers the admin panel as well as the front end.
5. Named third-party integrations: payment gateway, shipping, invoicing, SMS, and who pays the account and transaction fees.
6. An explicit out-of-scope list. This is the most valuable list in the document. For example: "This contract does not include copywriting, product photography, paid ad campaigns, a mobile app, ongoing SEO after handover, or paid licences for third-party tools."

If you are building a store, pull the function list out of my ecommerce development guide before you write the annex. It will stop you forgetting inventory, returns and discount codes, which are the three that always arrive late and unpriced.

4. Who owns the code after delivery?

Short answer: by default the developer holds copyright in the code they wrote, unless the contract transfers the rights in writing. Copyright law in Egypt and the Gulf treats software as a protected work, and paying an invoice does not automatically transfer ownership without an express clause. The detail differs by jurisdiction and can change, so have a local lawyer confirm the wording on a large engagement.

Three deliberate details in that wording:

• "upon payment of the full contract value" protects the developer. Any contract transferring ownership at signature will be refused by a serious developer, because it removes their last leverage to get paid.
• "produced specifically for this project" is realistic. Developers reuse internal libraries and components across clients and cannot assign those to you. Cover it with a sub-clause: "The Second Party grants the First Party a perpetual, irrevocable, non-exclusive, royalty-free licence to use any pre-existing components embedded in the project, including the right to modify them for this project."
• "as such" keeps the non-resale promise fair. Do not demand that the developer never builds anything similar again — that is unenforceable in practice and blocks them from working. Demand only that they do not resell your build.

Do not drop the "worldwide and for the full term" wording. Egyptian copyright law expects a written assignment to name each transferred right expressly and to state its scope, purpose, duration and territory of exploitation. Several Gulf statutes are drafted the same way. A clause that lists the rights but leaves duration and territory blank can end up narrower than either party intended, which is exactly the ambiguity you signed a contract to avoid. Name the rights, then name where and for how long.

Add a portfolio clause: "The Second Party may display the project in their portfolio after public launch unless notified otherwise in writing." Most serious developers need this, and removing it without reason usually raises the price, because you are taking away marketing value.

5. How do I split payments across milestones?

The rule: every payment must attach to a reviewable deliverable, never to elapsed time. "Second payment after one month" is bad drafting. "Second payment on approval of the UI designs for all screens" is good drafting, because it is provable.

Practical notes on that table:

• Never go below a 20% deposit. Anyone accepting 5% up front is either desperate or planning to drop you for a better offer.
• Treat a third as the sensible ceiling and 40% as the absolute limit, not the target. Past that point you are financing the developer's cash flow rather than buying delivered work.
• Hold 10-15% against final handover. That retention is what gets the last ten small bugs closed instead of the developer drifting away once the site "basically works".
• Put a payment deadline on yourself too: "The First Party shall pay within five working days of notification that a milestone is met, failing which the timeline extends by the period of delay." Late client payment stalls more projects than slow developers do.
• State the currency, who absorbs transfer fees, and whether the figure is VAT-inclusive. Ambiguity here costs 5-15% of contract value in a later argument.

To sanity-check the total before you negotiate, read how much a website costs in 2026 or look at my published packages to see what each price band actually buys.

Escrow, bank transfer, or platform?

6. Timeline, delay and liquidated damages

The delay clause is where most contracts turn one-sided, which is self-defeating: good developers refuse it and weak ones sign it, so you end up with a strong clause and a weak builder. Make it symmetrical.

That last sentence is what makes the clause signable. In my experience more than half of all delays trace back to waiting on client content or approval, not to slow development. Add a response deadline too: "The First Party shall respond to approval requests within three working days; failure to respond after two written reminders constitutes acceptance of that milestone."

7. Change requests: the clause that saves the project

Scope creep is the silent killer. It starts with "just add a share button" and ends at double the budget and double the timeline. The fix is not refusal, it is immediate transparent pricing.

Fix the hourly rate inside the contract. Without it, every small request becomes a fresh negotiation. Typical professional freelance rates as of 2026 run roughly 300-1,500 EGP per hour in Egypt, 80-250 SAR per hour in the Gulf, and USD 40-90 per hour for experienced remote developers serving UK and EU clients — with wide variation by specialism, and with senior specialists on complex platform work sitting above the top of each band. Also grant a small, defined free allowance, such as two design revision rounds and ten hours of in-build tweaks, so the relationship is not invoiced to death.

8. Acceptance criteria: defining the word "done"

"The site is ready" has no enforceable meaning. Define it. I put an objective checklist in every contract that a neutral third party could verify:

Final acceptance criteria
1. All functions in Annex 1 work in production without HTTP 500 errors.
2. No Critical or High severity issues open in the final test report.
3. Works on the two latest versions of Chrome, Safari, Firefox and Edge.
4. Responsive layout intact at 360px, 768px and 1440px widths.
5. Lighthouse mobile performance score of at least 70 on key pages.
6. SSL installed and HTTP redirected to HTTPS.
7. Daily automated off-server backups of database and files enabled.
8. Credentials handed over for every account listed in Annex 2.

Item five prevents the most common post-launch argument, but do not set an impossible threshold on a video-heavy site. Understand what actually moves that number first — why your website loads slowly explains the levers — then set the bar.

Keep two numbers separate in your head: the contractual floor and the target. Seventy is the generic minimum I would accept as an enforceable, provable threshold in a contract with an unknown counterparty, because it is achievable on almost any content-heavy build and nobody can argue about the measurement. It is not what I aim for — my own packages commit to Lighthouse 95+, because that is the standard I build to. Write the floor you are genuinely willing to enforce into the contract, then agree the target you actually want in the specification annex. Setting the contractual number at your dream figure just gives you a clause you will never invoke.

Add an inspection window: "The First Party shall submit comments within seven working days of delivery notice, failing which the project is deemed accepted." That protects the developer from a client who disappears for two months and returns with a new list, and it protects you by guaranteeing a real review period.

9. Warranty and maintenance are not the same thing

• Warranty is free repair of a defect in delivered work. Thirty to ninety days from acceptance is normal, and the length usually scales with the size of the engagement. Wording: "The Second Party shall fix any defect in the delivered functionality free of charge for ______ days from acceptance. The warranty excludes faults caused by modifications made by the First Party or a third party, by changes in external services, by hosting issues, or by new requirements."
• Maintenance is a separate paid agreement: security patching, dependency updates, backups, monitoring and a monthly block of development hours. Typical annual spend runs 5-15% of the original build cost, driven mostly by the response time you need rather than by code size.

If the site is commercial, put response times in writing: four working hours for critical outages affecting the site or payments, 48 hours for normal issues. And treat patching as contractual, not optional — turn my website security checklist into named line items in the maintenance agreement.

10. Handover: the asset list you actually own

I have met clients with a successful site who could not change a line of it, because everything was registered in the developer's name. Make Annex 2 a literal asset list, signed on handover:

1. Domain registered in the client's name and email, not the developer's.
2. Hosting or server account with full credentials.
3. Complete GitHub or GitLab repository transferred to the client's account, with commit history intact.
4. Final SQL dump and schema documentation.
5. .env.example and a list of every required environment variable.
6. Keys for every third-party service: payments, email, SMS, maps, cloud storage.
7. Source design files in Figma or equivalent, with edit rights.
8. Google Analytics and Search Console with owner-level access for the client.
9. A short runbook: how to deploy, how to restore a backup.
10. A signed handover record, dated, describing what was delivered.

11. Do I need an NDA?

An honest answer that will not please everyone: for most brochure sites and stores, a separate NDA is unnecessary and a strong confidentiality clause inside the contract is enough. The idea alone is rarely the secret; execution is. Clients who demand an NDA before describing the project usually lose a week signing a document that protects nothing.

A separate NDA genuinely earns its place in four cases: you are handing over real customer, financial or health records before contracting; the product is a SaaS platform whose pricing logic or algorithm is the competitive advantage, as with the tenancy models in multi-tenant SaaS with Laravel; your organisation's policy requires one; or the work involves access to a live system holding real user data.

That deletion sentence matters more than it looks. Database dumps sit on developer laptops for years, and that is one of the most common and least discussed sources of customer data leaking.

12. What if the developer disappears before delivery?

This is the question I am asked most, and almost everyone asking it omitted the clause that would have solved it. The solution starts before the disappearance, not after.

Prevention: three clauses that make vanishing pointless

1. Weekly pushes: "The Second Party shall push code weekly to a Git repository owned and administered by the First Party, who grants the Second Party push access for the duration of the project and retains full administrative control throughout." This one clause turns a disaster into an inconvenience, because you always hold the latest working build and any other developer can continue from it.
2. Client-owned environments: hosting and staging live on your account, not on the developer's personal server.
3. Pay against reviewable deliverables, per the milestone table above, so your money never runs ahead of the work.

Cure: the termination-for-default clause

That final sentence is decisive. Without it you can end up holding half a project you have no legal right to hand to anyone else, having already paid half the budget.

If it has already happened and there is no contract

• Document everything now: chats, transfer receipts, links, agreed dates, with timestamped screenshots.
• If you hired through a freelance platform, open a dispute there first — escrow systems handle this case well and can freeze held funds.
• Send a formal written demand to the registered email and phone with a clear deadline and a specific demand: deliver the code or refund.
• Price the loss honestly before litigating. Chasing USD 600 through a court in another country will cost more than the sum and months of your attention.
• Start technical recovery immediately: pull the latest copy from hosting, assess what is salvageable, then pick the replacement carefully using how to hire a web developer.

13. Governing law and dispute resolution

When the client is in Riyadh or Dubai and the developer is in Cairo, do not leave this blank. Fix three things: governing law, the forum, and the controlling language.

Three practical notes. On small cross-border projects, international arbitration costs more than the project is worth, so rely on escrow and a tight milestone structure instead. If the contract is bilingual, name one controlling version or the translation gap becomes its own dispute. And ask yourself honestly whether you would ever travel to enforce a judgment — if the answer is no, your real protection is the payment structure and asset ownership, not the dispute clause.

14. The full contract structure, as a final checklist

Here is the complete running order, section by section, as a recap checklist. The clause language itself is in sections 3 to 13 above, where each piece is explained before you use it; run down this list to confirm nothing is missing from your document before you sign. There is deliberately no download, because a contract you have not read does not protect you.

1. Preamble and parties, capacity, and email as the notice channel.
2. Subject: "design, development and delivery of a website per the specification in Annex 1, signed by both parties and forming an integral part of this Agreement."
3. Technical specification: framework and version, database, hosting environment, supported languages, performance thresholds.
4. Term and timeline, including clock suspension for client delay.
5. Fee and payment schedule, in figures and words, with currency, transfer fees and tax treatment.
6. Client obligations: content, images, accounts, responses within stated windows.
7. Developer obligations: professional standards, weekly code pushes, blockers reported within 48 hours.
8. Change requests: request, estimate, approval, hourly rate.
9. Acceptance criteria and the inspection window.
10. Intellectual property: transfer on full payment, territory and term of the assignment, licence for pre-existing components, portfolio rights.
11. Confidentiality and data protection, with survival period and deletion duty.
12. Warranty: duration, scope, exclusions.
13. Termination: by agreement and for default, with the effect of each on payments and ownership.
14. Force majeure, defined realistically to include major cloud outages and national internet disruption.
15. Governing law, dispute resolution, controlling language.
16. Annexes: (1) specification, (2) asset and account list, (3) payment schedule, (4) change request form.

15. Common mistakes

• A three-line agreement over WhatsApp. Messages may serve as evidence, but they do not substitute for a specification and they never settle ownership.
• Reusing a construction contract and swapping "building" for "website". I have literally seen this. Acceptance logic in software is nothing like acceptance on a build site.
• A one-sided delay penalty. You pay for it either in the price or in the calibre of whoever agrees to sign.
• Silence on tax. State whether the fee is VAT-inclusive, particularly with companies in Saudi Arabia and the UAE.
• No allocation of third-party fees. Hosting, domain, payment gateway and SMS are recurring client costs; write them down with estimates.
• No asset annex. See section ten — this is what clients regret a year after launch.
• Choosing the counterparty without verification. A contract limits damage; it does not create a good developer. The tradeoffs are laid out in freelance developer vs agency.

16. How I contract

For transparency, my own process: a free diagnostic call, then a fixed-fee proposal built on a written specification, then a six-to-ten page contract using the clauses above, milestone-linked payments, a Git repository in the client's name from day one, full ownership on final payment, and a warranty of 30, 60 or 90 days depending on the package tier. I do not start before signature, even with repeat clients — not out of distrust, but because the written document removes weeks of later argument and protects both sides equally.

If you have a contract in front of you and want a blunt second opinion, or you want a fixed-fee quote for your build, reach me through the contact page. The first consultation is free and I reply within 24 hours with a clear scope and price, no obligation.