Companies outsource software development for a small number of practical reasons: there is not enough work to fill a developer’s week, they need skills they do not have, they need to start sooner than recruitment allows, they do not want a system to depend on one employee, or they want a known cost with someone else carrying the risk of an overrun. Saving money is often the first reason given. It is sometimes true, and it is the one that most needs checking.
Which of these reasons applies to you matters, because it decides what kind of outsourcing you should buy.
The reasons that hold up
There is not enough work for a full-time post. In our experience this is the most common sound reason among small and mid-sized businesses. A system that runs the business may need a few days of attention a month: security updates, a fix, a small change. An employed developer costs the same in a quiet month as in a busy one. A supplier is paid for the work the system needs.
The skills are needed rarely or briefly. Moving a database to a new version, replacing an old Access system with a web application, tuning slow queries: each calls for experience a business might need once in five years. Buying that experience for the length of the job makes more sense than hiring it. The same goes for older technology, where the people who know it are hard to recruit at all.
The work needs to start soon. Recruiting a developer involves advertising, interviewing, a notice period and some weeks of learning the system. A supplier can usually begin once the work has been scoped.
Continuity. A business with one developer has a single point of failure. Holidays and illness leave no cover, and when that person resigns, much of the knowledge leaves too. A supplier spreads the knowledge over several people. People leave suppliers as well, so this holds only where the supplier writes things down, and that is worth asking about.
A known cost. A defined piece of work can be bought at a fixed price, with the supplier bearing the cost if it takes longer than expected. An in-house team cannot offer that. Nor can every outsourcing arrangement: work paid for by the day leaves the risk with you.
Management attention. Running developers well takes technical judgement: setting standards, reviewing work, keeping skills current. A business without a technical manager often finds this harder than the software itself.
An outside view. A team that has worked on many systems will have met your problem before, and may know a simpler answer than the one you were about to commission. This benefit is real but modest, and not a reason to outsource on its own.
The reasons that deserve a second look
“It is cheaper.” Sometimes. A day of a supplier’s time usually costs more than a day of an employee’s, because it includes management, cover and the supplier’s margin. Outsourcing costs less in total when you need fewer days than a full-time post provides. It can also cost less through lower rates abroad, though the saving is smaller than the rates suggest once you count the time your own people spend specifying and checking. Our article on the hidden costs of software outsourcing lists what the quote leaves out.
“It removes the risk.” It moves the risk. You no longer depend on an employee, and now depend on a supplier. That is a better position only if you own the source code, hold the accounts the system runs under and have documentation another team could use. Without those, changing supplier is slow and expensive, and the supplier knows it.
“We will not have to think about it.” Someone in the business still has to decide what is built, answer questions and check that what was delivered is what was asked for. Projects where the client steps back entirely tend to produce software that matches the specification and not the need.
“Development will carry on around the clock.” A team in a distant time zone can make progress while you sleep, provided the work is specified in enough detail that nobody needs to ask a question. For work still being worked out, the lack of shared hours slows things down.
When employing developers is the better choice
Outsourcing is not always right, and a supplier that says otherwise is selling.
- The software is what you sell, or the main thing that sets you apart from competitors. That knowledge belongs on the payroll.
- There is steady full-time work for two or more developers for years ahead. Employment then usually costs less for each day worked, and two people remove the single point of failure.
- Requirements change daily and are best handled by someone sitting with the people who use the system.
- You already have a technical manager who can recruit well and review the work.
Many businesses end up with a mixture: an in-house developer or two for daily work, and a supplier for defined projects and specialist jobs. Our comparison of a software company and an in-house developer goes through the trade-offs point by point.
Match the reason to the arrangement
Outsourcing comes in several forms, and the reason you are doing it points to the form you need.
| Your reason | What to buy |
|---|---|
| An existing system needs steady care, but not a full-time person | A monthly support arrangement with an agreed scope |
| A defined project, and you want the cost known in advance | A fixed-price build against a written scope |
| Your own team needs extra people or a missing skill for a while | Developers supplied to work under your direction |
| A large volume of well-specified work on a limited budget | A nearshore or offshore team, with someone technical on your side to review it |
| Your only developer is leaving | A takeover by a supplier, starting with an assessment of the system |
The third row is sometimes called outstaffing, and our article on outsourcing and outstaffing explains how it differs from handing over a result. The fourth is a question of location, covered in offshore, nearshore and onshore development. CodeFirst provides the first, second and fifth, and our page on outsourced software development describes how.
What to settle before you outsource anything
Whatever the reason and whichever form you choose, three things should be agreed in writing first.
- You own the code. The contract assigns it to you, and a current copy sits in a repository your company controls. Take legal advice on the wording.
- The accounts are yours. Hosting, domain names and third-party services are registered to your company, with the supplier given access.
- You know what you receive at the end. If the arrangement stops, you get the code, the documentation, the credentials and a handover.
Then write one sentence that begins “We are outsourcing this because”. If the sentence is about cost alone, work out the full cost of both options over three years before going further. If it names one of the other reasons, you already know which row of the table to start from, and which questions to put to a supplier.