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.
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.