This is part 4 of the Building successful MVP with offshore team.

Now you have a specification of your application and developers. It’s time to put on the next hat – project manager. That’s the key part to your success – you have to manage the development process.

A quick note before we move on. You should own the code. Never let developer show you the pieces of the product without giving you the code. Create an account on github and make sure that developers work with a repository there. You SHOULD OWN your code.

Manage and prioritize the work. Don’t create a list of features and let the developers decide what to work on. Tell them what should be done in what order. Work on the unique features of your application first. Do not start with Sign In, Sign Up and so on – features that are common for most applications. Build the core of your application first. This way you can address the most challenging and unknown parts earlier in the process.

Tell developers to show you how UI will like ASAP. There is no need to build the whole backend with API and database to show the actual UI. Developers can always use fake data before building the backend.

Use kanban board to prioritize the work. Here is a good example with Trello. I usually have the following boards:

• inbox (all new items come here before being prioritized)
• V1 or V2 or MVP or whatever version you plan to release (try to schedule only the version that you are working right now)
• Next Up – the next items that developers should work on (no more than 2-3 items)
• In Progress – this is what developer is working on right now (there should be no more than 2 items here, e.g. a feature and some urgent bug to fix)
• Testing – items are under QA’s testing
• Done – items that are done & tested
• Later – everything that you plan to work on after the current release

Most of the work items (bug, feature) move this way:
Later -> V1 -> Next Up -> In Progress -> Testing -> Done

Don’t overcomplicate it and create too many boards for any possible scenario and development steps. If in doubt – put items in the Later board.

Lear how to triage bugs. Not all bugs should be fixed, even critical ones. Consider the probability of the bug. It’s like insurance – yes if some bad thing happens, it can be costly, but the probability of it is so low and insurance is so high that it doesn’t make sense to have it.

Ask a developer to commit the code daily, especially at the beginning. This will give you a sense of the progress. Review the new code daily. No, you don’t have to learn to program nor to understand the code. But if one commit has a few lines added (sometimes these can be blank lines) and then removed in the next commit, it’s not a good sign. Look, it’s like writing a book – if an author writes only 100 words per day, it’s not good. GitHub will let you compare the changes. You can also track the progress with GitHub activity monitoring tools.

Be proactive. Get everything ready for the next item the developer will work on ahead of the time. Prepare UI design, UX flow, business and data validation rules, and so on.

All this work should not take you too much time. Depending on the number of developers it can be no more than 2 hours a day. Yes, it looks like a lot of work, but this is the road to a happy and frustration free launching.

This is part 4 of the Building successful MVP with offshore team.

This is part 4 of the Building successful MVP with offshore team.

Where to go?

One man said:

If you need a code – hire developers from India, if you need a solution – from Eastern Europe.

India and Eastern Europe supply most of the offshore developers. There are very common advantages and challenges working with developers from these regions.

Indian developers work best when you need very common applications like CMS, e-commerce, social network and so on. They can deliver such application very fast and with an acceptable quality. Their English is good, but time difference can be a challenge. Also, they tend to work with older technology stacks. Nothing wrong with that, of course. But if later you consider growing the engineering team in-house, this may present some challenges.

Eastern European developers work better on a project that is unique and requires more research, like IoT or ML applications. The time overlap with Eastern Europe is better, but English may be more challenging. Focus is another challenge. Quite often these developers are more interested in writing code rather than delivering a working product.

There are also good developers in Western Europe, Latin America, China and the US, but I have less experience with them.

Selection criteria

Here are the criteria that I use to select the candidates:

• hourly rate that fit my budget; check the actual rate that freelancers have charged on recently completed jobs because quite often it’s lower that posted rate
• region (see above)
• agency – in most cases I try to go with agency rather than a single developer; agency can provide more people if needed or substitute a person if developer is sick or on vacation; but they can also quietly “downgrade” you – give you a senior developer at first, but then replace him with a junior one without telling you. Yes, unfortunately, this happens.
• total hours worked, especially recent hours
• success rate and feedback.

Select 5 – 10 candidates and invite them to apply for the job.

Now, about the fixed scope. I would not recommend doing it. It almost never works. Because you have to prepare a detailed specification of the whole application upfront. And whatever price you get will be wrong, because at that moment for most of the freelancers its important to get the job and they will underestimate the effort. It’s better to describe what you need in general, get a rough estimation and then multiply it by 2. The actual time and cost depend on how well you will manage the project. I’ll talk about this later.

When you select candidates, ask for their work – anything that they can show you, whether it’s a completed application or code. Check it, but you cannot be sure that this is really the work of that developer.

Now you have your candidate and ready to go ahead full speed. Stop, don’t do it. Test the developer first. Select something small that should be developed, like Sign Up feature, or Forgot Password or list of the blog posts to show. The developer should be able to get it done in 2 – 5 days. Ask the developer to give you an estimated completion time and work with him. When the feature is done check the following:

• whether the actual completion time is close to the estimate
• was it easy for you to work with the developer
• how many bugs you found in the completed work

If you don’t have any red flags, then hire this person for the rest of the project. Otherwise, pay for the completed work and try the same process with another candidate until you find the right person. Yes, you can loose some money short term but will lose much more if you will continue with the wrong developer.