A software company or an in-house developer?
Employing a developer gives you someone who knows the business and is on hand every day. A software company gives you several people's skills without a hire, and which suits you depends on how much work there is and how steady it is.
| Aspect | Hiring an in-house developer | A software company |
|---|---|---|
| Cost | A fixed yearly cost made up of salary, employer's costs, equipment, training and recruitment. It is the same in a quiet month as in a busy one. | You pay for the work the system needs, as a fixed price for a project or a monthly plan. For a system that needs only part of a person's time, that usually comes to less than a full-time post. |
| Knowledge of the business | An employee learns how the business works, sits near the people who use the system and often hears of a problem before anyone reports it. | An outside team learns the business through the work and through what you tell it. Reaching the same understanding takes longer. |
| Availability | On hand every working day and able to drop other work for an urgent fault. Holidays and illness leave no cover unless there is a second developer. | Works to the response times agreed in a support plan and has other clients to attend to. Absence is covered by colleagues. |
| Continuity if someone leaves | When a sole developer resigns, much of the knowledge leaves with them, and recruiting a replacement usually takes months. | People leave companies too. The knowledge is shared between several people and written down, so the system does not rest on one of them. |
| Range of skills | One person covers design, programming, the database, hosting and security. Few people are equally strong in all of them. | Different people handle different parts of the work, and one person's changes can be checked by another. |
| Speed to start | Recruitment takes time, and is followed by a notice period and some weeks of learning the system. | Work can start once the system has been assessed and a scope agreed. |
| Managing the work | Someone has to set priorities, review the work and keep the developer's skills current. That is hard to do well without technical knowledge. | The company manages its own people. You set the priorities and accept the work against checks agreed at the start. |
| Who owns the code and accounts | Code written by an employee as part of their job normally belongs to the employer, subject to the employment contract. Check that accounts and passwords are held by the business and not by the individual. | Set by the contract, so read it. With CodeFirst the client owns the source code, the accounts and the documentation. |
Hiring an in-house developer is the better choice when
- There is enough development work to fill a full-time post, month after month.
- The software is what the business sells, or its main advantage over competitors, and you want that knowledge on the payroll.
- Requirements change daily and need someone sitting with the people who use the system.
- You already have a technical manager who can recruit well and review the work.
- You plan to employ two or more developers, so that no single person holds all the knowledge.
A software company is the better choice when
- The system needs steady attention, but not a full-time person.
- A sole developer has left or is about to, and you do not want to depend on one individual again.
- Nobody in the business has the technical background to hire a developer or judge their work.
- The work calls for skills one person rarely combines, such as knowledge of an old system and of the technology it should move to.
- You need a defined piece of work done for a known price, and little after that for a while.
What usually decides it
The amount of work, and how steady it is. An employee costs the same in a quiet month as in a busy one. In our experience most internal business systems, once built, do not produce a full week of development work every week. They need a burst of effort for a new feature and then a few hours a month of care. A business with a constant stream of development work is in a different position, and for that business an employee is often the better buy.
Dependence on one person. A single in-house developer is a team of one. Holidays and illness leave no cover, and a resignation takes much of the knowledge with it. Our page on what to do when a developer has left describes how that usually goes. A second developer removes much of the risk and doubles the cost.
Who will manage the developer. Someone has to set priorities and notice when quality slips. In a business with no other technical staff, that falls to a manager who cannot read the code. A good developer copes with this, but it remains a weakness in the arrangement.
A middle route
The choice is not all or nothing.
An in-house developer with a company behind them. The employee does the daily work. A company holds a support arrangement for the same system, which gives cover during absence and a second opinion on larger decisions. The knowledge is then held in two places.
A company for the development, with an owner inside the business. Nobody in-house writes code. One member of staff knows the process thoroughly, decides priorities and is the supplier’s main contact. This suits a system that is important but does not change every week, and it is the usual shape of a maintenance arrangement.
A company now, an employee later. If the code, the accounts and the documentation belong to you, an employee can take the system over when the volume of work justifies the post.
Whichever you choose
Keep three things in the hands of the business: the source code in a repository the business controls, administrator access to every account the system uses, and a written description of how a change is released. With those, either arrangement can be changed later. Without them, a resignation or a change of supplier becomes a recovery exercise. If you are not sure what you hold, a code audit will tell you.
Questions we are asked
Is it cheaper to employ a developer or use a software company?
It depends on the volume of work. A full-time post is a fixed cost whether or not there is a full week of work to do. If the system needs a few days of attention a month, a support plan usually costs less. If there is full-time work for years ahead, employing someone usually costs less for each day worked.
Can a software company work alongside our in-house developer?
Yes, where the split of responsibility is clear. A company can take on a defined project the developer has no time for, or hold a support arrangement that gives cover during holidays and illness. We do not place developers in your team to be managed by you.
Our only developer is leaving. Should we replace them or use a company?
First secure the code, the logins and a handover while they are still there, then decide. Replacing them restores someone in-house and also restores the dependence on one person. A company spreads the knowledge across several people. Whichever you choose, insist that the knowledge is written down.
What should we keep in-house if we use a company?
Ownership of the code and the accounts, and the decisions about priorities. It also helps to have one member of staff who knows the system thoroughly as a user and acts as the supplier's main contact.
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.