Back in 2010, I was working as a chief technology officer (CTO) with a startup competing with the all-mighty Uber. My first mission was to build a world-class product with a development timeframe of only four months, launching in Israel first. Even more challenging though, we aimed to enter the far larger and demanding London market in under a year. Well, it was not just challenging, it was nearly impossible.
Luckily, my previous extensive experience with offshore development teams came in handy. To quickly speed development for the company, I established a small team in California where I was based and a larger offshore development team in Ukraine.
Offshore development can be a great value, offering easy access to a largely untapped talent pool. However, many inherent drawbacks can render this opportunity practically unusable.
At that time, with more than 15 years of experience under my belt working with offshore development teams in India, Argentina, Russia, and Ukraine, I was accustomed to the tactics many outsourcing companies utilize to hold on to their customers while providing poor service and never-ending promises.
Fortunately, I was able to spot these tactics at the beginning, successfully working around them and avoiding wasting any time or money on unreliable services. Long story short, we launched our business in the U.K. within a year as planned.
Today, I run a software development company of more than 120 web and mobile engineers and use my previous startup experience to help other companies and startups receive reliable development service without putting their business at risk.
Unfortunately, not all offshore software development companies are as trustworthy. Some use unscrupulous business practices to keep their clients hanging on with no option to leave. That's why I decided to share with you five of the lesser-known signs that your offshore development team is trying to trap you, plus what you can do to keep your options open.
1. The developer doesn't provide any specifications.
If there are no clearly documented project requirements, most certainly you will end up with a product that is not what you envisioned. As a result, you will have either to accept the product that isn't what you wanted or enter into an endless chain of changes and fixes that you will then have to pay for. As a result, the project will run over budget and will be delayed well before the final product is complete.
More importantly, without proper specs, you won't be able to change providers. You will need to start from scratch and write off the time and money spent with the previous vendor.
Solution
Make sure your cooperation with the developer starts with a product definition stage and include a thorough requirements analysis. By doing so, you should get properly documented functional requirements, high-level internal architecture, and a UX/UI design (usually in a form of an interactive visual prototype). These deliverables will then allow the team to draft the project roadmap and give an accurate estimate of the development effort and cost.
2. They underestimate the cost and time for the project.
It is hard to say no to an offer that is half the price of another vendor's estimate. As the old saying goes, though, "If something seems too good to be true, then it probably is." Avoid providers that give unreasonably low estimates, both in terms of the cost and the amount of time estimated to complete the project.
As many people realize who move forward on a project based on such an estimate, one soon realizes the estimate had nothing to do with the actual project timeframe and cost. Yet, at that point, it is too late to back out, having already spent weeks or even months investing in the project. Many companies that have made this mistake often come to similar conclusions as to the causes, with the main factors being:
- The team is too slow (e.g., missed deadlines)
- The quality of the product is poor
- Any additional feature requires significant changes in the core product
If you have been faced with any of the above-listed issues in your product, chances are, your actual problem lies in inadequate estimates.
It's not your team that is slow. A realistic estimate should always take into account all possible risks, including time needed to fix bugs.
Poor quality is a result of time constraints set by a poor estimate. As with many unscrupulous developers, in an effort to meet deadlines, the team sacrifices code and UX quality. As the deadline approaches and the product isn't even half ready, some developers resort to hardcode and raw scripts, ignore unit tests, and in a best-case scenario, launch software that works reasonably well only in their own environment.
The need for extensive architectural changes to implement a single new feature is also usually a result of insufficient planning and poor architectural design (due to time constraints). Architectural design and planning are the least obvious tasks for most clients, which is why many companies won't include them in the project roadmap. This is a self-serving approach as it allows them to keep the estimate low and win the initial project. At the same time, these project stages cannot be ignored: They are critical to the quality of the end product as well as to its scalability.
Solution
If you get a surprisingly low estimate from a vendor, reach out to several reputable companies and ask for their estimates. If other companies (or at least one of them) provides estimates that are significantly higher than your initial quote, find out why. Analyze each estimate carefully by breaking them down into smaller items and comparing them with the other estimates you have received. Also, analyze the time estimate.
If your current provider is constantly underestimating costs and time, try to calculate an average error (usually +30 to 50 percent of the estimate) and add this to their next estimate. However, if cost overruns and delays are common, consider switching providers as soon as possible.
3. The developer provides no code or poorly documented code.
Poor code documentation (or its absence) makes it impossible to switch providers without losing most of your code base. Other companies won't be able to understand and work with such source code, or they will spend months trying to make it better. This is one tactic that many dishonest development teams use, because it forces their clients to stay on board.
Solution
Make sure your team follows code documentation best practices. In this case, it is a good idea to have a CTO or tech-savvy co-founder by your side. Alternatively, you can ask a trusted developer to review the source code from time to time.
4. Core development is done on the developer's own CMS.
Using the vendor's own CMS/framework/platform as the foundation for your product might be another trick a vendor uses so you don't switch providers. No matter how good their technology is, what ends up happening is that no one else can support the product or make changes to it except for your initial provider.
Solution
Before you agree to use the offered technology, ensure the following:
- The program is open source, and you are not likely to have license issues in the future.
- You own all intellectual property rights, including the right to use the CMS within your product (and you can make changes as you see fit).
- The CMS uses a modern programming language so you can easily find specialists to support your product outside of the company.
- The CMS has comprehensive and exhaustive documentation.
5. The developer provides a project manager at no additional cost.
It's not uncommon for offshore companies to offer dedicated project management services as a free bonus if you hire that software development service. While this might seem like a great deal, remember, there's no such thing as a free lunch. Any qualified specialist should get paid for his/her work.
Of the company is generous enough to offer something for free, chances are, you will get the least-experienced project manager. As a result, you will be robbed of a vital aspect of the development process, which, in turn, can lead to the exact problems described above.
Solution
Don't look for a cheaper option and don't try to cut costs by ignoring vital aspects of the software development process. Talk to the project manager in person, and don't hesitate to ask for a better specialist (even if you have to pay extra). Hire a professional product manager to oversee the development process on your behalf.
Wrapping up
If you find yourself in any of the situations described above, don't hesitate to terminate your contract and look for a better provider (even if you have to start over). The cost of a software product that is delayed and of poor quality can be significantly higher than the cost of reinvesting into your new provider.