For any given app, there is usually two parts that needs to be done. First, the actual App code inside C or Java. Second, the connection to a web-based data storage through a web service or an API. There can be apps which do not rely on any database to maintain state or load fresh data. But this usually holds true for most mobile apps.
Recently, we have had to share our Mobile app development with a client who already had a database (and a working website) and wanted us to take care of the mobile apps. All in the same time, the client had retained the original developers to work on API in parallel. Though it looks innocuous on paper, in reality there were a lot of logistical issues that sprung upon us in subsequent months.
Here I am going to discuss issues generic to this scenario. This article was written with software work sharing between development companies. If you are working with a freelancer then that opens up a whole new can of worms. These may not all apply to you but its better to be aware.
1. Lack of Communication and misunderstanding
If there are more than one companies involved in a work process, there is always a chance that there is miscommunication or lack of understanding of each other’s point of views. One company maybe using Jira while the other maybe using the Trello. Both companies will be probably be maintaining their own task lists and will have their own priorities. Clients communicate similar information to both parties but the task scheduling can vary.
2. Slow Processing of Requests
With different priorities, companies will look after their own tasks more than that of the other vendor hence creating unseen delays and frustration for client. The developers on both sides will have their tasks of sets of finish and will test scenarios pertaining to their deadlines.
3. Client Preferences and Soft Corner
Its a human nature that we always prefer the ‘known devil’. Similarly in hiring companies for app development, the team relatively unknown will take a bit of getting used to by the client. Its only natural to shift all the blame to the new guy and something that may cause the friction during app development.
4. Product Quality
With two teams involved, there is a chance that client may judge one against the other and mental images will create in the her mind about one team being better than the other. This may not necessarily be the case as teams maybe used to a certain way of development and could provide reasons behind their choices.
5. Adherence of Deadline
Deadline always suffers as there are parts of app development you cannot control and hence are susceptible to scope creep.
6. Mobile App Optimization
Again two sets of software need to be in coherence for them to work and if both sides of such project are being developed parallel then its possible that neither company has gotten the time to optimize their source code. Without a vocal project leader, there may arise scenarios about app speed and security optimizations.
7. Taking Responsibility
During such situation, it may become difficult to pinpoint the party at fault and client may become ping pong between the two vendors. It can happen in case of mismatching data types or API documentation or database versioning.
Lessons to Learn
Here are a few things we found that will help if such a scenario ever befalls you as a client.
Appoint Project Leader
In such cases, always appoint a project leader that is acceptable and respected by both parties. The project leader must be a technical resource that is able to handle affairs without prejudice or pressure.
Delay One Side
If possible delay one area of the mobile app until the other party is finished hence creating a strong base to build upon.
Provide Documentation
Both parties must be asked to document the code and product to a reasonable degree with focus on data types and standards for the other team to be able to read.
Apart from these, its still better if possible to give the whole work project to one team and hire a mobile app development company to take care of APIs and web side of things as well. If you have any stories to share, give a comment below.
