6 Important Questions to Ask Before Hiring an Offshore Software Development Company

6 Important Questions to Ask Before Hiring an Offshore Software Development Company

Are you thinking about hiring an offshore software development company to work on your startup idea? Let’s be honest – for many startups, this can be the difference between getting something built or not.

It sounds good, right? But before you go ahead and pull the trigger – there’s something important you need to know:

Not all projects can be outsourced effectively.

Luckily, such projects are rare, and even if your project has some elements that can’t be outsourced, chances are you can still outsource a major part of it. The key is to do the necessary prep work that will maximize your chances of success.

So, is outsourcing your development right for you and your startup? Here’s six critical questions to help you decide.

1) Do you have a technical friend or a mentor who can give you initial guidance?

In order to hire a good outsourced team or freelancer, you need to answer 2 important technical questions: “what technology should we use?” and “is your team good at that technology?” But how do you answer them if you’re not a technical person?

The solution is to find a technical mentor.

A technical mentor is a credible technology expert who can spend a couple of hours per week with you during the initial stage of your startup. It can be your friend, a co-worker or somebody you met at a meetup. As Ian Crosby of Bench.co points out, it is important to validate this person’s expertise. A recent CS grad or somebody who does coding as a hobby is probably not the best choice. On the other hand, somebody who recently built some software similar to yours, or someone who works at a top tech-based company (e.g. Facebook or Google) is a good candidate.

Your mentor will help you navigate this process, choose the right technology stack, do code reviews and potentially interview candidates. It doesn’t have to be a full-time CTO – meeting for a beer once a week during the initial stage should be enough. You can even offer to pay for their time if they are unable/unwilling to do it for free – believe me, it’s worth it.

Need some help on finding a solid technical mentor? Check out how these 3 tech CEOs found theirs.


Outsourced Developer - Find a Technical Mentor

It’s important to find a technical mentor

2) Are you comfortable with documenting every major function of your app?

Outsourcing works best for well-defined projects. Writing specification is one of the most important steps before you hire developers and can save (or waste, if done poorly) thousands of dollars. Documenting each function helps you and your developers stay on the same page and reduces time-consuming (and potentially expensive) back and forth.

First, make sure you’re familiar with the Lean Startup principles, especially the MVP. Start by narrowing down high-level functions(features) that are absolutely required in the first version of your app. At this stage, think of your product simply as an excuse to start conversations with your future customers.

don’t overbuild, you can always improve things later.

Describe each feature in detail, as if you’re talking to somebody who has no idea about the problem your application solves. The level of detail required for your specifications to work well might not be something you are used to, so check this video for an example on how to write a good specification.

Once you have a good description of all major functions of your app it’s a good idea to create wireframes(mockups/sketches). They will help your designer and developers better understand your vision in terms of how the app should work. Think of how to break down all functions into screens. Use other popular apps for inspiration – don’t re-invent the wheel. Create a sketch of every screen. Describe what happens when a user clicks a button/link, makes a selection, etc. You can give examples: “Make the animation of this popup like on xyz.com or in ABC app”.

This can either be done on paper by hand, or using wireframing tools like balsamiq.com or moqups.com. You could also hire a UX designer or agency (don’t confuse this with Web design) to do this for you. However, I recommend doing at least high-level mockups yourself – it’s a valuable exercise to help you better define your vision of the product. Check these examples for inspiration.

Do at least high level mockups yourself - hiring an offshore development company

At the very least, do the high level mockups yourself

3) Are you ready to provide designs for the developers?

A common mistake people make is assuming that developers should be able to do the visual design of their app. It’s like asking a plumber to do interior design. There are talented developers who also are talented designers, but they are extremely rare.

Don’t make developers design your app, unless you want it to look like this.

After you have wireframes created, a good option is to post a project on 99designs.com or designcrowd.com to have multiple designers compete for the design of your application. Another option is to browse dribbble.com or behance.net and contact great designers directly. In both cases, send them the wireframes so that they can understand the layout of the screens.

Alternatively, if your app is a web SaaS, buy an admin template on wrapbootstrap.com or bootstrapbay.com. An admin template is a collection of professionally designed common web app elements: menus, buttons, forms, tables, icons, etc. It allows you to not only skip the visual design phase, but also saves your developers time coding those individual elements. You can think of an admin template like a constructor for the front panel of a microwave: you still have to build the microwave and wire it to the panel, but at least you get nicely designed buttons and a shiny display.


Wireframe to design - Hiring an offshore development company

Are you ready to provide your developers with designs?

4) Are you comfortable with using online chat and email to communicate with your developers during a limited time window each day?

Depending on where you live your developers’ time zone can range from 4 to 12 hours behind or ahead of yours. This requires some getting used to. Fortunately, there are many tools to help you with this.

Email is my number one tool of choice, because (a) it doesn’t require both parties to be online and (b) it retains all information in an easily searchable format. Approach emails the same way you approach specifications. Write detailed answers, use bullet points to separate items, use screenshots, avoid ambiguity as much as possible.

Develop a habit of answering your developers questions before the day’s end. That way they can work while you sleep.

Chat (slack, skype, hangouts) is good for real-time discussions. I recommend chatting during pre-arranged times so you don’t distract your developers with a constant stream of questions. Avoid lengthy explanations in chat – use email instead. This will allow you to better word your explanation and make it easier to find it later.

Video/voice calls are the least effective – the information is not retained anywhere. Also spoken English is much harder to master than written, so the conversation can be very frustrating for both sides. If you need to share your screen – Skype makes this easy. For screen sharing also consider recording a video of your screen – that way it can be retained and shared with other team members in the future. Jing is free software that allows to record your screen and share the video with anyone. Snagit is a more advanced paid version.

Sharing screens with Skype - Hiring an offshore software developer

Skype makes it easy to share screens

5) Are you prepared to do thorough testing of your application and document each bug?

Don’t rely on your developers to deliver a bug-free first version. There will be bugs. Almost every application you use has bugs. Companies like Facebook, Google and Apple invest millions in bug hunting programs. Your application will be no different, and it’s not necessarily because your developers are bad. There are several reasons for this. First is complexity – a typical application has many interconnected components and our brain has no way of predicting all possible scenarios that can happen. Second, many developers hate testing, because it is extremely boring compared to coding. Another reason is that developers are so “zoomed in” they stop seeing the forest for the trees and can no longer use the application as a regular user would.

So you’ll have to fill the gap and test every aspect of your application yourself. Keep in mind that, as a creator of your app, you likely will not be able to use it as a regular user.

Having a group of people who can use your early product and report all issues directly to you can make a big difference.

They will help you not only catch bugs, but discover parts that are hard to use or not clear.

When you find a bug, make sure to give your developers step-by-step instructions on how to reproduce a bug. Instead of writing “Form doesn’t work” write “1. Fill in First Name, 2. leave Last Name empty, 3. click Submit – witness error screen (screenshot attached)”. Include browser name and version or mobile device model you used.

Remember, bugs don’t automatically mean your developers are bad, so don’t get frustrated right away. However, if the same bugs appear again and again after your developers fix them – this is a red flag. This means they are having a hard time managing the complexity of the app.

Here’s a great read on why software testing is so important.


There will be bugs - Hiring an offshore software developer

Software is complex – There will be bugs

6) Is your product going to be built with cutting-edge or uncommon technology?

Lastly, if the core technology of your product is still in early stages of its development and requires a lot of research and/or experimentation, then your product is probably not a good candidate for outsourcing.

Check if your product belongs to categories of AI, machine learning, computer vision or related fields. Does it require deep academic knowledge? Is it based on a math-heavy research paper?

Remember that outsourcing is best for well-defined projects that don’t require special domain knowledge or extensive research.

However, the chances are you can still outsource a part of your project. Example: Pandora uses the Music Genome Project at it’s core, development of which requires a lot of research and can’t be outsourced. However, you can easily outsource the web interface: login/registration, playlist, music playback, payment processing, etc. This can be beneficial for your startup, allowing your in-house team to focus on stuff that is truly hard, while outsourcing the more defined, but time-consuming parts of your project.

Focus on the truly hard tech in house - hiring an offshore software development company

Let your in-house team focus on the stuff that is truly hard

Tying it all up…

As you can see, there are many things you need to think about before finally pulling the trigger and hiring developers. Founders that skip the necessary prep work often fail miserably and end up spending their valuable time and money on a product that doesn’t work.

Don’t be one of them.

Use the steps that smart entrepreneurs and agencies follow to consistently and cheaply achieve great results.

To put it in perspective, think about an offshore development team or freelancer not as a one-stop shop that magically solves all your problems (although many will want you to believe they are), but instead as an assembly line that you rent to build a part from your blueprint. With no blueprint how is the assembly line supposed to figure out what to build?

If you’ve had experience with outsourcing software development – please share your story of success or failure in the comments. If there is a smart trick that worked for you or a mistake others should avoid – share it. Who knows – some of these stories could provide a great starting point for a future article.

Comments ( 9 )

  1. ReplyChris Aram
    This article was a fantastic overview of how to solve this huge problem; that I (and most other non-technical founders) have personally experienced. The issue of not knowing what you need (technically) is probably the biggest pain point for me - with almost every developer & software engineer you meet telling you that they can build the solution you need (but in totally different ways), it's incredibly difficult to know who to trust (and which method IS best). The technical mentor solves this. I've read a lot about failed attempts to outsource development. The main reason given for projects failing is that the needs of the founder and the outsourced development team are diametrically opposed; that is to say that the founder requires the best, most robust product, often in the shortest time, and for the lowest price. He needs the features to perform as they should, and to have conformity, longevity and scalability - or his project is very likely to die a death of a thousand cuts. The outsourced team however, has no vested interest in the long-term success of the project. They want to earn the most money (as fast as possible if priced work, or as slowly as possible if on an hourly rate), they want to use the technology that they know (not necessarily what's best), and they tend to promise the World to get contracts and then under-deliver. I think that trusted referrals, test-jobs, a technical mentor, and some kind vested incentive might go a long way to solving this problem too. Thanks for taking the time to write the article - I've subscribed and will be following future articles with interest!
    • ReplyAuthorAndrei Anisimov
      Thanks for the feedback Chris! I agree with you on the conflict of interests. However, this conflict is only in the minds of short-term oriented developers who want to get a quick buck and move on. What I found instead, is that long term as a developer you benefit when your clients succeed. Because if I help somebody make more revenue, guess who's one of the first in line to receive a portion of that revenue? :) Joking aside, in my view, the key to resolving this conflict is avoiding long-term open-ended projects with a vague scope. Instead breaking the project into short phases (say 2 week - 1 month long) and treating each phase as a separate project with a clear, limited scope. Such that there is not much flexibility for developers to choose what to spend time on. At the same time this protects developers from so-called "scope creep" - when clients try to add more features/make changes for the same price. Scope creep is a common frustration for developers and the reason they want to get out of such projects quickly. This is also the reason why larger, less clear projects will likely receive higher price estimates - developers add "protection" from unexpected scope creep.
  2. ReplyStephen Findley
    Andrei, great article, thanks for posting. In answer to Chris' comment, I really think it comes down to vetting the team that you work with. Short sprints help break up a project and provide a structure but it's really about getting to know the people you are going to be communicating with. Having worked on business development with offshore teams I am a big fan of spending a lot of time getting to know founders prior to commencing work. Often the tech team takes some risk, yes they can develop a quick MVP, but all the good development teams want to work long term with their clients - hence they need to know they have the right leadership team in place and are committed to their project. Spending time during this courtship phase is really important - for me on the business development side, I take these relationships very seriously and think of them as a personal recommendation from me so I want to know my developers will be a safe pair of hands. I often check in on an impartial basis to ensure the lines of communication are open and that both sides expectations are being managed. I do agree with your point around "scope creep" and there are some clients that ring alarm bells in this respect. However, I also believe that a well-crafted scope of work mitigates some of the risk on the understanding that if a project re-iterates or pivots, then revisions to cost/timeline will need to be made. Thanks again for the post!
    • ReplyAuthorAndrei Anisimov
      Stephen, good point on vetting. Doing a short trial project is another good way for both sides to get to know each other and see if there is a fit.
  3. ReplyLaurent
    thanks for the article. I have been working for a few years now with outsourced agencies or freelancers and the article came as a bit of a reminder as of the good practices to follow to ensure you run your project smoothly. A couple of question: - How would you feel about hiring several freelancers working on the same project to speed up the development time if the main developer has a limited bandwidth ? - Say I use github, would you have specific recommendation in regards to managing feature development, again in a scenario where multiple separate developer are working on the same repo? Thanks !
    • ReplyAuthorAndrei Anisimov
      Laurent, thanks for the feedback. Re your questions: 1. I do hire several freelancers to work on the same project sometimes. I usually have them work either on separate modules or on different layers of the same module (e.g. front-end, back-end), to make them independent of each other as much as possible. Simply adding more developers doesn't automatically speed up the process. Only if their work is more-or-less independent and responsibilities are clear. Also, the main developer (team lead) will now have to spend some time merging other developers' code into the master branch, resolving the conflicts and other related tasks. So the increase in productivity is not linear. A very common scenario where I use several freelancers is when there is a backend or full-stack developer and an HTML/CSS developer. These roles can be separated effectively. 2. Regarding the feature management in github. First, every feature should be in it's own branch in git until it is done and merged back into master. Second, the main developer will have to do the merge and code reviews. I usually restrict everybody except the team lead from pushing code into the 'master' branch (github allows to do that). This forces everybody to use the 'pull request' feature, which in turn allows the team lead to review the code before accepting the change.
  4. ReplyLaurent
    Hi again Andrei, thanks for the detailed answer. Actually i had this morning a chat with our lead dev and we discussed exactly the things you alluded to in #1. Merge conflicts etc. It looks like a good practice would be that when developer #2 finishes developing a feature in his branch , to pull latest changes in master and deal with the merge conflicts which could emerge. I like the idea to to have a full stack developer and another pure html/css guy (which i understand will be more design/UI focused) though might not be systematically applicable in complex app using MVC frameworks on the client side (angular in my case).
    • ReplyAuthorAndrei Anisimov
      Laurent, yes, that's another potentially good approach to resolving merge conflicts. But this has to be done carefully, so that the developer #2 doesn't overwrite some important change in master by accident. I prefer the lead developer to resolve conflicts, because it forces him/her to review the code being merged and stay on top of things.
      • Replylaurent
        got it ! Cheers, thanks for your time again.