The app industry is still relatively young. Not everyone is aware yet of the best practices in our industry and not every app agency has a code of conduct or moral compass when developing apps for clients. In the past couple of years we have run into several occasions where someone had an app developed by an agency and fell into the trap of ‘vendor lock-in’ – they were stuck with the vendor that built their app, they had to pay a lot to be able to take ownership of their own app or in some cases had to rewrite their app from scratch just to switch vendors.

To help companies avoid painful and costly vendor switches, I will describe a few obvious and a few not so obvious ways a vendor can lock you in.

The most obvious way for a vendor to achieve lock-in is to retain ownership of the app’s code. They give you a license to use the app but they remain the owner. This means that you pay for an app but it’s never really yours. As long as you are happy with your vendor that is not a problem. But companies change, relationships change, and at some point you may want to move to a different supplier. If you don’t own your app, you can’t take your app with you and you have to start all over. Avoid this trap by requiring transfer of ownership/copyrights to you. Some vendors may tie this transfer to you having fulfilled your financial obligations (we do so at Egeniq) — that’s fine, but make sure once the bills are paid, the app is yours.

A couple of years ago software ‘escrow’ was pretty popular; it allowed vendors to keep ownership of the code, while guaranteeing to a client that if the vendor would go under, the code would become available. This sounds safe, and escrow services are still available, but I’m not a fan; it is much more likely that you want to switch vendors for other reasons than them going out of business, and in such cases escrow generally has no solution.

When you are ready to publish your app, make sure you publish it in your own Apple or Google account. Getting an account and managing it can be cumbersome, and it’s fine if your vendor helps you do it or does it for you, but the account should be yours. If your vendor thought it might be easier for you to publish under their account, you might run into issues when switching vendors. Nowadays it’s possible to move an app between accounts, but only if both account owners cooperate.

A little less obvious and harder to avoid is lock-in by use of components or libraries. A vendor might have some off the shelf components that reduce the cost of development, but what happens if you decide to switch vendors? Would you have to stop using their software or would you have to start paying a license fee? You could avoid this by asking the vendor to not use such libraries in the first place, but that means more bespoke development and higher cost.

Some vendors open source their shared libraries and then it’s less of a problem, but if not, at least be aware of the consequences down the line.

It’s easier to replace a library than an entire app, but it can still be costly.

This type of lock-in isn’t common but I’ve still encountered it in the field. A vendor had built an app on top of a customers backend system but not directly; they had written a layer in between the app and the backend, hosted on their servers. This wasn’t with bad intent; the vendor had successfully reduced cost by abstracting the complex backend away from the app, and wanted to avoid discussions with the IT department so they hosted it on their own servers. But when the customer decided to move away from that vendor, the IT department didn’t want to host the unsupported software and they now had to pay the original developer for hosting and maintaining the intermediary API.

In situations like this there’s a trade-off between short term cost reduction and longer term maintenance cost. If you find yourself in such a situation, try to get IT on board; ideally an intermediary API (which is a good idea in and of itself) is hosted and supported by your existing backend team. If that’s not possible, make agreements up front with the vendor about what should happen if you decide to part ways later.

Lack of knowledge about an app can make it hard for a new vendor to take over. This doesn’t mean you have to learn about app development, but you can request a vendor to properly document their code, adhere to standards and follow best practices.

You can also add a clause to your contracts that a vendor should cooperate in transferring knowledge to the best of their abilities (at your cost). This might mean there’s some cost involved down the line, but it can smoothen the transition.

I’ve highlighted some ways in which vendor lock-in can occur. When commissioning an app, I hope this will help you avoid some pitfalls, or at least I’ve given you some points to discuss with your vendor. When I’m talking to a potential client about this subject I tend to say ‘I hope you stay with us because you are happy with what we do, not because you’re stuck with us’, but not every app vendor is that confident and may feel a need to give you an ‘incentive to stay’. It’s not always a problem, as long as you are aware of the (longer term) consequences.