A managed support contract or an individual contractor?
A contractor is usually cheaper by the hour, and a managed support contract is usually cheaper in risk: cover for absence, knowledge that does not leave with one person, and agreed response arrangements. This page is for IT and operations managers whose organisation pays one external contractor to keep an older in-house system running and is weighing up a support contract instead.
| Aspect | An individual contractor | A software company |
|---|---|---|
| Cost per hour and total cost | Usually a lower hourly or daily rate, paid only for the time worked. The total also includes the time your staff spend managing the work, and the cost of any gap when the contractor is unavailable. | Usually a higher cost per hour of work. A monthly fee covers an agreed scope, including cover, monitoring and documentation, with larger changes priced separately. Compare the total over a year, not the rate. |
| Cover for holidays and illness | None, unless the contractor arranges a substitute. A fault during their holiday waits until they are back. | Colleagues who know the system cover absence, so a fault is still dealt with under the agreed terms. |
| Knowledge held by one person | A contractor who has looked after the system for years may know it better than anyone. That knowledge usually sits in their head and on their own machine. | Several people learn the system, and what they learn is written down where your organisation can read it. |
| What happens when they leave | A contractor can end the engagement on the notice in their contract, which is often short. Unless the handover is planned, the next person starts by working out how the system is built and released. | People leave companies too, but the arrangement continues. If the contract itself ends, a written handback should be part of it. |
| Response arrangements | Usually informal: a call or an email, answered when the contractor is free. That can be very quick, but nothing obliges it. | Hours of cover, how to raise a problem and response times by severity are written into the agreement. |
| Security and access control | Often one shared administrator login, sometimes on the contractor's own devices. Removing access when the engagement ends depends on someone knowing every account they hold. | Named accounts for each person, granted and removed through a recorded process. Ask any supplier to show how they do this. |
| Documentation | Varies. A busy contractor who already knows the system has little reason to write it down. | Keeping documentation current should be part of the agreed scope: how the system is built, released, monitored and restored. |
| Who owns the code and accounts | Depends on the contract. Code written by a contractor does not belong to you unless the agreement assigns it. Check that, and check that hosting, domain and licence accounts are in your organisation's name. | Also set by the contract, so read it. With CodeFirst the client owns the source code, the accounts and the documentation. |
| Scaling up for an upgrade | One person's available hours limit how fast a large piece of work can go, such as moving off an unsupported platform. Running the upgrade alongside day-to-day support stretches them further. | More people can be added for a defined project, quoted separately, while routine support carries on. |
An individual contractor is the better choice when
- The contractor knows the system well, is reliable and is likely to stay available.
- The system needs little attention and the business can wait a few days for a fault to be fixed.
- You have technical staff who can review the contractor's work and take over if needed.
- Priorities change week to week and you want to direct the work hour by hour without a change to a contract.
- The system will be replaced soon, so a longer arrangement is not worth setting up.
A software company is the better choice when
- The business stops, or loses money, when the system is down.
- The contractor is the only person who understands the system and nothing is written down.
- Your organisation needs named accounts, an access record and agreed response times for audit or insurance.
- An upgrade or a move off an unsupported platform is coming and needs more than one person's time.
- The contractor has said they are retiring, taking a full-time job or reducing their hours.
How to compare the cost fairly
The contractor’s rate and a supplier’s monthly fee measure different things. The rate is the price of an hour of work. The fee is the price of a service: someone responsible for the system, with cover, monitoring and documentation included.
To compare them, add up what the current arrangement costs over the last year:
- the contractor’s invoices;
- the time your own staff spend raising work, chasing it and checking it;
- the cost of each period when a fault waited because the contractor was unavailable;
- any work the contractor declined or could not fit in.
Then ask a supplier to quote a monthly fee for the same scope after assessing the system. If the system needs only a few hours a year and can wait for a fix, the contractor will usually remain cheaper. If it is critical, or a departure would leave nobody who can change it, the contract usually costs less once the risk is counted.
The risk that rarely appears in the budget
An old in-house system looked after by one contractor depends on that person. While they are available it can work very well, often for years. The risk shows when they are not: a long illness, a retirement, a better-paid contract elsewhere. Our page on what to do when a developer has left sets out what usually follows.
Whichever arrangement you choose, keep three things in your organisation’s hands: the source code in a repository you control, administrator access to every account the system uses, and a written note of how a change is released and how the system is restored from a backup.
Moving from a contractor to a support contract
The change does not have to be sudden, and it goes best while the contractor is still involved.
- Assess the system. A code audit shows what state it is in and what a support contract would need to cover.
- Hand over with the contractor present. The new supplier proves it can build, release and restore the system, using the contractor’s knowledge while it is still available. Our takeover process sets out the steps.
- Agree the scope in writing. What is covered, the hours of cover, response times by severity and what is charged separately. Our answer on what a software support contract should include lists the clauses.
- Run the support contract. Day-to-day care moves to a maintenance arrangement. The contractor can stay on for specialist work if that suits you.
If you want to keep the contractor and only need cover while they are away, developer absence cover is a smaller first step.
Questions we are asked
Is a managed support contract cheaper than a contractor?
By the hour, usually not. Over a year it can be, depending on how much work the system needs and what an outage or a sudden departure would cost you. Add up the contractor's invoices, the staff time spent managing them and the cost of any period without cover, then compare that with a quoted monthly fee for the same scope.
Can we keep our contractor and add a support contract?
Yes, if the split is clear. One common arrangement is for the contractor to carry on with changes while a company gives cover during their absence and holds the documentation. Agree in writing who is responsible for faults, and keep the code in a repository your organisation controls so both can work from it.
How do we move from a contractor to a support contract without losing what they know?
Plan the handover while the contractor is still engaged. The new supplier should build the system from its source code, release a change and restore a backup with the contractor available to answer questions. Pay the contractor for those handover sessions if you need to; it is cheaper than reconstructing the knowledge later.
Does IR35 affect the choice?
It can. If the contractor works through their own limited company and your organisation is medium or large, the off-payroll working rules make your organisation responsible for deciding their employment status. A contract with a company to provide a service does not usually raise the same question. Take advice on your own arrangement.
What should we check before changing arrangement?
That you hold the source code and can build it, that every account is in your organisation's name with a list of who has access, and that a backup has been restored recently. Our software takeover checklist covers the rest.
Not sure which suits you?
Tell us about the system and what you need done. If one of the alternatives is the better fit, we will say so.