I was recently talking to a prospective client who wanted to know whether a software developer being local, meaning their office is in close physical proximity to yours, is important.
I’ve heard this question countless times, so I know they aren’t the only ones who are curious about this. With the rise of overseas dev shops, and the increased number of independent developers working remotely around the country, it has become easier than ever to seek out a provider online and hire them without ever meeting in person.
And often, that’s perfectly ok! Especially in this era of social distancing, being physically close to your software engineers is less relevant. However, there are many instances where hiring a local developer can make your project go more smoothly and eliminate a lot of headaches.
Here are just a few factors to consider.
Why hire local?
- Communication will be easier. I’m not just talking about language barriers, although those are a real consideration when hiring an overseas developer. There’s often a regional or local shorthand we all use to communicate. You might reference the work of a company who’s the biggest game in town where you live, but your dev shop across the country has never heard of them. There’s more explaining and more context to be built with a non-local team.
- Communication will be more efficient. It is likely a local developer will share a common set of values or beliefs with you. This will allow you to get more value for less time spent communicating. You are also less likely to have to spell out every single detail to the developer because they intuitively know what your requests mean.
- You can communicate face-to-face. This factor is less relevant in the midst of a global pandemic where we’re all staying at home, but under normal circumstances, in-person communications can prevent a world of problems down the road. Investing in just one in-person meeting to kick off a project helps both teams to establish a communication shorthand that will save you tons of time later on.
What if budget or other constraints don’t allow you to hire local? Choosing a non-local developer is absolutely fine. There are some additional factors you should consider to keep your project on track.
Here’s how I recommend successfully navigating work with a non-local developer.
- Make sure there is a strong project management system in place. Establish frequent communications and a schedule for meetings before you start working together. Use technology to keep your project on track (at Shrine, we use Basecamp for project management). Since you won’t be meeting in-person on a regular basis, working with a dev team who already has a solid project management system will help you stay better informed and will prevent your project from going off the rails.
- Meet face-to-face at the beginning of the project if possible. You’re probably not going to fly to Bangalore or Kyiv to meet with your dev team, but you could easily make the trek to Seattle or Chicago or Dallas, or really any major U.S. city (assuming there’s no global pandemic preventing you from traveling). Meeting with your provider in-person will help get everyone on the same page in a way that emails, phone calls, and even video chats can’t accomplish.
- Over-communicate. Do not assume the developer understands your market or your customers (and by extension, your company culture). Over explain in the beginning, and be candid and thorough in your feedback throughout the development process. Ask your developer to explain what they’re hearing back to you in their own words, to make sure you’re communicating your ideas properly. Don’t be afraid to check ‘common-sense’ assumptions.
Using the strategies above, it is entirely possible to build a complete startup team using a remote agency or freelancer. We have done it dozens of times for clients in locations ranging from Bermuda to San Francisco to Detroit. If you’d like us to help you build a remote development team, drop us a line, and be sure to check out our post on 5 questions to ask before building an app.
