In the world of web development, particularly open source web development, there are two fundamental requirements that you should ask of any new web development vendor – code isolation and server isolation.  Whenever possible, you must insist that the underlying code that runs your website is isolated and under your control. Likewise, whenever possible you must insist that the underlying server that hosts your website is isolated and under your control.  This is the best way to protect yourself and your investment when the relationship ends.

Protection of the hosting environment

Most websites are hosted by third-party cloud providers.  Amazon, Heroku, Digital Ocean, Google App Engine and Rackspace are just a few of the many hosting providers in the market.  Web vendors make use of these providers to host their client websites.  For convenience, a vendor might spin up a cloud server for your new website within their own cloud account at one of these providers. This gives them, not you, control over the hosting environment.  

Instead, you should establish a separate cloud hosting account in your name.  Your vendor probably has a preferred hosting provider and that's fine. The hosting provider doesn't matter as much as making sure it is your account, not theirs.  You will need to add a credit card to the account and pay for hosting charges, but the vendor was going to charge you for that anyway. This gives you the ability to add vendor users to your hosting account with whatever privileges they need to do their work, but you are the owner and the owner controls the show. Should you need to transition to another vendor, you can remove and add new logins as you see fit.

Most websites require both a web server and a database server.  Often they are on the same cloud server, but sometimes they aren't.  Make sure your account includes both the website and the database.

In certain situations, the vendor doesn't use a third-party host but instead hosts websites on their own servers.  See if they will make an exception for you. 

Protection of the codebase

Like third-party hosting providers, there are also third-party code repositories.  GitHub, GitLab and Bitbucket are three popular examples. Third-party code repositories provide an important set of tools for managing the underlying code of a website.  Similar to hosting providers, many vendors will create a code repository for your website within their own repository account.  

Instead, you should establish a separate repository account in your name, again adding their users with whatever privileges they need.  In this way, the establishment of an independent code repository mirrors the establishment of an independent hosting account, but with a codebase, there are more details that need attention.

The underlying code that runs a website can come together in different ways.  There is drop-in software which does what is needed without modification. Examples are wide ranging, from login managers to entire ecommerce stores.  There is also custom code, which is completely customized for your business and written from the ground up. These two examples represent the two ends of the spectrum with the rights and/or ownership firmly established and clearly understood.

However, in the space between, there exist several options where usage rights and ownership can be murky.  Spaces where software that is fundamental to the functioning of your website may not be yours nor yours to freely use.  A good example of this is vendor-specific code.

Over time, vendors will create ad-hoc software to help run websites.  Perhaps it is their own version of a login manager, or blog or content management system.  This vendor-specific software is often utilized on many - if not all - of the vendor's client sites.

Code repositories anticipate this and provide the option for one repository to link to another - in this case, a link from your repository to the one containing the vendor-specific code. Often this other repository is private, owned by the vendor and requiring special credentials that are not particularly obvious.  But what happens to that link when you want to change vendors? Understanding what private repositories are linked to yours and clarifying what happens when you leave is important. Otherwise, the vendor can sever the link and you’re left with a broken website.

As with all code that is required for your website to operate normally, it is important to clarify usage rights.  There is no better time to do this then when you are reviewing the vendor’s agreement. The gold standard is total independence, meaning the site can run independent of the vendor.  If operating independently from the vendor is not an option, at least you enter the relationship fully informed and eyes open.

Bottom line

No one wants to think of how the relationship may end, but eventually it will. Too often, a website owner is unknowingly tethered to a vendor.  Any prudent business should anticipate an end-of-life scenario up front and protect itself appropriately. A little preparation at the outset can provide important protection when it's time to part ways.