This is PART 5 of a blog series that details software development outsourcing risks and challenges. Go back and check out previous posts:
- Software Outsourcing Challenges: Billing Models
- Software Outsourcing Challenges: Buyer's Remorse
- Software Outsourcing Challenges: No Skin in the Game
- Software Outsourcing Challenges: Paying for Bad Experiences
Software development is always on the cutting edge of technological advances.
It’s the foundation that allows us to design tools that make our lives easier and stay ahead of the game. But developing is far from easy. And honestly, sometimes it requires outside help.
Even though the number of software outsourcing providers has skyrocketed in the past few years, the overall quality of work and level of customer satisfaction hasn’t.
We want to change that.
With over 15 years of experience in software development, our founding team has experience both from the perspective of an agency as well as a client.
🧭 We’ve received vague requirements (and given vague requirements).
🍒 We’ve dealt with picky customers (and been a picky customer).
🐛 We’ve complained about bugs to suppliers (and been the ones fixing bugs).
To put it simply: we’ve been on both sides of the fence. This has given us a unique perspective to understand the drivers and motivations behind clients and agencies when it comes to problems with outsourcing software development.
What Is a Vendor Lock-In
In an ideal open market environment, customers would be able to “lift and shift” freely as they want. If they are not happy with their existing software development agency, they can simply replace them with a new one. Right?
In the real world, it's complicated. Some software vendors make it particularly difficult for their clients to migrate projects and the IT infrastructure to a competitor or even in-house.
Accepting your right to move freely means lost revenue streams for the software development agency.
The vendors never explicitly prevent clients from switching to different providers; they just impose financial, and legal restrictions that cut any exit strategies and eventually impose a vendor lock-in situation.
Another software development agency trick you should be aware of is the so-called "Bait and Switch", I quickly explain what it means in this video 👇
How to Avoid Vendor Lock-In
Depending on a single vendor isn’t always a bad thing.
Many software outsourcing agencies serve as trustworthy, long-term partners for IaaS, SaaS, PaaS, and FinTech companies for years. IBM and Microsoft constantly build new technologies and expand their open source software capabilities with a wide-casted network of software partners.
However, if you’ve just started developing your app or looking to expand the core product functionality, vendor lock-in risks can jeopardize your entire ecosystem.
A vendor lock-in in cloud computing is a slightly different topic that deserves a separate in-depth review. Why you should be careful of choosing a single cloud vendor when using cloud services, you can read in this article from Cloudflare.
Here is what you need to watch out for to avoid the risk of software development vendor lock-in:
⚠️ Watch out for Notice Periods
The most obvious kind of vendor lock-in risk is of course time bound, in the form of notice periods.
Notice periods are typically present in long-term collaborations, instead of one-time projects, however, they are more common than you think. Notice periods can vary from a few weeks to a few months.
Be sure to read the fine print when you are reviewing the contract. If necessary, invite a lawyer on-premise to do it for you.
Also, in some use cases, certain contracts cannot be terminated for their whole duration. For example, if you sign a two-year contract with a cloud platform vendor you are stuck with that vendor for the next two years.
Some clients need and want that, as it’s usually enforced from both sides, meaning that the technology vendor also can’t walk away from the agreement. However, in such collaborations, you need to extensively test the team who is going to work on the project and perhaps test different vendors before committing.
It is very common for clients to ask for extensive trial periods, lasting a couple of months before finalizing the agreement. It might sound time-consuming, but otherwise, the risk you are taking is just too high.
⚠️ Migrations & Handovers
As a software architect or CTO, have you ever taken over a product that was developed externally? It’s like going to the dentist, you don’t really want to do it unless you HAVE to.
There is a lot that could go wrong with migrations in general:
- Undocumented legacy processes
- Incomplete fit-gap analysis
- Tedious mapping
- Lack of standardization
But if that wasn't enough, the fact that they are the agency and you are the client, complicates things. Now you are leaving them and a breakup, just like real life, can be difficult and painful.
It doesn't end there...
Here are some things that a software agency can do to make your migration even more difficult and eventually increase your switching costs:
- Drop in quality of service
- Leave a gap of knowledge behind, critical questions remain unanswered
- Unfinished documentation
- Reassignment of key developers with knowledge silo
Note: I am not suggesting that all agencies are evil and they will for sure act in this way. I am only speaking on the incentives that are in play and my previous experience from being on the other side of the fence.
⚠️ Technology Lock-in
Technology lock-in is the kindest of all lock-ins and it’s often unintentional.
Something like COBOL is too old, there are very few new systems being build with it (unless you are adding a new feature to a legacy system).
And something like Go, while in trend, it might not be widely used (at least not as of this writing). So it might be difficult to find additional developers to work on your project when it scales.
When you are just getting started, agencies make it very easy for you to use their services. They employ free trials, generous availability, short onboarding times, and even free service upgrades.
To detect such behaviour early and mitigate a potential vendor lock-in risk, it is also useful to know all the red flags when hiring developers in general: