Working with international clients from Pakistan: time zones, contracts and getting paid

Most of my clients are outside Pakistan, mainly in the UK, US and Gulf. I work from Islamabad. This is what I've found matters when you do that, and what I'd tell someone about to start.

Nothing here is tax or legal advice. I'm an engineer, and the rules on foreign income, banking and contracts are specific to you and change over time. Ask a qualified accountant and, for anything large, a lawyer.

Time zones

Pakistan Standard Time is UTC+5, and Pakistan doesn't currently observe daylight saving time. That detail matters more than it sounds. Your clients' clocks move twice a year and yours doesn't, so the overlap you agreed in March might be an hour different by November. Write meeting times in the client's zone and in yours, and recheck them when the clocks change.

The gap with the UK and the Gulf is small, so working hours overlap comfortably. The US is harder: late afternoon for me is morning for the US East Coast, and the West Coast is a stretch.

For distant clients I work asynchronously. That means:

• Write updates that stand alone. Someone should be able to read a message, understand where the project is and know what I need from them, without a call.
• Use short recorded videos. Five minutes of screen recording often replaces a 30-minute meeting and can be watched when the client is awake.
• Agree one overlap window. Pick a time when both of you are online and use it for the decisions that need talking.
• Ask questions in batches. Three questions at once beat three messages across three days.

The result is better than it sounds. A written update is also a record, and a record is useful when memories differ.

Contracts

I know people dislike paperwork. I dislike the alternative more: a disagreement six weeks in about what was promised.

A short contract is enough for most projects. The things I'd always write down:

Scope. What is being built, in plain words, and what isn't. "A booking form that emails the agency" is clearer than "a booking system."

Changes. What happens when the client wants something new. Without a rule, small requests pile up unpaid. Say that changes outside the scope are quoted separately.

Payment. The amount, the schedule, the currency, who pays any transfer fees and what happens if an invoice is late.

Ownership. Who owns the code and when. A common arrangement is that ownership passes on full payment. Say it either way.

Support. How long you fix defects for free, and what counts as a defect, as opposed to a new feature.

Ending the agreement. How either side can stop, and what happens to work already done.

Confidentiality. If the client wants an NDA, sign it before they send sensitive material.

I run client work through Codic Systems, a registered company, so contracts are with a company and not with an individual. Whether that suits your situation depends on you.

Getting paid

Getting paid from abroad is a practical problem, and the options differ by country and change often. I'm not going to name fees or products as though they're settled. Check what your bank, the client's bank and any payment platform currently allow before you agree a method.

What I'd do regardless of the method:

• Take a deposit before starting. It filters out people who aren't serious and covers your first stretch of work.
• Split the rest into milestones. Tie them to things the client can see, such as a design signed off or a staging site live.
• Tie the final handover to the final payment. Hold back the last piece, such as production access, until the final invoice is paid.
• Invoice promptly and clearly. A good invoice states what it's for, the amount, the due date and how to pay.
• Keep a written trail. Agree changes by email, not in a call that nobody wrote down.
• Ask early who pays transfer costs. Otherwise the amount that lands is not the amount you invoiced.

If a client goes quiet after delivery, a polite reminder with the invoice attached works more often than you'd expect. Most late payments are forgetfulness, not bad faith.

Trust and communication

Clients don't mind where you live. They mind whether you answer messages, do what you said and tell them early when something is going wrong.

Bad news doesn't improve with age. If a deadline is going to slip, I say so as soon as I know, with a new date and a reason. Clients nearly always handle that better than silence.

Language and tone

I work in English and Urdu, and most client communication is in English. I write plainly and avoid idiom, since the reader may be using a second language too. Short sentences, one point per paragraph and a clear request at the end.

When something goes wrong

Projects hit problems. A client changes direction, a deadline moves, or an invoice is disputed. The contract is what you both turn to, and it works best when you wrote it while you were still getting along. Keep the tone calm, point back to what was agreed and offer a way forward. Most disagreements are about unclear scope, and clear scope is cheap to write down at the start.

What I'd say to someone starting out

1. Understand the time-zone gap, and remember that only the other side changes its clocks.
2. Write down the scope, the changes process and the payment schedule.
3. Take a deposit, use milestones and hold back the final handover.
4. Check the current payment options before you quote.
5. Get proper tax advice from someone qualified.
6. Tell clients the bad news early.

None of it is difficult. It's mostly the habit of writing things down before you need them.