What do you do when it all goes wrong? I regularly hear from people who have taken the bargain basement route to app development, and are now stuck with a bargain basement app – an app which looks bad, is unresponsive, regularly freezes, or even crashes when it is used.
Sometimes these problems don’t show up until the app has been released. Performance problems often don’t manifest until your system has stored a significant amount of data, leading to a frightful scenario in which just as your iPhone App or Android App is taking off, gaining market share, it suddenly all falls apart.
Note I am not suggesting all offshore developers provide poor quality work. Some offshore developers provide an excellent service. But bad developers who cut corners are often very good at presentation – its the main focus of their business. And relationships with good developers can take a wrong turn, a situation which sometimes takes expert assistance to correct.
The following is a list of steps you can take to minimise the risk.
- Make sure you possess a working copy of the mobile app source code
Whoever controls your source code controls your app. The source code is human readable form of your app, which development software uses to construct app binaries, for deployment either to test devices, or to the app store or play store. Without the source code, you cannot make changes to the app, or fix problems. A lot of developers keep hold of the source code, to force clients to continue to use their service.It is normal for developers to hold onto the source code until they are paid. But you must insist on source code whenever you make a payment, and you must check that the source code you receive is actually the code for your app. Often the source code is broken or incomplete. This is not necessarily malicious, it can be due to carelessness, or even just an honest mistake. If necessary, enlist the help of a technical friend to make sure you are receiving the real thing.
- Control the Server
A second practice I see all too often is where the developer controls the server. The main use of app servers is to share data between different copies of the mobile app. Copies of the app on different phones can’t talk directly to each other, unless the devices are in close physical proximity. Instead, the apps relay messages via a server. The person who controls your server can shut down your app.The developer may have a positive motivation for controlling the server – server administration can be challenging, and they may feel that by shielding clients from this complexity, they are offering a better service.
But if your developer suddenly decides to start charging exorbitant “server fees”, and if they are unhelpful when you ask for the code to be moved to a different server, there is very little you can do about it, other than a potentially very expensive and disruptive migration to a different server – a migration which can lead to significant loss of client data.
- Hire a local technical manager
If your relationship with offshore developers hits a rocky patch, it can be difficult for non technical people to guide the project back on track – if the offshore developer claims that a simple looking change will take a long time to complete, and be very expensive, how can you tell whether they are being honest or reasonable with you? Some simple looking changes really are difficult – or they might be having a laugh, at your expense. If you have already committed significant money to the project, it can be very difficult to refuse ever increasing charges for changes and bug fixes, to bring your app project to a successful conclusion.With a local technical manager, you are in a much stronger position to negotiate fees. The local technical manager is much more accessible than an offshore team in a foreign jurisdiction. And the right technical manager has extensive experience with software development, so they can push back against unreasonable quotes or other sharp practices.
One of my favourite techniques for handling an offshore fee blowout, is to provide an “example” which proves conclusively that the quote is unreasonable. This generally involves quickly mocking up a proof of concept of the work item under discussion, to discredit exorbitant claims of difficulty or other excuses for excessive fees. It usually only takes one or two “example” exercises to establish a better working relationship. This corrective technique absolutely relies on you, the project owner, having control of your server and your source code.
If you would like to know more about app development, or would like some advice about getting your mobile app project back on track, please Contact me.
