How to Build a Software Development Team

The decision to build a software development team usually arrives as a budget line rather than as a plan. Somebody has approved headcount for two engineers, a board paper has argued that owning the code is cheaper than renting it, and the search starts before anybody has written down what the team is for. The hiring then goes wrong in a way that stays invisible for about nine months.

Most of the people asking this question should not hire yet, and the honest version of the advice starts there. A permanent team is a fixed cost set against a need that is usually variable. It works when the work is continuous, when the software is what customers pay for, and when somebody inside the business can say what should be built next week. Remove any one of those and you have bought by the year what you could have bought by the day.

What follows is the arithmetic and the sequencing: what an engineer really costs once National Insurance, pension, holiday, equipment and recruitment are in the number, which hire to make first, what teams of one, three, five and ten can genuinely deliver, and how to run a technical interview when nobody in the building is technical.

How many people do you need to build a software development team? Fewer than you expect, and later than you expect. One senior generalist who can own delivery end to end covers more ground than three juniors, because the constraint at small scale is judgement rather than typing. The first genuinely stable shape is three people, at roughly GBP 250,000 a year fully loaded. With a discontinuous roadmap, an agency is usually the better instrument.

Most Companies Should Not Build a Software Development Team Yet

Hiring is the most expensive way to answer a question you have not asked properly. An employment contract commits you to a salary for as long as the person is there, plus notice, plus the statutory costs described below, and it does so before you know whether the work will still exist in eighteen months.

The failure is rarely dramatic. A company hires two developers, they build the thing on the list, and the list runs out. Nobody wants to make anyone redundant, so the team invents work: a rewrite, a framework upgrade, an internal tool nobody asked for. Twelve months later the payroll is real, the output is not, and the founder concludes that engineers are unproductive. They were not. They were under-specified.

The counter-argument, and it is a good one, is that agencies cost more per day and understand your business less. Both are true. What it misses is that an agency is a variable cost you can switch off, so a bad month costs a month rather than a year. When the roadmap is genuinely continuous the calculation flips and in-house wins on both cost and speed. The mistake is flipping it early. A fixed piece of work with a defined end is an agency engagement, not a hiring plan, which is why our software development service sees so many businesses that arrive asking about headcount and turn out to have a project rather than a programme.

The Test That Tells You Whether You Need a Team

Three conditions, and you want all three. Fewer than three means you are not ready.

Is the software the product, or is it supporting the product? If customers pay you for software, or if it is the reason they choose you over a competitor, the code is a strategic asset and outsourcing all of it eventually becomes a governance problem. If the software runs your invoicing, it is plumbing, and plumbing is bought.

Is the roadmap continuous? Write down what you would build in months four through twelve. Not features you might like, work you can defend commercially. If that list is thin, you have a project with a tail rather than a year of work.

Can somebody in the business specify work? This is the one that gets skipped. An engineer needs to know what problem to solve and how you will know it is solved. If the only person who can answer that is the chief executive, and they have forty minutes a week, the team spends most of its time waiting or guessing. A team without a product owner produces motion, not progress.

A fourth question decides the timing rather than the answer. Can you fund eighteen months without the software generating revenue? If your runway forces the team to be profitable by month six, hire nobody and buy the work by the day.

What an Employee Actually Costs in 2026

Salary is roughly seventy per cent of the number. The rest is statutory, operational and one-off, and the last category is the one that ruins first-year budgets.

The statutory costs you cannot negotiate

Employer National Insurance is the largest addition. For the 2026 to 2027 tax year, employers pay 15 per cent on earnings above a secondary threshold of GBP 5,000 a year, per the GOV.UK rates and thresholds for employers. On a GBP 60,000 salary that is 15 per cent of GBP 55,000, or GBP 8,250. Eligible employers can offset up to GBP 10,500 of their annual secondary Class 1 liability through the Employment Allowance, though a company with a single director and no other employee liable for secondary contributions cannot claim it.

Pension auto-enrolment adds a minimum employer contribution of 3 per cent, inside a total minimum of 8 per cent, calculated on qualifying earnings between GBP 6,240 and GBP 50,270 a year according to GOV.UK guidance on workplace pension contributions. That works out at about GBP 1,321 per employee at the top of the band. Many employers pay a percentage of full salary instead, which is more generous and easier to explain to a candidate.

Holiday is a capacity cost rather than a cash one. Statutory entitlement is 5.6 weeks, which is 28 days for someone working five days a week, and bank holidays do not have to be given on top. Against roughly 260 working days, that is close to eleven per cent of the year before anybody is ill.

The costs that get left out of the spreadsheet

Equipment is small but real: a development laptop at GBP 1,500 to GBP 2,500, a monitor, a desk. Tooling is larger than people expect once you count source control, an IDE licence, continuous integration minutes, cloud environments, error tracking and log retention. GBP 1,200 to GBP 3,000 per engineer per year is a defensible planning figure, and a house estimate rather than a published statistic.

Recruitment is the spike. A contingency agency in the UK typically charges a percentage of first-year salary in the high teens to mid twenties, so budget GBP 9,000 to GBP 15,000 on a GBP 60,000 role unless you hire direct. Again, a house estimate.

The line nobody costs is management. A senior engineer supervising two others loses between twenty and forty per cent of their own delivery capacity, so three hires do not produce three people of output.

Read that as roughly 1.4 times salary in year one and 1.2 times thereafter, before management overhead. The salary, equipment, tooling and recruitment figures are house planning estimates; only the National Insurance, pension and holiday lines come from published rates.

The Contractor Route and What It Really Buys You

A day-rate contractor removes the statutory costs and the notice period, and adds a premium and a governance obligation. In the UK, a senior developer contracting through their own limited company commonly sits in the GBP 400 to GBP 600 a day band, with specialist skills and short engagements above it. That is a house estimate, consistent with the bands we quote elsewhere on this site.

At GBP 500 a day and 220 billable days, that is GBP 110,000 a year against GBP 72,000 fully loaded for a permanent hire on GBP 60,000. The premium buys three things: you can stop, you can start quickly, and you get someone who has already solved this problem elsewhere. It costs you continuity and the institutional knowledge that walks out with the contract.

Contractors work well for a defined capability gap, for covering a leave of absence, and for the first six months of a build where you want senior judgement without committing headcount. They work badly as a permanent substitute for a team, because the incentive structure quietly rewards duration over completion, and because nobody is accountable for the code eighteen months later. The sensible version is a hybrid: contractors for peaks and specialisms, employees for the parts of the system you cannot afford to have leave. That is the pattern behind most of our hire a web developer engagements.

Off-Payroll Working and What the Rules Ask of You

This section describes an obligation. It is not tax advice, and a contractor arrangement of any size should be checked with an accountant or an employment tax specialist before it starts.

The off-payroll working rules, generally known as IR35, apply where somebody provides services through their own intermediary and would have been an employee had they contracted with you directly. GOV.UK guidance on understanding off-payroll working sets out who decides. A medium or large private-sector client determines the worker’s employment status for tax and must issue a Status Determination Statement giving its reasons. For a small client outside the public sector, that responsibility sits with the worker’s intermediary instead.

Whether you count as small follows the Companies Act size test. HMRC’s Employment Status Manual records that from 6 April 2025 the thresholds rose to turnover above GBP 15m and a balance sheet total above GBP 7.5m, with the 50-employee limit unchanged. A company is medium or large if it meets at least two of the three across two consecutive financial years.

HMRC publishes a tool for the determination itself. The check employment status for tax tool can be used by hirers, workers or agencies, and HMRC states it will stand by the result provided the information given is accurate and in line with its guidance. That caveat is the whole game: an output based on the contract you wish you had is worth nothing.

The practical consequence is simple. Contractors are administratively cheaper than employees only while you are small. Once you cross the size test, each engagement carries a determination, a statement and a record.

What an Agency Costs and What You Give Up

UK agency day rates for a senior developer commonly run GBP 600 to GBP 1,200, depending on seniority, sector and how much delivery management is bundled in. That is roughly double a contractor and triple a loaded employee day, and the comparison is misleading in both directions.

What the premium buys is capacity that is already assembled. A three-person agency squad has worked together, has a deployment pipeline, an on-call arrangement and somebody senior reviewing the code. Standing that up in-house takes six to nine months and two hiring rounds. For a fixed-scope build, or a first version where you are still learning what the product should be, that head start usually beats the rate difference.

What you give up is proximity and permanence. An agency’s understanding of your business is bounded by what you have told them, and it leaves when they do. The mitigation is documentation and a handover clause written at the start, not at the end.

The break-even is easier to reason about in months than in rates. Below about nine months of continuous work the agency is cheaper once recruitment, ramp-up and the risk of a bad hire are priced in. Past eighteen months, in-house wins clearly. Our guide to choosing and hiring a software development agency covers that selection, and the budgeting guide for custom software covers the numbers.

The First Engineering Hire Decides Everything After It

Everything after your first engineering hire is downstream of that person’s judgement. They choose the language, the hosting, the deployment approach and the data model, and every subsequent hire is assessed against a stack they defined. A company that gets this wrong does not discover it for a year, and then discovers it all at once.

Hire a senior generalist who can own delivery end to end. Not a specialist in the technology you think you need, and not a manager. Somebody who can talk to a customer, decide what to build, build it, put it in production and support it on a Tuesday night. That profile is expensive, roughly GBP 70,000 to GBP 95,000 outside London as a house estimate, and it is the cheapest thing you will buy that year.

The test in interview is not whether they know your framework. It is whether they can describe a project they scoped badly and say what they would do differently, and whether they ask about your customers before they ask about your stack. An engineer who asks only about the technology is going to build something technically excellent and commercially irrelevant.

Give this person authority as well as a job title. If they cannot say no to a feature request, you have hired a very expensive pair of hands. Our post on how to hire a software developer in the UK goes further into the vetting.

Why Hiring a Junior First Fails

The logic is always the same and always wrong. A junior costs GBP 28,000 rather than GBP 80,000, so you can hire two, and they will grow into the role. What actually happens is that nobody is there to grow them.

A junior developer is a net negative on delivery for three to nine months. That is not a criticism, it is how the profession works: they need code review, architectural guidance, and someone to stop them before they commit a decision that is expensive to unwind. Without a senior person doing that, the review never happens and the junior ships unchecked work straight into the system that runs your business.

The bill arrives later, as technical debt. Rewriting eighteen months of unreviewed code typically costs more than the salary you saved, and it costs it at a point where the software is already load-bearing.

Juniors are a good investment in the right order. Once you have a senior who has capacity to mentor and a codebase with tests and a review process, a junior becomes cheap capacity that compounds. Hired first, they are an unfunded liability with a payroll number attached.

Team Shapes: What One, Three, Five and Ten Can Deliver

An org chart tells you who reports to whom. What a buyer needs is a statement of what each size can actually put into production, and what it structurally cannot.

One engineer

One senior generalist can build and run a single application with a modest surface area. They can ship weekly, fix their own production issues and hold the whole system in their head, which makes them fast. What they cannot do is be ill, take a holiday, or resign. A one-person team has no redundancy at all, and every business running on one engineer is running an unpriced risk. Mitigate it with an agency retainer that covers absence, or accept it explicitly rather than by default.

Three engineers

Three is the first shape that survives a person leaving. Typically one technical lead and two engineers, with the lead spending about half their week on delivery and half on review, planning and unblocking. Three people can run two workstreams, keep a release cadence and carry a rota. They cannot specialise, so anything requiring deep expertise (a payments integration, a performance rewrite) is bought in. Fully loaded, this is roughly GBP 250,000 a year.

Five engineers

Five is where structure starts to earn its keep. You can now afford one specialist alongside the generalists, and the technical lead stops writing code for most of the week. Five people can run a product with a real user base, respond to incidents inside business hours and still make progress on the roadmap. This is also the size at which the absence of a product owner becomes intolerable, because the coordination cost now exceeds what a founder can absorb in the gaps.

Ten engineers

Ten is two teams, whether or not you have drawn the line. Communication paths grow faster than headcount, so the informal approach breaks and you need explicit ownership: who owns which service, who is on call, who decides. This is where an engineering manager becomes a role rather than a hat, and where platform work (deployment, environments, observability) is somebody’s job instead of everybody’s evening.

The Roles Explained for a Non-Technical Reader

Job titles in software are inconsistent between companies, which makes them hard to buy. Here is what each role does with its week.

Product owner

Decides what gets built and in what order, writes down what “done” means, and says no. Spends the week talking to customers and to the team, and converting one into work the other can act on. Without this role somebody else does it badly, usually the technical lead, at the cost of their delivery time. You can go without a dedicated product owner up to about five engineers if a founder genuinely has a day a week for it.

Technical lead

Owns how the system is built. Reviews code, makes the architectural calls, and is accountable when the design turns out to be wrong. At three people they still write code most days; at ten they write very little. This is the role you cannot skip at any size above one, because it is where consistency comes from.

Full-stack engineer

Builds features across the whole path, from the screen a user sees to the database behind it. The backbone of any small team, because a generalist can pick up whatever is blocking the release. At small scale, hire almost exclusively for this profile.

Specialist

Deep in one area: mobile, data engineering, security, a particular framework. Enormously valuable when the work genuinely requires it and idle when it does not. Buy specialists by the day until the need is continuous for at least six months.

QA engineer

Tests the system deliberately rather than incidentally, builds automated test suites, and owns the definition of a release that is safe to ship. Developers test their own work, but they test what they expected to happen. A tester tests what a user will actually do.

Platform engineer

Owns the ground the software runs on: environments, deployment pipelines, monitoring, backups, cost. Sometimes called DevOps, which is properly a practice rather than a job. The work exists at every size; the question is whether it is someone’s job or everyone’s overtime.

When a Tester, a Designer and a Platform Engineer Become Necessary

Each of these has an honest signal, and it is a symptom rather than a headcount number.

Hire a dedicated tester when regressions reach customers more than once a quarter, or when releases slow down because nobody is confident enough to press the button. Both mean manual verification has exceeded what developers can absorb. On a five-person team that usually arrives between month twelve and month twenty-four.

Hire or retain a designer when engineers are making interface decisions in the pull request. That is a failure of sequencing rather than skill: they are being asked to design and build at once, and the design half gets whatever time is left. A part-time designer is usually enough well past ten engineers.

Hire a platform engineer when deployment becomes an event rather than a routine, or when your best engineer’s week is being eaten by environments and pipelines. If shipping requires a named person and a calm afternoon, the ground has become the bottleneck. Our post on CI/CD pipeline practices covers what good looks like before you hire for it.

Hire an engineering manager at around eight to ten people, and not before. Below that, a technical lead with authority is better than a manager without technical credibility, because the decisions that matter at small scale are technical ones.

Writing a Job Description That Filters

A job description has one job: to reduce the number of applications you have to read while increasing the proportion that are relevant. Most descriptions do the opposite, because they list technologies instead of problems.

Lead with the problem. “You will own the rewrite of a booking system that handles GBP 4m a year and currently loses about one order a week” tells a good engineer more than a paragraph of adjectives, and self-selects for people who find that interesting. Name the stack in one line, marked as the current stack rather than a requirement: a strong engineer learns your framework in a fortnight and a weak one is not saved by already knowing it.

Publish the salary band. Roles without one attract people optimising for volume, and waste an entire interview loop discovering a gap that a number would have shown in ten seconds. If the band feels uncomfortably public, it is probably wrong.

Be explicit about the shape of the team, including that it is small. “You will be our first engineer, reporting to the founder” is a genuine attraction for some people and a genuine deterrent for others, and you want both effects. Vagueness here produces candidates who accept and then leave in month four.

Then cut the requirements list to things that are actually required. Fourteen bullet points is a list of preferences pretending to be a specification, and it suppresses applications from people who would have done the job well.

Running a Technical Assessment You Cannot Run Yourself

Without a technical founder, the temptation is to assess for confidence, which correlates with nothing. Structure the process so that the technical judgement happens somewhere you can trust it.

Use a short, paid take-home exercise. Two to three hours, paid at a sensible rate, with a written brief stating the constraints and what you will assess. Unpaid multi-day exercises filter for spare time rather than skill, and lose you exactly the experienced candidates you want. Keep it close to the real work: a small feature against a realistic codebase predicts the job better than an algorithm puzzle.

Bring in an external technical assessor for the review and the follow-up interview. An hour of a senior engineer’s time reading the submission and walking the candidate through their decisions tells you more than any number of competency questions. Expect to pay a day rate, and treat it as cheap insurance against a hire that costs a year.

Ask the candidate to explain their code to you, the non-technical person. If they cannot describe what they built and why in terms you follow, that is information: most of the job is communicating with people who are not engineers.

Take references properly, and ask one specific question: what did this person do when they disagreed with a decision. The answer separates engineers who raise problems early from those who go quiet and build the wrong thing correctly.

Right to Work Checks Are Not Optional

Every employer must check that a candidate has the right to work in the UK, and the check must be completed before employment starts. GOV.UK guidance on checking a job applicant’s right to work sets out three acceptable methods: an online check using a share code, a manual check of original documents with the applicant present, or a check through a certified identity service provider using identity document validation technology. British and Irish citizens cannot obtain a share code, so their check runs on documents or through an identity service provider.

Keep copies for the duration of employment and for two years afterwards, and diarise a repeat check for anybody whose permission to work is time-limited. The record is what establishes a statutory excuse if something is later found to be wrong.

The exposure is not trivial. GOV.UK states that an employer may face a civil penalty of up to GBP 60,000 for each illegal worker where a correct check was not carried out. For a company making its first two hires, that is larger than the entire recruitment budget. Build the check into the offer process rather than the first day, so a start date never arrives with the paperwork unresolved.

Hiring From Outside the UK

If the candidate you want does not already have permission to work here, you need a sponsor licence before you can employ them, and that is a project rather than a form.

Applying for a Worker licence costs GBP 611 for a small or charitable sponsor and GBP 1,682 for a medium or large one, according to GOV.UK sponsorship guidance. Most decisions are made in under eight weeks, with a priority service at GBP 750 offering a decision in ten working days when slots are available. Plan on the standard timeline, because that queue is first come, first served.

The role itself has to clear a salary floor. The Skilled Worker visa requires a licensed sponsor and a certificate of sponsorship, and GOV.UK sets the standard salary requirement at GBP 41,700 a year or the going rate for the occupation, whichever is higher. For most software roles the going rate, not the general threshold, is the binding constraint.

Then there is the Immigration Skills Charge, payable by the employer when the certificate of sponsorship is assigned. GOV.UK sets it at GBP 480 for the first twelve months for a small or charitable sponsor and GBP 1,320 for a medium or large one, with GBP 240 or GBP 660 for each further six months. On a three-year sponsorship for a medium employer that is GBP 3,960, and the sponsor cannot pass it to the worker.

Budget GBP 6,000 to GBP 9,000 and three to four months for a first sponsored hire. That is often right for a scarce skill, and almost never right for a first hire you need working in six weeks.

Onboarding and the First Ninety Days

Set one measurable target: the new engineer ships something to production in week one. Not a major feature, a small real change that customers see. It is the fastest test of whether your environment is actually workable, and it changes the psychology of the hire from observer to owner.

Several things have to be true for that to happen. A documented local setup that works on a clean machine. Accounts and access arranged before day one rather than requested on it. A deployment path that does not require a specific person’s blessing. A named buddy whose calendar is genuinely clear that week. If any are missing, the first thing your new engineer learns is that your systems do not work.

By day thirty they should have shipped a meaningful feature and be able to describe the business, not just the codebase. By day sixty they should be reviewing other people’s code and challenging decisions. By day ninety they should be identifying work rather than receiving it.

Those milestones are also your early-warning system. A hire who is challenging nothing by day sixty is either mismatched or being managed too tightly, and both are fixable in month three at a fraction of what they cost in month nine. Our post on developer onboarding that ships in week one sets out the mechanics.

Retention, Costed Rather Than Cultured

Replacing an engineer costs the recruitment fee, the ramp-up, and the delivery the departing person stopped doing once they resigned. On a GBP 60,000 role, GBP 12,000 of fee plus three months of reduced output puts the real figure north of GBP 25,000. That is a house estimate, and a conservative one, because it excludes the knowledge that leaves with them.

Engineers rarely leave over money alone, though money is the reason they give. They leave because they cannot ship. A deployment that takes three days, a review queue nobody clears, a roadmap that changes every fortnight, six months of work cancelled before release. Each tells a competent person that their effort does not convert into outcomes, and competent people have options.

The commercially rational retention spend is therefore not perks. It is deployment automation, a functioning review process, a stable roadmap and enough slack that maintenance happens before it becomes an emergency. Those are the same investments that increase delivery speed.

Pay bands still matter, in one specific way. Salaries drift when the market moves and internal reviews do not, and the person who notices first is the one who interviews elsewhere. Review bands annually against public data such as the ONS Employee earnings in the UK bulletin, which put median gross annual pay for full-time employees at GBP 39,039 in April 2025. It costs far less than a resignation.

The Hybrid Model Most Companies Land On

After eighteen months, most companies that set out to build an in-house team end up somewhere in the middle: a small permanent core owning the product, with an agency or contractors attached for specialisms and peaks. That is not a failure of the plan. It is the arrangement that survives contact with a real roadmap.

It works when three things are true. The in-house team owns the architecture and the production environment, so the external party is contributing inside a structure you control rather than defining one. Code review runs in both directions, so external work is reviewed by your team and your team’s work is reviewed by theirs. And the external party’s scope is written as outcomes, not hours.

It fails when the agency becomes a black box. The tell is that nobody in-house can explain how a component works. Prevent it structurally: external work lands in your repository, deploys through your pipeline, and is documented as a condition of payment rather than a courtesy at the end. Keep a knowledge transfer session in the contract at a fixed cadence, monthly is usually enough. Our comparison of outsourcing software development, UK versus offshore is worth reading before choosing where the external half sits, because time zone overlap materially changes how well this model works.

A Staged Plan for the First Eighteen Months

Months one to three: do not hire. Write the roadmap for months four to eighteen and get it reviewed by somebody technical who is not selling you anything. Buy the immediate work from an agency or a contractor. The output of this stage is a defensible answer to whether the work is continuous.

Months four to nine: hire the senior generalist. One person, well paid, with authority over technical decisions. Keep the external capacity running alongside them for the first two months so delivery does not stop while they orient. Decision point at month nine: is the roadmap still full, and is this person able to specify work for others.

Months ten to fifteen: if both answers are yes, add two engineers to reach the stable shape of three, and appoint a product owner even if it is a founder formally allocating a day a week. If either answer is no, stay at one plus external capacity, which is a perfectly good permanent state for a business whose software supports the product rather than being it.

Months sixteen to eighteen: the second decision point. Add the fourth and fifth people only if the constraint is genuinely capacity rather than direction. Teams grow for the wrong reason more often than the right one, and the symptom is a backlog that is long but not prioritised. At every decision point, ask whether the next hire is faster than the next agency day.

Where to Start

Write the eighteen-month roadmap first, answer the three-part test honestly, then price both routes with the real numbers rather than salary alone. Most companies discover that the first hire should be one senior person rather than two mid-level ones, and that the six months before it are better bought by the day.

Mecanik works both sides of this. We run software development engagements for companies that are not ready to hire, and supply senior capacity through hire a web developer for teams building a core who need the peaks covered while they do it. If you are weighing the two, the useful conversation is about the roadmap, because that is what decides it.

Frequently Asked Questions

How much does it cost to hire a software developer in the UK? Budget roughly 1.4 times salary in year one and 1.2 times thereafter. On a GBP 60,000 salary that is about GBP 85,600 in year one, made up of salary, employer National Insurance at 15 per cent above the GBP 5,000 secondary threshold for 2026 to 2027, a minimum 3 per cent pension contribution on qualifying earnings, equipment, tooling and a recruitment fee. Salary, equipment, tooling and recruitment figures are house planning estimates.

Should my first engineering hire be a senior or a junior? Senior, and a generalist rather than a specialist. A junior developer is a net negative on delivery for three to nine months and needs a senior person to review their work, so hiring one first creates unreviewed code in a system your business depends on. The rewrite usually costs more than the salary saved. Juniors are a good investment once a senior with mentoring capacity and a review process are already in place.

How many developers do I need to build a software development team? Three is the smallest shape that survives someone leaving: a technical lead plus two engineers, at roughly GBP 250,000 a year fully loaded. One senior generalist can run a single application but has no redundancy for illness, holiday or resignation. Five is where a specialist and a dedicated product owner start to pay for themselves, and ten is effectively two teams needing explicit service ownership.

When is an agency better than hiring developers in-house? When the work has a defined end, when you have less than about nine months of continuous roadmap, or when you need capacity before a hiring round could deliver it. An agency is a variable cost you can stop, so a bad month costs a month rather than a year. Past eighteen months of continuous work, an in-house team wins clearly on both cost and speed.

What do I need to check before employing a developer in the UK? Complete a right to work check before employment starts, using an online share code, original documents with the applicant present, or a certified identity service provider. GOV.UK states the civil penalty can reach GBP 60,000 for each illegal worker where a correct check was not carried out. If you are sponsoring someone from outside the UK, you also need a sponsor licence, a certificate of sponsorship and the Immigration Skills Charge.