I'd like to share some words on why site owners might not want to hire freelance developers for support. (Nothing personal, freelancers. It's strictly business.) Many will agree, some will disagree—share comments if you'd like.
When someone moves to hire freelance developers for support, they're hoping for the best. The real scary stuff happens when they don't plan for the worst, but let's be optimistic. After the project is finished, it looks great, site owners are happy, user flow feels good, etc. Now it's time for website support and maintenance options. The freelancers you contracted with have agreed to a support contract for the next year. But more often than not, a hired freelancer doesn't work out like this.
To be fair to them, hiring freelancers for development is fine overall. Small businesses owners with small websites, without the means to contract long-term with a development agency, sometimes turn to sites like: Upwork.com, Freelancer.com, and even Rent-acoder.com. While pulling talent from sites like these can work out there are some projects, like support, where this just isn't advisable.
When we focus in on support and maintenance, we're usually focusing in on long-term projects. And it's not that freelancers don't try, but they always have new projects pulling them away. And we've found that there are many other reasons why they aren't right for support.
Reasons like the reality of hired freelance developers now handling support requests as quickly as site owners would like. And another one: if the lead developer is on vacation, it might be necessary to wait a week or two—there's no replacement. These are just the obvious. After a year, you both realize it hasn't gone well. You drop the support contract with the freelancers. Now it's time to find someone else again.
Think Twice: Don't Hire Freelance Developers for Support
The short answer is this: freelance developers are usually short-term and project-oriented rather than support-oriented. This isn't even considering tools, best practices, development processes—all things freelancers are called into question about.
But let's look in more detail at the difference between choices. We'll understand not only why an option like process-oriented support is better, but what freelancers can do to create a smooth transition if you're working with them currently.
Development projects are like a story. A short-term development project is like a story. It has a beginning, a coherent sequence of events, and an ending—either good or bad. Like most stories, there are moments of great anxiety, perhaps some serious misunderstandings, but in the end everything is supposed to come together.
But a website is never really over? There isn't a definitive end when it comes to websites. It's not about getting to a definite goal; it's continuous. To put it in more prosaic terms, the freelancer's business is goal-driven. It's successful when it delivers the product which the client wants. A big part of what drives the individual developer is the challenge and the prospect of finishing the job.
Support and maintenance projects are different. It's not that they require less effort or imagination, but it's an ongoing relationship rather than a process with a definite beginning and end. Most days nothing unusual will happen. There will be straightforward requests to update features or make changes. Every now and then, though, there will be an emergency, and the maintenance team needs to get up to full speed quickly.
Two Business Models
Many times a freelance developer's income stream is unpredictable. One month might bring lots of work, only to be followed by a dry spell. This means a developer is reluctant to turn down new business, even if during busy times. The income needs to be enough to last through the slow times.
When the developer is heavily loaded with deadlines, something has to give. It's most likely to be the work that doesn't have deadlines, such as maintenance agreements. During the slow times, a freelance developer can be very helpful and may even offer extras. These times don't usually come at the client's convenience, though.
The economic model for a support organization is steady. The agency keeps on as many clients as it can deliver quality service to, and its workload is less prone to feast-or-famine situations. It will have periods when urgent issues arise, and occasionally more than one emergency at a time will turn up.
The Transition: How Hired Freelancers Help
If we approach a contract with the understanding that another organization will provide long-term support, the developer will be relieved rather than disappointed. We should be clear, though: The developer should provide short-term support and be responsible for fixing bugs. That's part of the obligation to meet the client's requirements. Long-term support means system maintenance, routine upgrades of supporting software, taking action when things go wrong, and so on.
The development contract should require not just a working product but thorough documentation. An undocumented product is a nightmare to maintain. It's bad enough when the developer has to come back to it later; it's still worse when someone else has to understand it well enough to deal with problems.
One of the best things freelance developers can do before transition: be available for consultation. This doesn't guarantee anything; a year later their recollection of what they did could be foggy. Still, they'll usually be able to explain why they made key decisions and that can help the support team to understand the best approach to any needed changes.
The right division of labor will produce the best results for a website—both in the development phase and in the subsequent maintenance. A coordinated transition will make it easier to deal with future maintenance and changes.
The Best of Both Worlds
Coordinating a freelance developer and a separate support company can be tricky. Oftentimes it's just easier to deal with a company that has both development and support teams. Then the contract is all with one company, and the support people can easily ask the developers whatever questions they have.
We can explore alternative views later: like why there might be an even stronger argument to be made against staying with the agency that developed your site. There are plenty of reasons why choosing a different support organization post-development makes a lot of sense. We'll get into that soon.