How to salvage a busted app development project

No one likes to think about it. No one expects it to happen. But, it’s a very real risk of any development project — the third party developer you selected isn’t all they made themselves out to be. As is true in more of these engagements than many clients realize, developers will often over promise as to what they can realistically deliver. Sometimes, they promise functionalities or features they’re not capable of delivering in hopes they can freelance or outsource that piece of the project. Other times, they promise “design expertise” when their on-staff designer is an amateur or junior designer at best.

This type of misdirection can come in many forms, but the bottom line is this — in any third party developer engagement, there’s a very real chance your app can’t be built or won’t be built to spec. So how do you protect yourself from this risk?

Know what you own, demand radical transparency, and maintain access to your assets. By that I mean, when you commission a company to build any piece of software for you, you’re not just buying a finished product — you’re buying intellectual property. The code, the design assets, the technical specifications, all the web services, login credentials… you own all that (or at least you should if you’ve drawn up the contract correctly). As such, so long as you maintain control and access to all these things throughout development, if you have to move off-script and bring in someone else to clean up a failed partner’s mess, they’re not starting from scratch.

To prepare you for this unlikely yet unfortunate scenario, though, we’ve come up with a list of assets you’ll need should you have to facilitate a salvage opportunity.

Have to haves:

• Source code for iOS and/or Android app
  • You own the source code — it’s a huge part of what you’re paying for when you hire the developer. You should gain and maintain constant access to the source code should you ever want to reference it, check progress, etc. And in the case that you need to move on from your current developer, you’ll have the most up-to-date code to hand off.
• Source code for web console (if applicable)
  • Same story as the app source code, but for any web console your developer is utilizing if your software solution calls for it.
• Source code for Webservices
  • See above but applied to any and all backend webservices
• Server information
  • Much as you need to maintain access to the source code, so too should you require access to any server information needed to make your software go
• Hosting login
• Login information for the database
• Documentation of the APIs
  • Just as your source code is paramount, so too are the APIs your developer chooses to utilize in service of your app. As such, you need to know not only which APIs are being used, but also how they’re being integrated into the app.
• All design assets for the iOS and/or Android app
  • You definitely don’t want to have to build any code elements from scratch; you also don’t want to have to rebuild any of the design assets if you can help it.
• All design assets for the web console (if applicable)
• Database export with all data (but, if your new developer gains access to this, they can also take care of it)

Nice to haves:

• An ERD export of the database
• Documentation on the web sever
  • For instance, cron jobs, PHP setup, MySQL setup… basically instructions on how to get the server up and running. This is a nice to have; not a must have.
• ERD core data models (if applicable)

I sincerely hope you’re never in a situation requiring full salvage. That said, it’s worth being prepared for such an exigency. It’s also important to know what your rights are and what your assets are so you can maintain access and ownership thereof throughout the entire process. As such, make sure you stipulate, control and track these things as your developer develops your app; that way, you always have a fallback option should the worst happen.