At Itomic we like our clients to stay with us because they want to – not because they have to. Approximately half (and rising) of our website design and development revenues come from repeat business from existing valued customers (thank you!), and we have an extremely high customer retention rate. So we like to think our efforts are paying off in this regard. So how is it possible that you might find yourself ‘having’ to stay with your website development company?
Vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. In relation to websites, ‘substantial switching costs’ typically means the complete rebuilding of your website from scratch with another developer, albeit with some or all of the public-facing content (words and graphics) salvaged from your old site.
So do you ‘own’ your website? You might think you do, but you might not. By ‘own’ we mean that you’re free to take your entire website code and content, in full working order, to another developer to work on, at little or no ‘transfer’ cost. The good news is that the incidence of people not owning their website is almost certainly in decline thanks to the rising use of quality open source software packages such as Drupal. But the ‘bad’ news is that there are many people who don’t know that extent of their current vendor lock-in, and they only find out when they make moves to take their website business elsewhere.
It’s important to make the point that website vendor lock-in isn’t necessarily a ‘malicious’ attempt by a website developer to stop you taking your business elsewhere by making it very costly to do so. As you’ll read below, vendor lock-in might be an (unintended?) side-effect of a couple of methods of building websites, e.g. one that involves the use of proprietary code (and therefore a ‘right’ by the developer to protect their Intellectual Property), or one that can build you a site very rapidly as part of a much bigger system that itself can’t easily/simply be picked up and dropped down with another provider.
This article is not an attempt to ‘bash’ website developers who employ, intentionally or not, vendor lock-in techniques. Rather it’s about informing consumers about these techniques so that owners of existing websites can be better informed, and prospective purchasers of new websites can make smarter decisions. That said, certainly we believe there is an onus of moral/ethical responsibility on the part of the website developer to clearly state ownership rights in their website contracts, just as it’s the responsibility of consumers to read and understand contracts before they sign them.
Types of website vendor lock-in
Your website is actually leased, not owned. The small print of your contract with your website developer says that the ownership of your websites extends as far as the content you’ve put into it (words, images, videos, etc.) and perhaps the graphic design, but not the underlying code. To use a medical analogy – you own the skin, but not the bones. To use a vehicle analogy – you own the body work, but not the engine. In this scenario either your developer won’t allow you full access for you to take your website elsewhere, or you’re allowed but some or all of the code is encrypted (‘protected’) such that another developer will not be able to access the encrypted part and therefore can only support/develop your site to a limited degree. This might sound unreasonable or outrageous on the part of the website developer, but remember that everyone has a right, to a degree, to protect their IP. A web developer’s IP might be what gives him his competitive edge in the marketplace, i.e. he’s spent thousands of hours developing a cutting edge system that a) he wants to get a return on his investment from and b) customers are prepared to pay a premium to get access to. (side note: when you purchase a copy of commercial software such as Microsoft Windows you don’t actually own the code – you’re only leasing it).
This one often goes hand-in-hand with the ‘leased, not owned’ model. Your website (and those of lots of other people) is built as part of a ‘plug-in’ to a much, much bigger system. But, for want of a better phrase, it’s a parasitic relationship because your website cannot live without the ‘host’ system, i.e. it cannot operate as a ‘standalone’ entity. This is actually an extremely scalable method of building and maintaining lots of websites quickly, and some website development companies large and small, local and international, have done very well out of it (and still do). However, as well as the vendor lock-in downside, it can be a quite inflexible system in terms of its ability to be customised to the ‘nth degree to individual customer requirements.
Poor code quality
One of the many benefits of the Internet is that it has made technology hugely more accessible to the masses. But a fool with a tool is still a fool, and there’s no shortage of people who can build websites, but only some of them (through professional training and experience) can build sophisticated websites with good quality, well-documented, robust, easy-to-maintain code. Itomic have inherited websites from other companies where the code – despite being written using technologies that we specialise in – is of such poor quality that maintaining or upgrading it will be so challenging (and therefore time consuming) that the longer term financial interests of the client are better served by re-writing it from scratch. That said, even the most brilliantly designed and written systems will eventually need re-writing. Why? Because technology and business expectations are evolving rapidly over time, and there’s no such thing as a system that can be expected to anticipate all those changes, i.e. be easily adaptable to them, in perpetuity.
So you’ve decided to look for another website developer – but you can’t find one (in your locality) that has genuine expertise in the language your website has been written in. Sure, you’ll always be able to find someone, somewhere in the world who can help (at what price?), but flights overseas or interstate to discuss your requirements face-to-face with your developer are far from ideal for a successful business relationship (never mind the cost). At the risk of incurring the wrath of some fine website developers, I’m going to go out on a limb and state that the two most mainstream – and therefore ‘safest’ – coding languages/frameworks in existence today that your website could be written in are either PHP orASP.NET, and the two most mainstream database technologies are MySQL (which tends partner with PHP) and MSSQL (which tends to partner with ASP.NET). All other languages and databases are less well established on a global scale (either old and dying, or young and yet to gain significant market share – and may never) which means that finding other developers in your locality who support these technologies may or may not be very challenging. Examples of such less well established on a global scale web-building server-side technologies include: Perl, Ruby on Rails, Cold Fusion, Java, and Python. Let’s be clear – there’s nothing ‘wrong’ with these languages for building websites or other software applications. Indeed the world needs ‘early adopter’ developers to give the newer technologies (e.g. Ruby on Rails) a fair go. But if only a handful (or less) of developers in your area have the expertise to support them, this is undeniably a form of vendor lock-in. Getting a little bit more technical… note that there are also mainstream and non-mainstream technical environments in which websites ‘sit’ that might increase or decrease costs moving costs. The two areas to look out for here are your website hostingoperating system (Linux and Windows are the most popular) and web server (open source Apache and Microsoft’s proprietary IIS dominate).
Great quality and service!
This is the sort of vendor lock-in that Itomic aspires to! If vendor lock-in is about a significant cost to your business in changing your website provider, then undeniably changing from a high quality, high service provider to a lower quality, cheaper provider could be a very expensive mistake, i.e. a false economy. If the quality (e.g. design, functionality, reliability) of your website is degraded by the work of the new developer (e.g. that $5/hour overseas out-sourced service) and their service levels are low (or even non-existent) this could prove very damaging to your business.
Unfortunately, it’s usually only when you want to get out of a contract or a supplier/business relationship that you find out the extent of vendor lock-in, i.e. you find out what was in the small print of the contract you signed way back when. Where the web industry ranks in relation to other industries in terms of good/bad practices in this regard we’ve no idea. What we do know is that, regrettably, some businesses feel they’ve been very ‘burnt’ in this regard. They’ve learnt the hard (costly) way. So when they go looking for a new relationship with a website development company they’re rabidly opposed to any vendor lock-in practices (except for the “great quality and service” technique!), and they make this clear to us in no uncertain terms. Typically they insist on open source software with no initial or ongoing license costs or restrictions, and we’re very, very happy to oblige.
If you’re in a current business relationship with a website development company, it might pay you to ask the hard vendor lock-in question today so you know where you stand. And if you’re looking for a new business relationship with a new website company, hopefully you’re now better informed up-front about the issue of vendor lock-in so that you don’t ‘learn the hard way’ like some others who have gone before you.