If you ever hire a web developer, there will normally come a point where you need to provide administrative access to your host or back-end website administrative section. It’s all part of the process when you work with people like me who develop websites for a living. I routinely need admin access to WordPress to make things happen for my clients. Sometimes I need to access the hosting account. Sometimes both, and sometimes neither. It all depends on what you’re asking your web developer to do.
First time web entrepreneurs might find the request for the “keys to kingdom” a bit startling at first. Those that are a little more seasoned using web developers might find themselves in a bit of a mental quandary as to exactly what is appropriate to share, and what isn’t.
Fortunately, there are ways that we can share credentials and help reduce the amount of vulnerability that might be felt. Here are some ideas to help you understand how this usually plays out.
Before you hand over the keys, make sure you trust them
Trust is something that, to me, is earned. There are unscrupulous people in the world whom given the chance, will wreak havoc on your life, so unfortunately, people are hesitant to trust developers initially. When push comes to shove though, and you need to provide someone access to a vital system, you should already trust the other party to some degree.
Trust can be obtained in a variety of ways.
- Time and experience with the other party will build that trust. After working on a project together or just having known the person for some time can provide enough trust required.
- Research the web developer. Find out from past clients what their experience was like working with the developer. This should be pretty easy to do. The web developer site should also have some testimonials or something similar to help new clients determine if the prospective web developer is trustworthy or not.
- Trust your gut instinct. Like fruit, if it smells bad, you don’t put it mouth to see if it tastes bad also! You throw it away and find better fruit. Same is true with people that perform services for others. If you can’t trust them with the things they need to do the job, why are you using them?
You should always feel comfortable enough to share your information with someone that is presumably trying to help you out.
When that trust is there, and you’re ready to start that development project, here are 3 ways that you ensure that providing your password doesn’t have long term worrying effects.
1. Create a new username and password for the developer
Perhaps the easiest way to protect yourself, and still provide enough access for a web developer to do what they need to do, is to create a unique username and password. The web developer can use the supplied credentials to do their thing, and when all is said and done, you can simply change the password, disable the account, or delete it entirely. If you feel that you might ask for more work later on, disabling or changing the password is probably easier so you don’t have to recreate everything.
While the web developer still has access to your site, and can still do some damage if they wanted to. Trust will always be in play.
2. Change your password during development
Can’t create a new user but you need to supply credentials to the web developer? No worries. All systems that you use should provide the ability to change your password. Another option you have is to change your password prior to starting work, and then provide the web developer the modified credentials. This gives the web developer what they need to get work done, but also does not leak to them your original password. When the work is done, you can change your password back to its original text, or change it to something entirely different.
What you don’t want to do is to provide a password that you use on more than just the site being developed! People are creatures of habit, and I’m sure many of you out there use the exact same password for your Twitter, email and other accounts. By modifying your password for the systems that the developer will be using, you are helping to protect yourself from possible problems.
Important! You wouldn’t want to change a password that is used by other processes. That could be bad, potentially. For instance, you wouldn’t want to change the password used to access your database, unless you change the values in the website as well. Not doing so could bring down your website. Make sure you understand exactly what’s being affected by the change before making the change!
3. Don’t share your password at all
Maybe you don’t want to share your password at all. While its possible to build a website without having access to a production server, it does complicate the issue. Web sites can usually be built in their entirety on a desktop or laptop and then deployed to a production server later on, when all is said and done. If you decide that you don’t want to share your password nor provide access to the systems required for the project, the web developer will then have to perform all their work locally on their desktop or laptop. Expect to be more involved with the process though. There are times when the developer will need information, data or files that just can’t be obtained without those credentials.
I usually don’t meet many people that want me to develop a site for them who also have the ability to install and configure it when I pass all the files over to them. Those people are usually able to develop a site themselves as well, so they normally don’t need someone like me. But in the case where trust might be an issue, you might have the individual build the website, and then use another developer that you do trust to perform the installation and configuration.
As you can see, while this option might be the best security for you, it’s also producing many obstacles that will need to be overcome. The amount of time required for the site to reach production mode will be increased, and not to mention that there might be additional costs incurred by the web developer having to establish a mock site on their local computer for development.
The bottom line is trust
The bottom line here is trust. If you don’t trust your web developer, why are you even considering them? Any web developer worth their salt is going to help you feel comfortable, and ultimately prove to you that you can trust them. At the end of the day though, you should keep your username and password safe from others, but sometimes you do need to share your credentials to get stuff done.
How I operate
As a web developer, I usually need to ask for credentials to my client systems. I remember a long time ago when I was handling some of my very first clients how awkward it felt to ask for the administrative username and password to someone’s website. Its ingrained in all our minds to keep them safe and to never give them away, and here I was asking for the keys to their digital kingdom. It took me a little time to get comfortable with the idea, but this experience helps me to understand where others are coming from, hence how these options have come about.
If you and I ever work with each other, I will ask you for access to your systems if and when I need them. Don’t ever just provide me the keys to your kingdom; allow me to ask for them first. I want to make sure that you feel comfortable enough, and I with you before sharing sensitive information.
When I do ask, don’t let it come as a shock to you since I do need these things to do what I need to do. The ideas above are great ways to maintain a little control if you feel you need that control, so use them to your advantage. To do what I do, I don’t necessarily need access to your hosting account, nor your backed WordPress administration to perform web development services, but it does help speed things along when I do have access.
Having a web developer deploy the changes however will always require that credentials be provided.
Have some additional ideas?
How did you feel the first time sharing your username and password with someone? Have some ideas that you would like to add?
Let me know in the comments below. Thanks for reading.