Robert Beerworth Team : Web Strategy Tags : Web Design Web Strategy

You can't move from your web developer

Robert Beerworth Team : Web Strategy Tags : Web Design Web Strategy

Unless you have a very simple, static website, chances are you are stuck with your web developer.

Despite what many people think, the reality of the matter is that websites are not transferrable, and you cannot pack-up and go to another web developer when you've tired of the first.

There are plenty of instances when this is not the case – especially around highly standardised technologies such as WordPress – though even then, the website and its functionality needs to be standardised, and pretty much vanilla, out of the box.

Let me explain.

Wipe away the tears

It is very difficult for a client to do any real due diligence into a web developer. After all, what do you look for?

Web developers typically look great on the surface and without going through the website development process, how can you know what the web developer is really like to deal with.

In any event, if the shit hits the fan, you can always move your website away right?

In reality, probably not.

The number of terrible phone calls I have with people who have reached rock-bottom with their web developer is depressing.

In my experience, there are only a few usual suspect reasons for this:

• The project is massively delayed, and the web developer is simply not moving fast enough.
• The website is not what they expected. The web developer can't get the technology to do what they promised.
• The web developer has seemingly given up.
• The client service and communication is horrendous.

So why can't you leave?

Unfortunately, there are more than a couple, 'usual suspect' reasons for this. For purposes of keeping this blog reasonably short, I've listed only the top reasons.

And before going into them, take my strongest advice. Optimism and the 'this won't happen to me' attitude are great, though in most instances, this will happen to you.

Prevention is far better than cure and you are best advised to spend longer investigating the web developer and talking to their existing clients, than trying to extract yourself from a messy marriage, 6 months down the track.

And so the reasons you’re likely not leaving your web developer:

• The technology cannot be practically transferred.

In my experience, this is one of the biggest culprits. At Wiliam, we simply will not take over the code of other web developers. No ifs, buts or maybes.

It is just too high a risk.

Every web developer has their own way of coding, and rarely is the code clean, standard and documented; the developer might be a great developer, though they're not coding with the view that their code will be sent away for others to take over.

There is just not enough time.

To this extent, I'd hazard to say that most code is atrocious and it is very difficult for another developer to take it over, and keep developing.

Moreover, without proper documentation (which rarely exists), it is difficult for the new web developer to know how the website/application has been built, or why it has been built that way.

Make a change over here, and something else breaks over there.


Who knows, except the original developer?

Wiliam's blanket attitude to taking over other code comes from a fairly recent and awful experience where we agreed to take over a classic ASP website, and to make changes and upgrades to it.

I can only take responsibility for not doing more due-diligence into the code and the project was an absolute disaster. We lost a lot of money, the client hates us and although we finally managed to get all of the changes made and uploaded, we were bruised and battered for it.

The code we inherited was unbelievably bad, though unfortunately, you needed to scratch below the surface to see that.

I think the client understood that we were genuinely and honestly trying to work in a terrible situation, though they were understandably angry. Maybe that they bought a lemon, maybe that we couldn't get it to work... either way.

• Licensing.

An oldie, but a goldie. The CMS license...

Every second web developer has their own CMS (Content Management System) technology. If the web developer's name is 'Ghost', the CMS will be called 'GhostCMS' and so forth.

In 99 out of 100 instances, there is nothing clever or proprietary about the technology. Suffice to say, it is probably pretty average. Only Google has magical code, not some small web agency in Redfern, Sydney.

Anyway, clients are usually unaware that the web developer has a bullshit license that effectively stonewalls any chance of the client making a break for it.

Indeed, many smaller web developers have the CMS license as the basis of their client retention strategy! Seriously, they lock the client in and the client can’t leave!

(My view is that you service the client well and they'll stick around, though that is another story...!)

At Wiliam, out attitude is that the client owns everything and is entitled to everything, source files and all. If the client leaves, we can't blame them and we certainly shouldn't penalise them.

• Source files and 'source files'.

As a quick clarification, source files are not necessarily source files.

What do I mean by this?

If your website is developed in a technology such as Microsoft's .NET, the source files on the web server are not the same files that a web developer needs to build the website.

The files on the web server are compiled, meaning that they cannot be edited, or not at least without great difficulty.

It is true that under most agreements, you are buying the website but not also the right to have the original, uncompiled source files... You think you’re clever because you’ve managed to lock the web developer out of your server, though you don’t have zip.

When entering into a web development contract, ensure that you are also receiving the source code, including all relevant CMS source-code and whatever else is needed to allow you to walk away.

(Even then, you still run into the technology/code hurdle I described earlier, but at least you could make a break for it…)

• Centrally-hosted technology.

Some websites are built on a common CMS, shared with many other websites.

For a two grand job, this is arguably fine. For a twenty grand job, it is unacceptable and means that you really are locked to the technology, the CMS and the web developer.

Make sure your website is running independently of any other websites or CMSs or whatever.

I could go on forever. There are so many reasons for why moving away from your web developer is impractical.

Seven times out of ten, they will be trying to stop you from leaving, and let me tell you, web developers can be pretty effective at stopping clients from leaving.

And even if they don't try to stop you, there are so many technical hurdles to jump, it just rarely works.

You'll be spinning wheels for weeks or months as the new web developer tries to make heads or tails of the mess they have inherited. I know this is not always the case and I apologise to all of those that have transferred away successfully.

It is better however that you accept your fate and a long marriage with your web developer, than think the divorce will be short and sweet. You might be one of the lucky ones, though chances are, you won’t.

Last Thought

If you do find yourself running into issues, be pragmatic.

Try to understand from the web developer what is wrong. Document all outstanding tasks and agree deadlines and deliverables.

Agree that you both want to end the project and be friends.

If the project needs a little capitalisation, as long as you're not throwing good money after bad, consider giving the web developer some more dosh.

I know that sounds uncommercial, though projects usually cost more than you budgeted. It is better to complete the website and get the benefit it brings, than to have a deflated and unprofitable project flapping in the wind.

Weeks turn into months pretty quickly. Accept that you made the wrong choice of web developer, grit your teeth and focus on what is needed to get to the finishing line.