What should you ask before hiring an offshore web developer?

Before hiring an offshore web developer, check five things: that their past work is real and theirs, that your working hours overlap enough for regular live conversations, that you will own the code and every account from day one, that the contract covers IP, payment and handover in writing, and that you'll see working progress every week. Get those right and distance stops being a risk. Most offshore projects that go wrong fail on one of these five, not on the quality of the code.

This guide is the checklist I'd want a client to use on me. It works whether you're hiring a freelancer, a small studio or a larger agency, and in any country.

What "offshore" really changes

Hiring a developer in another country changes three things compared with hiring locally: you'll rarely meet in person, your working hours only partly overlap, and the contract may cross legal systems. Everything else, such as skill, reliability and communication, matters exactly as much as it would with someone down the road.

An analogy: it's like renovating a house you don't live in. The builder may be excellent, but you can't drop by to see the walls going up. So you agree in advance how you'll see progress, who holds the keys, and what happens if you part ways halfway through.

Why it costs you money

The cost of a bad offshore hire is rarely the hourly rate. It's what comes after:

• Lost time. Weeks pass before you realise the work isn't progressing, because you never saw it running.
• Lock-in. The code lives in the developer's account, the domain is registered in their name, and the hosting is on their card. When the relationship ends, you have to negotiate to get your own business back.
• Rebuilds. A new developer inherits code nobody documented and quotes for starting again.

Every one of these is preventable with questions asked before you sign, which is what the rest of this guide is for.

The checklist

1. Verify past work

A portfolio of screenshots proves very little. Ask for things you can check:

• Live links to sites or apps they built, which you can open and use yourself.
• What exactly they did on each one. "I built the front end; another team did the back end" is an honest, useful answer. "We did everything" for a large brand deserves a follow-up question.
• A reference you can contact: a past client willing to take a short call or answer an email.
• A code sample or public repository, if you have someone technical who can look at it. Even without one, a developer comfortable sharing code is a good sign.
• A quick check of the live work. Run one of their sites through PageSpeed Insights on mobile. You don't need to understand every number; you're checking that they take quality seriously on work they're proud of. My guide on Core Web Vitals explains what to look at.

2. Communication and time-zone overlap

Vietnam is on UTC+7 all year round, with no daylight saving time. Here's roughly what that means in practice:

• Singapore and much of Southeast Asia: almost the same working day.
• Australia: the east coast is three to four hours ahead of Vietnam (Perth just one), so most of the working day is shared.
• UK and Europe: Vietnamese afternoons overlap with European mornings, which is enough for a daily or weekly call.
• US East and West Coast: normal office hours barely overlap, if at all, so one side takes an early-morning or evening call. This works well when it's scheduled and predictable.

The point isn't to work the same hours. It's to agree a regular slot for live conversation, and to rely on written updates the rest of the time. Asynchronous (written, not real-time) work across time zones can actually be productive: you send feedback at the end of your day and wake up to it being done.

Ask about communication itself, too:

• Which channels they use (email, Slack, a project board) and how quickly they typically reply.
• Whether they put decisions in writing after a call.
• How comfortable they are with written English, which matters more than spoken English in day-to-day async work.

3. Code ownership and repository access from day one

This is the single most important item on the list. You should own every account, and the developer should be invited into them, not the other way round. From the first day:

• The code repository (GitHub, GitLab or Bitbucket) is in your organisation's account, with the developer added as a collaborator. Commits land there daily, not in one big upload at the end.
• The domain is registered in your name, with your login.
• Hosting, analytics, email and payment providers are on accounts you own and pay for. The developer gets access, which you can remove.
• Passwords and API keys (the secret codes that connect your site to other services) are stored in a place you control, such as a password manager.

Ask: "Can you set the project up in accounts I own, and invite you in?" A professional will say yes without hesitation. This also makes everything that follows, including the handover, much easier.

4. Contracts and intellectual property

A cross-border contract doesn't need to be long, but it should be written down and say clearly:

• IP assignment: that copyright in the work transfers to you, typically on payment. Without this clause, ownership can be unclear, especially across jurisdictions.
• Third-party and open-source components: that any libraries used are properly licensed for commercial use, and listed.
• Confidentiality: if you're sharing business details, an NDA or a confidentiality clause.
• Scope, change process and termination: what's included, how changes are approved, and what happens to work in progress if either side ends the contract.
• Governing law: which country's law applies if there's a dispute.

For anything significant, have your own lawyer look over the IP and termination clauses. A good developer will welcome that. If you're also deciding how to structure the price, my guide on fixed price vs time-and-materials covers the trade-offs.

5. Invoicing and payment

• Currency and method: agree which currency you'll be invoiced in and how you'll pay (bank transfer or an international payment service), and who covers transfer fees.
• Milestones over lump sums: pay against visible, accepted milestones, not large amounts far ahead of the work.
• Proper invoices: each invoice should name the project, the period or milestone, and the work it covers, so your accountant can file it.
• For time-and-materials work: a timesheet or task breakdown with every invoice, and a monthly cap you've agreed in advance.

6. Weekly demos

Insist on seeing working software, not status reports. A short weekly demo, live or as a recorded screen walkthrough, of what changed that week is the single best early-warning system you have.

Better still, ask for a staging site: a private copy of your website where new work appears as it's built, so you can click through it yourself whenever you like. If a week passes with nothing new to see, you'll know immediately, not at the deadline.

7. Handover

Plan the end on day one. At handover you should receive:

• Admin access to everything (most of which you'll already have, if you followed step 3).
• Documentation: how to run the project, how to deploy changes, and where the important settings live.
• A list of every third-party service the site depends on, with what each one costs.
• A short walkthrough call, recorded, so a future developer can pick up where this one left off.
• A clear warranty period for fixing bugs, and the terms for ongoing support or maintenance after that.

Red flags

None of these is proof of bad faith on its own, but each deserves a direct question:

• They want to host the code or register the domain in their own account "to keep things simple".
• They can't share live links or a reference you can contact.
• The quote is one line, with no list of deliverables or exclusions.
• They ask for most of the money up front, before any work is visible.
• They say yes to everything instantly, including every deadline and every feature, without asking a single question about your business.
• Updates are always "almost done", but there's never anything to click on.
• They avoid putting decisions or changes in writing.

Questions to ask, in one place

• "Can you show me two or three live projects and tell me exactly what you built on each?"
• "Could I speak to a past client?"
• "What's our regular overlap for a live call, and how quickly do you reply in writing?"
• "Will you set up the repository, domain and hosting in my accounts, and work in them from day one?"
• "Does the contract assign the IP to me on payment, and which law governs it?"
• "How will I see progress each week? Will there be a staging site?"
• "What exactly will I receive at handover?"

Next step

In short: distance isn't the risk; unclear ownership, invisible progress and unwritten agreements are. Ask these questions before you sign, and an offshore developer can be as dependable as one down the road, often with the bonus of work moving forward while you sleep.

I'm a senior web developer based in Vietnam, working with businesses abroad, and I'm happy to answer every question on this list about how I work. You can see past projects, read more about me, or get in touch to talk through your project.