In this guide 6 sections
Hire in-house when software is central to how you win and the work never stops. Outsource when the work comes in bursts, needs several skills at once or you cannot wait months to recruit. Most small firms do best with one or two employees who own the product and an outside team for peaks.
Start with how steady the work is
Open your Jira board or spreadsheet of requests for the last twelve months. If bug fixes, report tweaks and small features arrive every week, you have a standing workload, and that suits a salaried person who slowly learns your quirks.
Project work that arrives in a lump, then goes quiet, leaves an employee idle. It fits an outside team that moves on when the release ships.
Be honest about your pattern, because sprint plans flatter it. Many owners picture a steady stream and actually have three launches a year. Check the tickets.
The effort of hiring is larger than it looks
Hiring is slow. You write the advert, screen résumés, set a coding test, run two interview rounds and then wait out a notice period before the new hire even starts. After that comes a long stretch of learning your database and your odd integrations.
You also need someone who can judge the work. A lone developer on a salary, reporting to a non-technical owner has nobody to review pull requests, check backups or question shortcuts. Nobody at all.
An outside team arrives already formed, with a lead, testers and a designer who have shipped together before. You trade that speed for less depth in your particular business. That is the deal.
- Weeks lost to job boards, referrals and notice periods
- Who reviews pull requests and schema changes
- Laptops, IDE licences, staging servers and test phones
- Cover for appraisals, leave, illness and attrition
Continuity and the bus factor
Ask one question. If your only developer left tomorrow, how many days would pass before someone could fix a broken invoice run or a stock sync that stopped overnight? That gap is your bus factor. For a one-person team it is wide.
Outside teams reduce the problem when several people know the code. They create a new one if the knowledge lives only in their heads, their laptops and their private accounts.
Either way, demand written notes, a runbook, a code freeze procedure and access in your name. Continuity is a document. It is not a promise.
Cost shape, mixing both and avoiding lock-in
An employee is a fixed monthly commitment, whether the backlog is full or empty. An outside team is closer to a variable bill. It swells before a launch and shrinks after. Choose the shape your cash flow can carry without strain.
Mixing works well. Keep one or two people who own priorities and acceptance. Bring the outside team in for large builds and rare skills, such as mobile apps or penetration testing.
Lock-in comes from missing paperwork, not from the model. Hold the repository, hosting and domain yourself. Insist on readable code, and keep a short inventory of what each system does and who touched it last.
- Git repository under your own organisation account
- Deployment script and rollback notes in a wiki
- Admin credentials held by two of your people
- A retainer clause that allows a clean handover
Run a three-month trial before committing
You do not need to decide forever. Try the lighter option first, usually an outside team on a rolling contract with a short notice period, and keep a log of what work actually arrives each week.
After three months, count the hours spent and the types of task. If you used most of a person’s week, every week, the case for a hire is strong.
Write that count on one sheet. Bring it to your next planning meeting.
Workload and ownership worksheet
A one-page worksheet. The top block lists the past twelve months of changes by month and size. The middle block has three rows, one each for product owner, developer and tester, with a column for in-house, outsourced or shared. The bottom block records where code, hosting, domain and credentials are held.
Open a blank worksheet to printQuestions owners ask
Is one in-house developer enough?
Rarely for a product that matters. One person is a weak link and has nobody to review their work. Pair them with an outside team or a part-time reviewer.
When should I move work in-house?
Move it when the work is steady, your payroll, stock or booking rules shape every change and you have someone able to manage developers. A trial period shows whether those conditions hold.
How do I avoid being tied to one vendor?
Own the code, hosting and domain from the start, require documentation and ask for a handover plan in the contract. Test the handover once while the relationship is still good.
Can an outside team feel like part of my company?
Yes, when they join your chat, attend planning calls and work from your backlog. It takes effort from both sides and a named contact on yours.