Building successful MVP with offshore team. Project Manager.

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.

Building successful MVP with offshore team. How to find a developer.

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.

Building successful MVP with offshore team. Part 3.

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

Remember – the more details you let the developer interpret freely and assume, the more likely you are going to fail. Think about it this way – if you decide to build your own house, will you tell the builder that you would like to have a gorgeous open floor plan house with 4 bedrooms? I guess not. You will go through each detail of your dream house before any construction starts.

Product manager

Product manager converts your vision of the application into the exact specification of what user will experience. This includes the exact steps of how a user navigates through your application, mockups of each screen, any data validations and so on. The key word is “exact”.

Let me give you an example. It’s not enough to tell a developer that you need a Log In functionality. You should provide the exact details about it:

  • Should it accept email and/or username
  • Any restrictions about username and password
  • Error message if Log In fails or any field is missing
  • Should user be able to stay logged in (Remember Me option)
  • Should log in ever expire
  • How you are going to handle “Forgot my password”
  • and so on and on …

But this is too much work to describe all these details. Shouldn’t developer already know all these?”. No, but he will assume, and that’s not what you want. Believe me, you will do this work anyway. It’s just a question whether you will do it upfront or after the coding is done, the result is not what you need and it should be rewritten. Doing this work upfront saves you time and money. It also gives your QA the exact testing plan.

Now the question is how can you nail all these details upfront? It’s not that difficult, just don’t try to invent a bicycle. Find any popular application that has a similar functionality and check how it works. For our example with Log In, you can try Facebook, Gmail, Instagram or Quickbook. Try all possible scenarios, write them down, apply for your own case and pass them to developer and QA. You should discuss this specification before any development is started. Make sure that it’s very clear for developer and QA that they should not assume, but ask.

Be proactive and you will succeed.

Building successful MVP with offshore team. Part 2.

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

What is MVP?

Let me define what I mean by MVP before going into recommendations. MVP is a product with the least set of features that founders can use to test their business model. You have to consider whether it’s a throw-away or a foundation for your real product. Most founders start MVP with a throw-away approach in mind. They would like to build something quick & dirty and test with a few clients. They plan to build a solid product if MVP has some traction.

It doesn’t work this way in most cases. Founders continue building on top of the throw-away MVP as soon as they get some traction. And soon they have a code that’s difficult to maintain and grow. Their application doesn’t scale and performance is bad. And sooner or later founders face a taught decision – invest into rebuilding the product.

It should not be this way. It’s possible to build a prototype without any investment at all (I am talking about cash, not time). You can do the UI in Sketch and test the UX in InVision. These are very valuable tools that any founder should consider mastering anyway. BTW, I discourage a common theme on startup forums- learn how to code. Programming is not easy. It will take a lot of time to learn it to the level where you can produce something beyond “Hello, world” application.

Originally published at

It’s possible to build MVP on a solid foundation that will be a “keeper”. And it does not need more time or money to build than a throw-away product. I’ll be describing how this kind of MVP can be built.

Developer is not enough


Steve told me: “If only I could find a good developer …“. If you also think that the “right developer” is the way to success, sorry, but you are wrong. If you think that you can pass your vision to a developer and get it back as an application that is close enough to it – forget about it. Save your time and money.

To build a good MVP you need:

  • Product Manager – translates your vision into actual product behavior
  • Project Manager – triages the work and makes sure that it’s done on time
  • UX/UI Designer – defines the experience that users get from your application
  • Architect – makes sure that the “foundation” of your application is good and you will not have to throw it away later (optional, but …)
  • Developer – writes code
  • QA – finds the bugs and verifies the fixes

If you find a developer who can wear all these hats – great, but it’s not going to be cheap. Now, you can hire people to do PM, PrM, UX/UI, QA. Or you can do it yourself. In any case – there ain’t no such thing as a free lunch – you will pay for this work with your time or your money.

I will share how you can do all these work yourself in the next posts (it’s going to be more practical).

Building successful MVP with offshore team

My friend Steve (not a real name) called me recently. He would like to launch a business. He has an idea, business plan and some money to build an MVP. His question: How to? Steve cannot afford SF BA developers. His option is to go offshore. But he heard a lot of scary stories about working with offshore developers.

I’ve heard them too. A lot of them. People had a very bad experience. They will never deal with developers who are not with them in the office anymore. It hurts, I know. I would feel hurt and furious if my personal money were on the line.

But I’ve built successful high-quality applications with offshore teams. And the cost was a fraction of what it would cost to build in the Silicon Valley. I’m not the only one.

I gave Steve some recommendations. I will share them here in the next few posts. Steve can build his MVP offshore. He can do it fast, on budget and without a stress. These recommendations may be useful for you too.

Giving birth to a software

There are a few exciting moments for a software developer when he builds a software (and love doing it). First “clear” run, 1M customers using it without a problem, … For me the most exciting moment is the “birth”. At first there is nothing, nothing material – just some thoughts in the people’s heads. And then you create a folder, name it, add some files and run it. And it runs. It does nothing really, but it runs! There was nothing, and now there is something. This “something” is small, useless and ugly, but you see the future beauty of it. You see people who will use it, love it (or dislike). It will solve their problems and make their life easier.

But it’s still just yours at this moment. And then you commit. And boom, it’s part of the world, not just yours anymore. Even if it’s only your partner or code repository who knows about it. It’s out “there”.

And although I do it every day for some “exploration” projects, it’s different. That doesn’t bring that excitement. But starting an application that will “live” is like planting a tree or breaking ground for a new home. I may not see the tree grow or build the most of the home, but it’s all about starting it. Yes, I love to see a working product in the hands of the people. It feels good. But starting it …

I see quite often auto-generated comment in the code “Created by …“. I never like it. But when you commit the code, you have to give your name. And I know that there are a few products around that have my name at the root. And it brings a happy smile to my face 🙂.

A few day ago a new tree was planted …

Stop using Slack


Confession – this is a flashy title to attract an attention. Slack is a great tool and you should use it. But, please, STOP abusing it.

Let me explain my point of view. It’s a great tool to have a conversation with your team members. But it should not be used to preserve the knowledge. What knowledge? Anything that related to your work like discussions about product features, roadmaps, decision points and so on that you may need to reference back in the future.

Let’s say you have to discuss a specific feature of your product. I assume that you already have it tracked in one of the applications like Trello or Asana. It’s so tempting to just jump into one of the Slack rooms and start the discussion there. But unless you have a room for each features, bug, task don’t do it. And, no, I don’t advocate to have a room for each working item you have to discuss. Instead of going to Slack, find this item in the tracking system that you use and discuss it there. Your discussion is the knowledge that you would like to preserve. It can be useful for you in a couple of months or for your teammates when they will need it later. One item – one place to store everything important about it. It makes much easier and faster to find information when you need it.

Have you ever came back from vacation to find your Slack room full of unread messages? No? Well, I guess you don’t use Slack then :). How can you get up to speed with any decisions that were made about a particular task? Search? Read all the messages in a particular room? But it has discussions about 10 other items, all “shuffled” and polluted with totally unrelated chatty messages. But if that discussion is kept with an item itself in the tracking system, then you will get what you need right away.

Are you a manager? Then you have to track all work items of your team. But you don’t have to track ALL of them right away. Some need your attention right away, but some – can wait. You know that there is a discussion going on, but you don’t care about it right now. You will deal with it later. But when the time will come, you want to get up to speed fast.

So, do use Slack. But keep your knowledge where it belongs – with your work items. A small effort to put the information where it really belongs will go a long way when you will need it.

Urgent vs delayed

Another disadvantage of Slack comparing to email + IM is no explicit sense of urgency. In most cases, when we receive email, we know that we can reply later (unless it’s stamped as urgent). But when somebody pings you via IM, it means that there is a need for an immediate reply. Well, this is how it is in most cases. And this is not very clear with Slack. Unless you read the message, you don’t know whether a response is expected right away or it can wait.

This is not a big deal, because it can be easily fixed with some tag or “stamp” of the post. Just agree with your team what it will be.

And remember, a tool only as good as the user.

Happy collaboration!


Some time ago I’ve moved this blog from self-hosted WordPress to The folks at had a very nice idea – write your posts in Evernote and just publish them from it. And I love Evernote. I use it a lot. So, it was a very easy choice for me.

But later went from a free and subscription model to subscription only. And the price ($10/month) was too much for me. I was not alone. I’m not sure what the future of will be, but I think that price should reflect the value.

So, this weekend I’ve moved back to WordPress. Even after a few years away it feels homy. It’s good to be back.

Better TODO comment

Here is a simple trick that makes TODO comments more efficient. You have seen TODO comment like this all over the code:
//TODO: convert to prepared statement.
var query = 'SELECT processedDateTime FROM ProcessedEvents WHERE hash = ?'
Yes, it’s good to have it. This is a way to track a technical debt. And here is how it can be much more useful:
//TODO: vvs p2 convert to prepared statement.
var query = 'SELECT processedDateTime FROM ProcessedEvents WHERE hash = ?'
Just 2 small pieces are added:
vvs – your initials,
p2 – priority (p1, p2, p3)
Now, you can search the whole code base for your own TODOs (or TODOs created by a specific person). And when you see a comment like this there is no need to go to Annotate or Blame to find out who has left it (save time).
When you leave a TODO comment you are in the best state to analyze the impact of the incomplete work. That’s why putting a priority at that moment is so crucial.
It’s a simple trick that can save you tons of time, especially when you manage a team and do daily reviews of all commits.

Easy mocking in Node.js

I’m a big believer in unit testing. Not only because it allows me easy code refactoring and faster regression testing, but because I can deliver product much faster doing unit tests. Yes, writing more code (unit tests) shortens product delivery time. But this is another topic.
Efficient unit testing is not possible without mocking. In Node.js I was a happy user of rewire. I liked it. Until today. For whatever reason it stopped working for me. Either it doesn’t like me anymore or something wrong with me, but it refuses rewire modules.
So, I’ve spent some time looking for another mocking framework. There is a number of good ones around. But all of them didn’t feel 100% right. Especially when I compare them with framework available for C# or Java that I’m used to.
So, can mocking be easily and nicely done without framework? Sure, the same way I have never used any IoT/DI frameworks with C# – always used simple manual injection.
And it’s actually very easy with Node.js.
In the following code, I need to test create function. There are 2 calls that need to be mocked for unit tests: inboxDb.create and inboxProcessor.processEvent. Here is a manual mocking with  just a few lines of code – check the mock setters (t the bottom of the code.
'use strict';
var moduleName = 'inbox.controller'

var Promise = require('bluebird'),
appRoot = require('app-root-path')

var inboxDb = require(appRoot + '/server/components/inboxProcessor/inbox.db'),
MessageModel = require(appRoot + '/server/api/messaeg/message.model'),
inboxProcessor = require(appRoot + '/server/components/inboxProcessor/inboxProcessor')

* Processes incoming message.
* @param req
* @param res
exports.create = function (req, res) {
var payload = req.body.m
var ipAddress = req.connection.remoteAddress;
console.log('%s|create|payload:%s', moduleName, payload)

var message = {}
inboxDb.create(payload, ipAddress).
then(function(result) {
try {
message = MessageModel.parsePayload(payload, ipAddress)
return Promise.resolve(message)
} catch(error) {
console.log('%s|create|parsePayload|Error: ', moduleName, error)
return res.send(204, 'poison')
}).then(function(event) {
return inboxProcessor.processEvent(event, payload, undefined)
}).then(function(result) {
return res.json(201, result)
catch(function(error) {
console.log('%s|create|Error: ', moduleName, error)
return res.send(500, error)

/* Mock setters */
exports.setInboxDb = function(mock) {
inboxDb = mock
exports.setInboxProcessor = function(mock) {
inboxProcessor = mock
Now, with this setters in place, mocking is actually very easy in the unit test:
'use strict';

var Promise = require('bluebird'),
should = require('should'),
request = require('supertest'),
appRoot = require('app-root-path')

var app = require(appRoot + '/server/app'),
target = require('./inbox.controller')

describe('POST /api/inbox', function () {

it('should process message', function (done) {
target.setInboxDb(setDbMock('ok', false))
target.setInboxProcessor(setInboxProcessorMock('ok', false))

var data = { "m": "message - actual content is not important"}
.expect('Content-Type', /json/)
.end(function (err, res) {
if (err) return done(err)


function setDbMock(result, throwError) {
var mock = {
create: function(payload, ipAddress) {
if (throwError) {
var error = {message: 'db error'}
return Promise.reject(error)

return Promise.resolve(result)
return mock

function setInboxProcessorMock(result, throwError) {
var mock = {
processEvent: function(event, payload, next) {
if (throwError) {
var error = {message: 'error'}
return Promise.reject(error)

return Promise.resolve(result)
return mock}
By replacing actual invocation with our mocked functions, the code is easier to test and debug (in this case I’ve just created a wrapper that allows me to return some result or throw an error):
target.setInboxDb(setDbMock('ok', false))
target.setInboxProcessor(setInboxProcessorMock('ok', false))
Yes, it’s minimalistic and doesn’t have all the bells and whistles of other frameworks. But, it’s simple and will cover 80% of the mocking needs.
Update. I’ve opened another set of unit tests with rewire today and it worked flawlessly. I’m not sure why the first set didn’t work, but I’m glad that I’ve found this simple solution and will stick with it for now.