Skip to main content

4 Mistakes That May Result In Your Website Being Held Hostage: Part 1

By July 17, 2014February 1st, 2018Website Design & Marketing
4 Mistakes That May Result In Your Website Being Held Hostage: Part 1

Alert! Make sure you stay tuned for my sucker punch at the end of Part 2 next week.

Over the past few months, my company has focused on promoting its branded service offering called Web.Search.Social. In a nutshell, Web.Search.Social targets small and medium sized businesses in the area of web, search and social marketing. We’ve been running a series of cost-saving promotions to entice people to hire us.

The good news is that we’ve closed a bunch of new work. The bad news is that the work has come with some stress. Not for us, but for some of our new customers.

As it turns out, some of our new clients discovered that rebooting their marketing wasn’t so easy because their websites were being held hostage. In some cases, a fee was required to disengage from an old developer. In others an attorney had to be called in. In still others, there was nothing to be done and we had to start from scratch when our customers realized they would never be able to access their original websites again.

Here are the first two of the top four mistakes that I’ve witnessed and how you can avoid them.

You Don’t Know Who Owns Your Domain Name

If you want to buy a car, you go to a car dealership. If you want to buy a domain, you go to a registrar. However, you can’t really buy a domain. It’s more a like a lease for a fixed amount of time. After that time expires, you can renew the domain otherwise it becomes available for anyone to purchase and use.

Registering a domain is a simple process that involves two steps. You pay for the number of years you’d like to have control of the domain and then you enter your corporate information.

This is the first place where things can go haywire.

If a developer is registering a domain on your behalf, he can register it under his corporate name instead of yours. At that point, the domain is his and not yours.

What’s confusing is that it’s not immediately apparent that you don’t own the domain name. Your email will work fine. Your website will work fine. But behind the scenes the domain is someone else’s property.

Almost all of the businesses I speak to believe their domain name is registered to them, but roughly 1 in 4 later discover otherwise.

The easiest way to avoid this headache is to be clear in writing up front about who the domain should be registered to if someone is registering on your behalf.

If your domain is already registered but you aren’t sure who it’s registered to, you can use a tool such as WhoIs to try to find out the registration details. Sometimes the information will be clear and straightforward, but in the case of a private registration, you will not be able to determine the actual registrant.

In the latter scenario, you’ll need to go back to your developer and ask for an accounting of the domain including where it is registered, to whom and when it expires. If your developer refuses to give you this information – or if your developer has mysteriously disappeared and is no longer returning your phone calls – you may be in for trouble.

If you are wondering why this can be bad for your business, here are a few scenarios we’ve seen happen.

  1. The developer may refuse to transfer ownership to you and demand a licensing fee.
  2. The developer may refuse to point the domain to another hosting provider should you choose to move your site.
  3. The developer may neglect to tell you when the domain expires and your domain will go back into the “available” pool where someone else buys it.
  4. If the developer is not on top of his automated renewals or his credit card cannot be authorized, the registrar may opt to put the domain on hold and not issue it back to the market until the matter is resolved.
  5. If your developer disappears without a trace, you may never get access to your domain again and you’ll be left without the ability to update, move or change your site or hosting.

Each of these scenarios are unfortunately common and can be easily avoided with some up front questions about who will be registering the domain and to whom.

You Don’t Know Who Owns Your Website

Whenever we engage a new prospect, I always ask, “Who owns your website?” Unsurprisingly, most people don’t know that there is a possibility that someone else could own their website.

As it turns out there are a lot of marketing companies and developers that don’t work for you using a work-for-hire model where you own your site after you have paid for completed work. Some developers work on a licensing model where they do the work, but retain ownership. They then license exclusive access to you. This is more typical in a scenario where there are recurring fees. Once you stop paying the fees, the website goes away. When you attempt to move the site, the developer asks for a release fee. Sometimes, the developer tells you that you don’t own any part of the site at all, neither design nor content, and if you stop paying the fees or attempt to hire another developer, you will be forced to start over.

It’s kind of like leasing a car. You pay much less for the car in a lease than with a loan, but at the end of the lease, if you want to keep the car, you have to pony up the value of the car. Keep this in mind later when I present my sucker punch.

The simple solution to this is first to ask questions up front so that you know exactly who owns what. Second, and most importantly, you should have a solid contract that is clear and enforceable, because when you…


Did you catch that word? Enforceable.

If you don’t know what that means then you should make it a point to learn. Before we get to that, here’s the paragraph in our standard contract that guarantees that what we produce is the property of our client upon final payment. You can feel free to copy this and demand that your developer include it in their contract.

All of the work we perform is “for hire”. At the conclusion of the project and upon final payment, all deliverables including any materials that we have produced for you will be the sole property of your organization. Ownership does not extend to software or hardware owned and licensed by Rahvalor, including servers or development tools.

Also, note that if you did hire a developer without a contract, that doesn’t mean that you can’t create a new contractual agreement at sometime midstream. You just both have to agree to it. For example, two weeks after your developer has started working on your site, you can say to him, “Hey, you know what? We never signed a contract. We should really do that to protect both of us.” No harm. No foul.

Now back to “enforceable.” Did you ever sue someone? I have. It’s ridiculously hard. Even with a stellar contract. As far as the law is concerned, there’s no right party or wrong party; only enforceable facts. What is enforceable? Anything in your contract. Well, not really everything, but most things. What’s not enforceable? Anything that’s not in your contract. Even then, you may win a judgement, but not gain anything.

Pft. I know, right? I can’t wrap my head around this stuff either.

Here’s the simple version. If you hire a developer for $2,500 with no contract on a simple verbal agreement or an exchange of a few emails, the terms of that agreement aren’t necessarily enforceable. You can sue them. They can sue you. But it’s a coin toss as to who will win a judgement. What is guaranteed is that you will both be out a lot more than 2,500 bucks in legal fees.

Why bother with this nonsense when you can just have a good ‘ol contract up front?

Before I go, I want to touch on one more scenario so I can get the taste of this legal mumbo jumbo out of my mouth.

There is another scenario related to content ownership that is not strictly unethical, but can still sting if you’re not expecting it.

Some developers use proprietary systems to launch and manage websites. While you may own the content that the developer produced, you may not have access to the system or framework. For example, WordPress is a very common website development platform. If Developer A builds you a site in WordPress and you want to move it to Developer B, all you have to do is follow the well documented guidelines for such a transfer. But if Developer A is using an obscure or homegrown system, then you may end up with your content, but not in a useable form to launch as a website.

You need to know this up front and ask for a contingency should you want to move your site to a new developer or a new hosting provider. Always – and I mean always – guarantee yourself that your content and your site is yours.

Part 2

Stick around for part 2 where we’ll discuss two more easily avoidable mistakes and I’ll give you an unexpected sucker punch at the end. Subscribe below to be notified by email when a new post is published.

Join the discussion 3 Comments

  • Gladys Cruz says:

    Hello Sir
    I am a newbie, but I do realize that the domain name HAS to be under the name of your organization.
    Everyone should read this BEFORE they attempt to hire a developer.

    Thank you for a great article.


  • Kriss Morton says:

    I thankfully have had my domain names for years and started off as a developer myself so have not faced this. But as a developer and a reseller, I do have to watch out for my clients. I feel everyone should understand what it means and how it is done and never would do this to a client. It has to be under the name of your organization. Posts like this make it very easy and clear. Looking forward to part two.Also people really need to start taking the time to research the process before diving in. HOMEWORK, when did we forget the lost art of doing it?

  • I’m my own developer so ‘win – win’ : I’m totally looking forward to part 2!