kurdt_the_goat — 2010-04-07T00:09:10-04:00 — #1
I'm talking about FTP, SVN or similar - access to a clients website files.
Either the client themselves (penny pinchers!) wants to modify the site, or they've contracted some other developers (again with the penny pinching!) to do some additional work on the site.
How do you deal with it? Do you disallow other people access to sites you've developed? Do you reluctantly agree? If so, how do you circumvent issues that arise with multiple people working on the same site?
kohoutek — 2010-04-07T00:20:50-04:00 — #2
I give trusted clients access to the SVN repository. I don't give clients access to my server, however.
My scenario might not be applicable to the question you raise though as I never host clients' websites.
I develop websites on my development server. During the development process they have access to the demo site but they don't get access to manipulate files themselves during the development period.
I do get access to most of my clients' servers, however.
As for having multiple people working on the same site, I and the programmers use SVN for it.
cranial_bore — 2010-04-07T00:49:23-04:00 — #3
Do you reluctantly agree?
Why the reluctance? If it's a site in progress I might have practical concerns about an outside developer also working on it, but if it's been launched as is basically "finished" it's the clients business.
kurdt_the_goat — 2010-04-07T01:06:23-04:00 — #4
Reluctance because you'd ideally like to be the sole developer and retain the client for many years to come, not have to work with a third party etc.
spaceman — 2010-04-07T01:16:40-04:00 — #5
Whilst penny pinching may be a factor, it not be the main reason, or it may not be a reason at all. There are many other possible reasons. But it's still their site (assuming all outstanding bills are paid) to do with as they please - including stuff it up, accidentally or intentionally - if they so choose.
So just because a client wants access to their own finished site via FTP doesn't automatically mean they're cheapskates, and to deny this request on the grounds that "only we are capable of safeguarding the integrity of your code" is not practical/realistic.
spaceman — 2010-04-07T01:19:34-04:00 — #6
Smells like vendor lock-in. Fantastic (for profitability) if you can get away with it without annoying the client.
leon_nk — 2010-04-07T08:18:11-04:00 — #7
If you approach this as a normal, professional, business deal - i.e. client pays for a product (website), that product becomes their property to do whatever with. Fair enough they own the code/design/files.
However, I have in the past done quite a few pieces of "portfolio-boosting/experience-gaining" work - i.e. I sell a client a website for a knock-down rate.
In these instances I would not give out file-access. Part of the reasons for performing the work for so cheap was to
a) have work on my portfolio, this would be in jeopardy if I allowed others to use my work (when would it stop becoming "my work"?)
b) In hope for repeat business, should the work be satisfactory to the client.
rustybuddy — 2010-04-07T08:25:31-04:00 — #8
Is the site just a site, or does it come with a service contract?
Either way, this should have been discussed up-front (pre development). Now that the cat's out of the bag, I would say that if you want to possibly retain them as a client you should release the files to them. At this point it may just be a trust building thing for them. But you should attach conditions to this...
I assume you have an hourly rate you charge them for updates/modifications? My approach in the past is this. My normal hourly rate is $XX, if I release these files to you, and you or someone else goes in and makes a mess my hourly rate doubles (or other increase) to fix anything that was broken by the other developer.
Sometimes this opens their eyes to the fact that stuff can go wrong when they let the bosses nephew go in and start working on your finely tuned scripts.
zipperz — 2010-04-07T09:32:50-04:00 — #9
Once my clients pay for the job they usually own the files, they are theirs, if they want to play with them or have someone else make changes they are more then free to do that.
But,,, when they mess stuff up that is all them and I charge to fix it.. I have had cheap clients that think they can make changes and build a site once it is up and the majority of the time they mess up the site..
And sometimes they try to act like they didn't... I hate scammers they get to find another web designer.
I just let people know they can do what ever they want with THEIR files and I can tell if THEY mess them up.
Trapping people into your services is a good way to make people mad.:mad:
awestmoreland — 2010-04-07T10:26:20-04:00 — #10
As falgie pointed out, the issue is support. Unless the client informs you of changes they've made, you'll be updating your local copy and overwriting the files on the server. Not giving the client access saves them money and frustration.
As long as a client understand the risks, I've no problem moving the site to their own hosting and allowing them to tweak as they see fit. I don't give clients access to my hosting though as I believe there may be liability issues for the things they could potentially upload.
wwb_99 — 2010-04-07T11:24:38-04:00 — #11
We don't hire anyone who doesn't use our SVN and QA network and also hand over all files, including vector originals. Its a work for hire and we own the works.
rustybuddy — 2010-04-07T11:30:42-04:00 — #12
But all of this is fully disclosed and understood by all parties involved upfront correct?
What if your developer had created a customized CMS system (while not contracted with you). When you saw his work you wanted to use his/her system. Would you expect them to hand you over all the code for the CMS system?
willisti — 2010-04-07T12:29:13-04:00 — #13
I think it's good practise to provide the client FTP access if they understand the consequences and what could happen if they mess up. We've won a lot of new clients after their existing provider did not grant access and started charging ridiculous rates and letting the client down! Quite a lot of companies like to tie in clients for the long-term and restricting FTP access helps.
dvduval — 2010-04-07T12:33:14-04:00 — #14
I think you will find that setups are different. In our case we require the clients to purchase their own hosting, and we rarely use SVN except in house, though sometimes I think we should use SVN for client jobs too. We've had a couple of cases where the client starts trying to work on the site at the same time as our staff, but the problem hasn't presented itself enough to be a major concern.
joebert — 2010-04-07T15:28:28-04:00 — #15
As long as they understand I'm not responsible for problems related to changes they've made, and that I will charge them for anything I have to do in order to remedy problems related to changes they make, I have no problem with handing over the keys.
I wouldn't build someone a house and refuse to give them a copy of the blueprints in order to persuade them to come back to me if they want to add a deck or something later, I don't know anyone who would either.
awestmoreland — 2010-04-07T15:54:57-04:00 — #16
Several responders to this thread assume the only reason not to give FTP access to the client is a revenue-generating ploy. I think for most it's simply a case of security.
I'm not going to give anyone (client or otherwise) FTP access to my server, but I'll happily set a site up on the client's server where they'll have free reign to change anything they like.
All the "you break it, I charge you to fix it" caveats naturally still apply.
system — 2010-04-07T16:36:36-04:00 — #17
we never give ftp access to anyone even if they ask to pay for file access.
qtronik — 2010-04-07T20:13:41-04:00 — #18
Hey my first english message here, so understand my poor English.
I let ftp access to restricted docs on my clients websites only for uploading big files for his websites, like my deejay client who want to give free big download of is mixes on his site. That save me alot of downloads and upload via e-mail or data cd burnings.
Same things for the mensual photograf of collection group clients.
I don't alow coding. Too mush headache on poor clients try...
scross — 2010-04-07T21:44:22-04:00 — #19
As much as we want to be able to protect our work, we need to make sure we use contracts to state what the client is actually paying for, e.g. are they paying for the entire site (code and all) or are they only buying an aesthetic where they then must come back to the designer when changes need to be made? It must be clear.
Personally, I don't like clients being able to have access to files via ftp, too much can go wrong.
stikkybubble — 2010-04-08T05:09:31-04:00 — #20
I always assumed that when someone pays for a website, it's complete with ftp etc. It seems that it's not as unusual as I thought for clients' websites to be hosted on the web designer's server. I have done that with a few cheap sites I've done for locals and was worrying about ftp/access to the control panel, as I don't see how I can allow that without serious privacy issues (they could access databases belonging to other people). However it also sounds as though some people don't give ftp access to complete, separate sites. That does seem stingy to me, even though I understand the 'they might mess it up' factor. Surely it's better to warn them that you'll charge to fix it, and perhaps have a maintenance agreement? Not every client can be a complete clutz, surely? The last time I was asked about this it was another developer wanting to make sure that they could "change titles and stuff" after the design was complete (in perpetuity).*
I don't necessarily have a firm opinion on this, I'm interested like the original poster was in knowing what the standard practice is, and why.
*I told them they would need to ask the client for the server password, and thought they were very strange asking this! Now I know better!
next page →