In part 1, we have tackled head-on the cost question on developing a software product in-house versus outsourcing it. Outsourcing to an Outsourcing Development Center (ODC) in an emerging market seems to win the founder’s maths.
In this post, I would like to discuss a few pitfalls in the outsourcing approach.
To set the context, let’s first define outsourcing.
What is outsourcing?
In order to develop a software product, you can hire software development companies (SDC) to build a part of or the entire product. These companies usually offer software engineering service as the main capability; some offer design services in addition to that.
You can probably find one in the country where you company is based in. But generally speaking, if cost is a priority, people tend to outsource development work to companies in India, China, and Vietnam as the manpower cost there is much lower.
There are usually two modes of engagement: project-based and dedicated headcount.
Project-based outsourcing
For the former, as a client, you need to come up with the project requirements upfront (often in great detail).
The SDCs will provide a quotation based on how much efforts they think they will need to execute the requirements.
Once the contract is signed, on one hand, new requirements that fall outside of the original scope is considered a change request, which will cost extra.
On the other hand, if the project requires more manpower for a longer duration than estimated to complete, the SDCs will usually have to bear the additional cost.
Dedicated headcount outsourcing
If your product requirements still have a lot of room for change (a likely scenario when you are in the early stage of building a product), you can opt for the option of hiring dedicated headcount from an SDC.
You may give them an idea of your requirements so that they can match you with talents with relevant skillsets. If you know who you need, you can put up a request for specific headcounts.
For example, 1 team lead with 3 years of experience, 1 frontend engineer with ~1 year of experience with React, and 2 engineers with 1–2 years of experience with Nodejs
The SDCs will give you a rate card on how much an engineer with a certain level of experience will charge for an hour of his or her work. Once the engagement starts, what you pay is the hourly rate multiplied with the number of working hours your handpicked teams spend on your product. This approach tends to be more expensive the project-based one.
You do have the flexibility to add and remove team members as you go. Unlike a project, there is no hard completion date. The engagement can last as long as you think you need.
How is outsourcing a death trap?
You might have probably guessed a number of pitfalls simply based on my description of how outsourcing works. The first on the list will be quality concern.
1. Quality is a big headache
If you have no prior experience working with SDCs and are looking for one from Google search, it will be hard to tell the good SDCs from the bad ones. Company websites and conference calls can give you a general impression of the SDCs. But you will not be able to know for sure until after you have started working with them.
Many times, the person you deal with during the initial enquiry and negotiation process is a sales person, who is not the same person working with you during development.
1 particular SDC that I worked with had very minimal testing done. At every user acceptance test after a feature was released, my team would find a myriad of logic, design, and language bugs that should have been caught by their Quality Assurance (QA) team. We always had a suspicion either their QA did not exist or they did a half-hearted job.
During the handover, to our dismay, we found out there were no proper test documents. There were no scripts for unit tests and integration tests. This had also cast doubt on the quality of the code they wrote, something we would not know for sure unless we analyse the entire code base.
On another occasion, my team used the dedicated headcount approach with another SDC. Our engagement turned sour when we realised they were stalling. Many excuses were made to justify why they took an unrealistically longer amount of time to develop a feature that took another SDC a much shorter time to complete. The motive, I suppose, was to make us pay them for a much longer period than required.
You might ask why we did not switch to another SDC as soon as the early signs of trouble showed up. The answer is the next pitfall.
2. Outsourcing has a high hidden switching cost
Be it a project-based or dedicated headcount engagement, there is a deposit amount paid that will be forfeited if the contract ends prematurely. For a startup that is trying to be prudent with every dollar spent, the deposit amount is significant.
Even though there are contractual terms that allow us to terminate the contract without penalty if the SDC fails to deliver the requirements satisfactorily, in reality, it is hard to enforce them.
In the case with the SDC who hardly did any testing mentioned above, features were still developed. They still worked to a large extent. The SDC still diligently fixed the bugs that were reported despite being very inefficient.
Due to a lack of quality control, the same bugs could be fixed and re-fixed 3–4 times, resulting in much time wasted on our side running the user acceptance tests time and again, in addition to testing new features that were released.
To make matter worse, if we were to switch to another SDC, there is a high chance the new SDC would not continue building on top of what the previous one has developed. The reason is it takes a lot of efforts to understand and maintain codes written by someone else. They would likely start from scratch. And we might end up repeating the same vicious cycle.
As a result, since there was a significant amount of time and money invested, unless things were absolutely horrible, we would just suck it up and continue.
This project, which was originally estimated to last 15 weeks, has in fact taken more than a year to complete. The one-year duration was not only due to the inefficient bug fixing for the original requirements. It is also because we have experienced numerous scope creeps.
3. It is hard to be agile when you have to cook up requirements upfront
As a startup working on a new product idea, every day, you discover new things about your customers and users, which requires the product to change in response.
Having a project-based engagement with an SDC simply does not support that kind of agility. Requirements defined two months ago could have been outdated; but they would still be developed anyway. Changes in requirements will be charged accordingly.
This is not the worst that can happen. With a waterfall approach like this, startups can make the mistake of defining a product in too much detail, at a stage where nothing is concrete.
After months of development, the result is a complex product, which will be launched to the market, with no guarantee of a favourable response.
There is a very real possibility the whole thing might flop.
Dedicated headcount approach can work better in this aspect since your requirements do not have to be set in stone, provided that someone in your team can lead and monitor the development tightly.
4. Handover is painful
When the development contract ends, you can enter a maintenance contract with the team that builds the product. If you loathe working with them, you will be in for a rough ride.
If you do not hire the same team to continue maintaining the software, you will have quite a challenge in the handover. Either your own team needs to inherit the code base, studies it, and starts managing it or you need to get another SDC to do the same thing.
It is tedious to take over someone else’s code, especially if there is no proper documentation. In many situations, the next team will find what was written lacking and would rather re-write one from scratch.
Sometimes, in the pursuit of low cost development, the software could be written in languages and frameworks that were no longer popular, creating a challenge in looking for talents with the relevant skillsets, willing to maintain and build on top of it.
5. You need tech leadership within your team
When cost is prioritised over sustainability, you might end up in a situation where different SDCs develop different parts of your product offerings with different languages and frameworks.
However, it is not yet time to grapple with such system complexity in your early days, when your attention should be on validating rounds and rounds of assumptions.
The key to avoid this is to have a technical leadership within your team. Think ahead about the pros and cons of working with SDCs to develop your products.
Choose one of the commonly used tech stacks (does not have to be the latest trending one) that preferably someone in your team is familiar with, and stick with it.
This enables you to be better-informed while working with your SDC counterpart, flattens the learning curve during handover, and reduces complexity for continuous development afterwards.
Then when is it appropriate for startups to outsource?
You can probably tell by now I am not a big fan of outsourcing product development to SDCs. Neither am I a big fan of hiring an in-house development team too early. But I recognise there is no perfect option.
I cannot stress the importance of a slow buildup while validating assumptions often enough.
If you need to engage an SDC in the process, my best idea of a safeguard is to ensure each round of engagement has a requirement scope small enough to be developed within a month by 1–2 engineers. Make sure you know what assumptions you want to test and how to test them prior to the development.
The bottom line is that outsourcing product development is a promising solution to a lack of software engineering talents in your lineup. I have tried my best to explain its pros and cons from my experience, which hopefully can help you make a better-informed decision should you embark on this path.
