6 ms·

The biggest mistake I made when I started freelancing is I had NO plan on how to take care of maintenance after I closed up shop. Websites are living business

The biggest mistake I made when I started freelancing is I had NO plan on how to take care of maintenance after I closed up shop. Websites are living business cards that are almost always changing. So when you take on 5 projects over a year. You're never really going to get away from them. They are perpetual. You will always get calls later on about "fixing this" and "changing that". And if you think you can simply give the client all the code so they can go on to someone else, it's not that easy. Especially if you're hosting everything for them (which I now understand is a big mistake). Clients don't understand code well enough to be able to do that, and the changes they need are sometimes so vital to their business, you'd feel like an asshole for not giving in. Sure you can charge them for the changes but again: If you get busy later on in life you'll always be haunted by your former clients. It's hard to let go. Learn from my stupid mistake. Before you even create index.php create a plan on what you're going to do when you get sick of freelancing. Set everything up around the idea that one day you will need to pass this all onto someone else.

jiggy2011 14y ago
Could you not build up a network of people who you would trust to do a decent job of maintaining the website after you moved on? Then recommend these others to clients if the need arises. I know some developers will offer "understudy" type services where the code is always available to at least 2 developers. One will do the majority of the work and the second will simply look at changes incase they need to take over.
goostavos 14y ago
How do you handle that sort of thing? Is there a cut-off or something? I've never done any web development, but I can see how this would be a hairy situation.
- damoncali 14y ago
  You put it in your contract - it should be crystal clear. If at some point, you don't want to continue (i.e. extend your contract), just refer them to another developer. It's not that big a deal.
  - ChrisNorstrom 14y ago
    Oh it's quiet a big deal when you're not set up for it from the beginning, and it costs you time and money to transfer your client to another developer. When you handled everything for your client from domain registration to hosting to ftp and email accounts and some of the scripts require relative URLs (relative to your hosting account's directory on your hosting company's server) and their mysql databases are with you. Surprise! You've got a few hours to a few days of work ahead of you. Sure you can charge the client. But again, if you're sick of that shit you can't just ditch them. If the other developer wants to do it, they can't because there's no way you'd give them admin access to your server. And since you're on a shared hosting server you don't have the privileges to create a temporary admin account that only allows access to the things that need to be transferred. You're stuck doing all this work. If you want to get rid of the client you now have to oversee that all these things are successfully transferred. And no one can do this but YOU. The more complex the client's site the more of a pain in the ass things become. Things add up quickly. Oh, Just a few things you need to do. :) - make backups of absolutely everything - Transfer the domain (up to 7 days) - Setup and reteach the client their ftp details - transfer email accounts and if they have an IMAP account, have fun backing up all their emails and attachments and transferring them to the new IMAP acount. Same applies to an archiving POP3 email account. - Go into all 3rd party scripts and reinstall everything - change all relative paths on all of those 3rd party scripts as well as changing the mysql details (some scripts aren't simple "drag and drop then reinstall" scripts) they are instead a pain in the ass to migrate because certain options aren't stored in the mysql database that you just backed up. Instead they're in the filesystem and you have to back that up and drag and drop everything over, and if you re-install it you lose all those settings so you have to spend a whole day planning out what exactly needs to be dragged and dropped over. - transfer all backups little by little to their new destination - transfer over all the mysql databases - RE-train your client to understand ALL of these new changes and answer any support emails when they have problems or something is wrong. (NO they won't send emails to the new developer, they'll send them to you) - Answer emails from the new developer who doesn't understand exactly how everything was done. And a lot of this requires everything at the other host to be somewhat setup, which requires a bit of cooperation between you and the new developer. And when it takes most people 5 days to respond to an email because they're overloaded with work (something I'm guilty of right now). A complete transfer after ironing out all the kinks could take over a month. If you were smart and planned ahead you would have just created a whole self contained account with a host and had everything wrapped up together so when you transfer your client to a new developer you just hand the new developer the admin username and password to the control panel and leave. But you didn't. You're Chris Norstrom and you're new to this crap and so you did things the wrong and long way. ;)
cageface 14y ago
This is one of the biggest reasons I've decided to focus on native apps. No server to maintain.
danssig 14y ago
But on the other hand, you've created customers that are practically guaranteed to produce repeat business dollars.

jiggy2011 14y ago

Could you not build up a network of people who you would trust to do a decent job of maintaining the website after you moved on? Then recommend these others to clients if the need arises. I know some developers will offer "understudy" type services where the code is always available to at least 2 developers. One will do the majority of the work and the second will simply look at changes incase they need to take over.

goostavos 14y ago

How do you handle that sort of thing? Is there a cut-off or something? I've never done any web development, but I can see how this would be a hairy situation.

damoncali 14y ago
You put it in your contract - it should be crystal clear. If at some point, you don't want to continue (i.e. extend your contract), just refer them to another developer. It's not that big a deal.
- ChrisNorstrom 14y ago
  Oh it's quiet a big deal when you're not set up for it from the beginning, and it costs you time and money to transfer your client to another developer. When you handled everything for your client from domain registration to hosting to ftp and email accounts and some of the scripts require relative URLs (relative to your hosting account's directory on your hosting company's server) and their mysql databases are with you. Surprise! You've got a few hours to a few days of work ahead of you. Sure you can charge the client. But again, if you're sick of that shit you can't just ditch them. If the other developer wants to do it, they can't because there's no way you'd give them admin access to your server. And since you're on a shared hosting server you don't have the privileges to create a temporary admin account that only allows access to the things that need to be transferred. You're stuck doing all this work. If you want to get rid of the client you now have to oversee that all these things are successfully transferred. And no one can do this but YOU. The more complex the client's site the more of a pain in the ass things become. Things add up quickly. Oh, Just a few things you need to do. :) - make backups of absolutely everything - Transfer the domain (up to 7 days) - Setup and reteach the client their ftp details - transfer email accounts and if they have an IMAP account, have fun backing up all their emails and attachments and transferring them to the new IMAP acount. Same applies to an archiving POP3 email account. - Go into all 3rd party scripts and reinstall everything - change all relative paths on all of those 3rd party scripts as well as changing the mysql details (some scripts aren't simple "drag and drop then reinstall" scripts) they are instead a pain in the ass to migrate because certain options aren't stored in the mysql database that you just backed up. Instead they're in the filesystem and you have to back that up and drag and drop everything over, and if you re-install it you lose all those settings so you have to spend a whole day planning out what exactly needs to be dragged and dropped over. - transfer all backups little by little to their new destination - transfer over all the mysql databases - RE-train your client to understand ALL of these new changes and answer any support emails when they have problems or something is wrong. (NO they won't send emails to the new developer, they'll send them to you) - Answer emails from the new developer who doesn't understand exactly how everything was done. And a lot of this requires everything at the other host to be somewhat setup, which requires a bit of cooperation between you and the new developer. And when it takes most people 5 days to respond to an email because they're overloaded with work (something I'm guilty of right now). A complete transfer after ironing out all the kinks could take over a month. If you were smart and planned ahead you would have just created a whole self contained account with a host and had everything wrapped up together so when you transfer your client to a new developer you just hand the new developer the admin username and password to the control panel and leave. But you didn't. You're Chris Norstrom and you're new to this crap and so you did things the wrong and long way. ;)

cageface 14y ago

This is one of the biggest reasons I've decided to focus on native apps. No server to maintain.

danssig 14y ago

But on the other hand, you've created customers that are practically guaranteed to produce repeat business dollars.