Working with remote freelance developers is becoming a common thing for many businesses. The fast-paced and more efficient workflow provided by outsourcing entire development projects, or parts of them, usually outgrow the learning curve required with this new approach to working.

On a purely business perspective, geographical borders are often a limit to growth and efficacy. Because of this peculiar feature of working with freelance developers, often projects happen between subjects living in different countries or even continents.

The biggest issue that arises in this regard is that you and the developer you have outsourced to are most probably located in different time zones. This can be an incredible inconvenience to both sides and cause hassles that result in a loss of productivity and effectiveness.

So what do you need to know about time zones to make the best out of them for your WordPress projects?

Pros of working with a developer in a different time zone than yours

Let's start with a real-world scenario: you have a new your project that needs to be addressed now, and you're in need of the best candidate to take care of it.

It might be the case that in your local area there are no WooCommerce experts, or performance specialists, or security professionals available you could reach out to.

What do you do, then? You look for a freelance developer.

Since your goal is to move things forward, your research for the perfect candidate shouldn't be limited to your local area or personal network. Therefore, where your outsourced developer will be based shouldn't matter that much either.

That's just one of the pros of working with remote professionals. On top of that, if you work with freelance developers in different time zones, you'll also benefit from having an ongoing flow of work that you could hardly recreate with someone in your own time zone.

Think of companies with 24/7 support or those with a continuous development cycle where you send requests by the end of your day and the developer picks it up in their morning (when you're about to call it a day). We'll see more of this in a second.

The third and great benefit of working with someone located in a different country, and likely a different time zone, is the cultural freshness they bring in. A different culture often means a different perspective on life and, more often than not, on job-related aspects.

That sounds awesome!

To sum up, here's the list of pros of working with a developer in a different time zone than yours:

  1. No geographical limits to hiring the best candidates and specialists
  2. Uninterrupted project development
  3. New ideas and fresh perspectives from a different culture

Unfortunately, when working with freelance developers, there are some cons as well you'll need to be aware of. Fear not – you can overcome all of them with good communication skills (which is something you can start improving today)!

Cons of working with a developer in a different time zone than yours

Working with a professional not only outside your office but also in a different time zone than the one you're currently in, can be challenging for some business owners.

Why that? The main reason is, even though you always knew communication is important in your work, you had never had the chance to actually test how that assumption happens to be true. In fact, working with developers and any other professionals in a different time zone brings up all implications of remote work plus asynchronous communications and flows of work.


Working with developers in a different time zone than yours requires communication and organizational skills from your part. If you lack them, your project could get delayed, your developer might deliver something different from what you have in mind, and so on.

To sum up, here's the list of cons of working with a developer in a different time zone than yours:

  1. if you suck at communication, you're delaying your project (+ meetings will be hard)
  2. if there's no good planning, working will be hard and poor
  3. there's going to be little to none constant collaboration

How to find out your developer's time zone

Let's start by clearing the air around where you developer's currently based. You can simply do that by picking a developer's location and put it on one of the many free tools. The one I use is called World Time Buddy (WTB):

World Time Buddy

Just add your city and your developer's in the top-left search box, and you'll get to see how your time zones overlap. That's the very first step when considering to hire a remote (WordPress) developer.

Now, here's where the game gets funnier...

How to decide on a developer's time zone: behind vs ahead vs your local time

It is important to give ample considerations to choosing developers from the best suited time zones.

The first choice you might think about should be someone within your own GMT. But that's your best choice only at certain times; it is possible that you find a more interesting opportunity elsewhere. In such cases, it is imperative to give time zones, and their difference, a considerable thought.

As WordPress developer and Codeable expert Jonathan Bossenger highlights here:

When you are working across different time zones, it's really important that you understand what time zone you're in so that you understand the difference in the time delay.

Let's have a look at the three options you have:

  • Option a): the developer is ahead of your time zone
  • Option b): the developer is behind of your time zone
  • Option c): the developer is in your time zone

Option a) - Working with a developer ahead of your time zone

The favorable outcome that comes out of working across time zones is when you’re working with a developer who is six to eight hours ahead of you.

For example, if you're based in New York, US a developer based in Europe might be an ideal choice. This is because as they end their work day, you're only halfway through yours meaning that they can effectively send you updates on your projects and you can have an overlapping, working time zone to interact and work things out seamlessly.

Explains Jonathan:

I'm Cape Town, South Africa and all of my US-based clients are between six to eight hours behind me. That means at the end of my day I can send them an update, and I can send them some finished piece of functionality, and they can spend the other half of their day testing that functionality and sending me feedback. Then I can log on the next day and I can start working on that feedback, fixing bugs, making changes, and so on.

The great benefit here is the constant flow of work which almost never stops between the involved parties. Specifically, by working with a developer ahead of your time zone could help you set up a routine where your day starts with an update about the project already in your inbox to look at so that you have your day to review it and send feedback back to your developer right before they start their day.

Option b) - Working with a developer behind of your time zone

What if your best candidate developer lives hours behind your current time zone? Well, theoretically nothing major changes: if you need to have daily status updates on your project, your developer could send them when they end their end their workday so that you'll find them the next day in your inbox.

I should warn you, though, that working with someone behind of your current time zone requires additional planning to be done up front as you'll need to take into account all of the project details you can think of to prevent any delays.

It takes some training, but the benefits of working with developers in different time zones than yours have a greater impact than the annoyance of doing some more planning you're requested to do.

Wait so... does that mean hiring developers in your own time zone has little value? No, it does not!

Option c) - Working with a developer in your time zone: better suited for urgent work (but not exclusively)

Even though the quality and professionality of a developer should be the first aspects you hire them for, there's also another one that has to do with the time you have planned around your project deliverables.

In other words: urgency. As Jonathan comments:

The basis of the choice sometimes is the amount of time you have. That's why, if time is a concern, find someone in a similar time zone, especially if your work is urgent because it's easier to quickly send a message and, if there's any clarification needed, the response can happen within a few hours.

Urgency can be mitigated with a detailed project brief and a solid preparation in advance of all other additional information your developer will ask you to provide. Time-sensitive projects can also be managed with developers located in different time zones, it's a matter of how comfortable you are with an asynchronous workflow.

4 aspects to embrace to get the most out of a developer working in a different time zone than yours

The hardest part isn't working with someone in your same time zone, although some further communications and planning are required than in a common per-person working relationship.

When working with developers in different time zones, as most of the work happens in a non-linear way, you should always have the impression of over-communicating to convey your requests properly. This allows the process to be streamlined and executed in the most efficient manner.

There are some important factors you should keep top of mind in this regard. Let's see them!

1. Deeply understand that you're in different time zones


It is important that you understand the difference in time zones quite clearly. Be sure that you have your developer's respective working hours figured and have communicated yours to them as well.

This allows you to keep appropriate expectations of when you’ll be receiving updates and when you’ll have to respond to them. Jonathan highlights:

When working across time zones, it is important to be as detailed as possible with your communication because there is going to be a large chunk of time between communications, you can't simply waste time clarifying things.

If you miss doing so, there's going to be an enormous communication gap in certain situations along with expectations not being properly set up and managed. It is better to be as descriptive in the problems that you're having or the feature you want to build as possible, rather than wasting time with unclear requests or feedback that might be misunderstood.

2. Be considerate when planning meetings

Meeting, meeting, meeting

This is another vital aspect to consider when working with someone outside your time zone. Each individual is different in terms of their brain working capacities. There are certain individuals who are up and active at 7 am, while there are people who might wake up at 9 am but only feel fit to work only after noon.

Although this might not be the most common behavior, it is important for you to be aware of and consider it in your communication flow. Jonathan summarizes:

When you're booking meetings or calls with your developer, plan a meeting at a time that doesn't just fit your schedule, but also fits both your productivity level.

Either a developer who is tired after a long day at work or yourself won't be much help and, as a result, your project will suffer.

3. Have the term "End of the day" clearly defined


"End of the day" is a term that needs a proper definition for both sides because it will determine and clear a lot of expectations that exist among you and an outsourced developer. The term "end of the day" might be different for each individual, for instance, a developer might refer to end of the day when they go to sleep because they like to take work home and sort major problems that might occur from there.

This doesn't necessarily mean that they'll always be available and here an effective communication becomes a necessity from both sides. Jonathan points out:

In an outsourced environment, specifically for a freelance developer, "End of the day" is a variable thing. It doesn't always mean a specific time. That's why you need to define and agree on it up front.

4. Discuss project updates, feedback, responses up front with the developer

No matter what aspects and considerations are discussed, it all gravitates around defining and agreeing on a common communication and updates flow with your developer. Some examples are:

  • How frequently do you need project updates? Daily, hourly, weekly...
  • How can you reach out to the developer if an emergency occurs? Here you'll also need to define what an emergency is
  • How long should you wait before sending another request to the developer?
  • When will your developer be online? How does that relate to your workday?
  • (more...)

It is important that you ask the developer and clearly define what type of conversation you’re having with them and how quickly you expect them to respond. Similarly, you need to ask them what work they’re performing and what their availability is and how conveniently they might be able to send messages back to you.

Defining the parameters of communication and clearly sharing what your expectations are across time zones is crucial.

Wrapping up

Working effectively with outsourced developers who are situated in different time zones can be somewhat of a hassle depending on the respective time zone that they're in and your work schedule.

For urgent projects, your first choice should be better to hire someone in your same time zone to take advantage of a greater time span in which you and the developer are both working.

Nevertheless, working with freelance developers isn't a matter of where they're located, rather how a good fit they are for your project. By getting used to these fundamentals concepts, you'll start taking advantage of this efficient working paradigm, the only one empowered with an around-the-clock focus on what you care most about: your project outcomes.

This blog post features Jonathan Bossenger, a freelance web consultant, developer, writer and podcaster. He is a big supporter of open source software due to its ability to change the world around it. For the past 13 years, he has gathered expertise in all facets of the software development lifecycle, from devops to project management, and everything in between.