You have been working with a software outsourcing team and they have not been doing a good job. Your current team could be creating poor quality code, or taking a lot of time in creating the product or charging you more, there could be several reasons you are not happy with them. It is time to change your team. Before you change your software development team, you need to make sure you have everything with you. You have to ensure you have access to all the documents, source code, infrastructure and designs that you can handover to your new team. We have created a comprehensive checklist that you should follow to secure your intellectual property
1. Know your tech stack
You should make sure that you know what tech stack has been used to build your frontend and backend. This is the first question you will be asked from your new team. Below are examples of some of tech stack used:
Mobile App Stacks: Native iOS (Swift), Native Android (Java or Kotline), ReactNative, Xamarin, Flutter.
Web Frontend Stack: Angular, ReactJS, Vue. This is for the front end
Web Backend Stack: PHP, .Net, Python, RubyonRails, JAVA
Backend Database: SQL, MYSQL,
2. Source code
Source code is the real asset that you want to secure. New developer would require the source code to build upon it. Your current development team should be saving source code on a code repository like GitHub or Bitbucket. You want to get access to your source code on these code repositories. You should not get the source code in a zipped file from your current team. Getting source code in a zipped file is not the right method since you may not get all the files properly and you may not be able to see all the historical changes made in the source code. If your current team tries to give you the source code in a zipped file, say no to them and ask them to share it via Github or Bitbucket.
3. Database and API documents
If you have a backend database built for your application, your current team should provide you a database design document and an API document. A database design document shows the structure of your current tables and their relationships. An API document shows the APIs created for the front end, end points, request and response format. These documents are very helpful for your new team.
4. Requirement document
A requirement document defines your current functionality, business rules and requirements of your application. This document is used by the design and development team to build your application. You should update your requirement document to reflect the current functionality of the application and share it with the new team. If you don’t have one, make sure you ask your current team to develop it. If you don’t have a requirement document, it will be very difficult for your new team to understand the functioning of the application, it will also be challenging for them to add new features without having a requirement document.
5. Wireframes and designs
When you started working with your current team, they must have created the clickable wireframes and visual designs of your application. These designs are typically done using softwares like Figma, Balsamiq, Sketch, Invision etc. You should get access to these designs and share them with the new development team. The designs will help the new team to understand the current flow, user experience and architecture of the application. Your new team should be using the existing designs to make changes to incorporate your new requirements. Some of the companies don’t create both the wireframes and visual designs, they might just create wireframes or visual designs, you should make sure to get whatever has been created. You should also download the design files and keep them in your own system.
6. Have your current team compile the code and demo the application
You should have your current team compile your source code to build the application and demo it to you to make sure the application is performing the way it is supposed to be. This will also ensure that there is no difference between the source code and the application build. If you have the compiled code and correct application build, it will make it easier for your new team to review the source code and build to understand the current state of the project.
7. Capture all the credentials
You might have several credentials that are being used in your project, you should make sure that you have all the credentials with you so that you can easily share the information with your new team. Here are some of the examples:
Hosting Credentials: credentials for AWS, Godaddy, rackspace or any other hosting services that you might be using. These credentials are used to access and update your backend systems.
Apple app store: If you have published an iPhone App, you will need credentials to access the apple developer account.
Google Play store: If you have published an Android App, you will need credentials to access the Android developer account.
WordPress Credentials: If you have a marketing website built in WordPress or any other CMS, make sure to have admin credentials and hosting credentials for the wordpress website.
Third Party Credentials: Sometimes you integrate your application with third party systems like Paypal, Stripe, Facebook, Twitter, Instagram or any other system. Make sure to get the credentials for all these third party systems.
8. Do the knowledge transfer with the new team
You should set up a call with the existing team and new team so that they can do the proper knowledge transfer. Your new team should make sure that they ask all the technical and project questions, your old team should be providing all the answers in time.
9. Have patience
This is the most important tool you need when transitioning your project from the old team to the new team. This is not something that can happen in a day or a week, transitioning is a process, most of the time, it takes a few weeks to transition the project. You should make sure that the new team has everything that is needed for them to be successful.