Should Your Company Hire, Train, or Contract for AI Delivery?

Hire when you have continuing work that needs internal engineering capacity. Train existing staff when their current skills provide a credible starting point and you can release time for learning and practice. Contract when a defined assignment needs expertise or capacity you don't have. Compare the complete delivery and support costs, then decide who will own the workflow after launch.

Define the work before choosing a staffing model

Write down the operational result you need and the work required to sustain it. A limited pilot, an internal application, and a product serving paying customers require different coverage. Estimate discovery, implementation, evaluation, and support separately. Include the contribution of staff who provide records, approve rules, and review outputs.

Separate the initial build from the continuing backlog. A company may need substantial integration work for six weeks and modest maintenance afterwards. Another may need weekly releases across several workflows. A single headline number for engineering hours can hide that difference and lead you to fund capacity you cannot use.

Identify the skills you already have and the time those people can actually provide. An engineer with the right experience but a full delivery schedule doesn't fill the capacity gap. A domain expert can define acceptance criteria without being ready to maintain an application. Use our guide to the skills needed to run AI in production to check coverage.

CIPD's April 2026 AI skills-planning guidance treats hiring, developing staff, and borrowing external expertise as options for addressing skill gaps. It recommends aligning that choice with AI adoption and workforce planning. Apply the framework to a defined assignment rather than choosing a staffing model because an AI job title is popular.

A small-business owner's Reddit question asks whether to hire an AI-focused employee or use an agency to repair fragmented systems. It reflects a buyer's uncertainty, rather than evidence that a particular staffing model works best. Distinguish a systems-repair problem from a missing model capability before hiring.

Set the required date for an accepted result and the consequence of delay. Compare credible time to readiness, including access, onboarding, and review. An external team can also wait for customer decisions, and an internal hire can also need help. Ask each proposed plan to show its dependencies.

Hire for continuing capacity and ownership

A permanent hire fits when you can show a continuing body of work and a role the organisation can support. Give them a defined remit, a manager who can resolve priorities, and access to the owners of the relevant systems. Hiring an engineer doesn't settle the business rules or grant production permissions.

Look beyond the first project. What will the person work on after its initial release? Include maintenance, new integrations, quality testing, and the backlog of improvements you have evidence for. Avoid filling the plan with speculative projects simply to justify a full-time position.

Assess the relevant delivery skills. A person who can build a demonstration may need senior review before operating a customer-facing service. A senior engineer may still need domain support to define correct outcomes. Request evidence from comparable systems and specify the specialist help you will provide.

Count recruitment and ramp-up. The company needs time to assess candidates, establish access, and teach the operation. A role with clear scope and an available mentor has a different readiness path from an isolated first technical hire. Use your own hiring experience and current candidate evidence rather than a universal time-to-hire claim.

Plan continuity beyond the individual. Give a second authorised person access to the repository and recovery process, and require documentation that they can follow. A permanent employee can leave or take time off. Internal employment changes the relationship; it doesn't automatically remove dependence on a single builder.

For a venture-backed startup, a hire can make sense when the capability is central to the product and customer commitments create sustained work. Inspect whether the founder still provides essential deployment or support work outside the staffing plan. A growing headcount should improve delivery coverage, not merely change the names in the organisation chart.

Train for a demonstrated skill gap

Training fits when the starting skills are close enough to the required task and the company can support practice. An analyst may learn to prepare approved inputs and maintain evaluation cases. An experienced developer may learn an AI integration stack. Those paths differ from asking a nontechnical employee to operate unfamiliar production infrastructure after a short course.

Define the capability the person will demonstrate after learning. For example, they can identify a stale source, test a prompt change against the agreed cases, and escalate a failure through the runbook. Course completion establishes participation. A supervised demonstration establishes more about readiness for a specific responsibility.

Release time from existing duties. Learning, practice, and review compete with the work the employee already does. Decide what moves to another person, slows down, or stops. Calling that time free because salary already appears in the budget can conceal an operational capacity cost.

The OECD's November 2025 SME workforce report, based on a 2024 survey of over 5,000 SMEs in seven countries, found that half of non-adopters reported a lack of employee skills as a barrier. That describes respondents in the surveyed countries and period. It doesn't establish how long your employee needs to become competent or prove that training alone fixes the barrier.

Give the learner a mentor and a boundary for independent work. Let them maintain approved low-consequence tasks first, with review of changes they aren't yet ready to own. Increase responsibility when they demonstrate the required checks and recovery skills. Reassess the assignment if they need continuing specialist support beyond the planned scope.

Training can also accompany external delivery. Have staff write domain cases, review the build, and practise operation while the contractor is available. Make that work part of the project plan. It transfers more capability than a presentation at the end, provided the receiving team can actually perform the agreed tasks.

Contract for a bounded delivery commitment

External delivery fits a defined project, a temporary capacity gap, or specialist work that you don't need full time. Specify the result, systems, permitted data, and acceptance conditions. Ask who will perform the work and what comparable delivery evidence they have. A company profile is weaker evidence than a team and plan matched to the assignment.

Agree whether the engagement provides advice, implementation, or continuing operation. A diagnosis and roadmap can be valuable, but they have different completion conditions from a supported workflow. A time-based contract buys capacity under its terms; a fixed-price project still needs clear scope and a change process.

Keep an internal process owner. They decide business rules and accept the result, with the relevant technology and security owners approving their areas. The supplier can recommend and implement, but cannot replace customer authority. Budget the customer's participation alongside the supplier's work.

Document support and handoff before work starts. State who repairs integrations, handles provider changes, and responds to an incident. Distinguish a response commitment from restoration of the service. Check what happens when a support allowance runs out or a new requirement falls outside the agreed scope.

NIST's AI RMF playbook addresses third-party risks and contingency processes alongside clear organisational responsibilities. Outsourcing the build doesn't eliminate the need to oversee the deployed system. Use the framework to assign duties; it doesn't certify a supplier or determine your contract terms.

Agree the rights and access needed to continue operating the result. Identify company-controlled accounts, code and configuration, documentation, and any supplier-owned components. Require appropriate professional review where the agreement needs it. Our guide to consultant, engineering, and FDE assignments covers role and delivery boundaries.

Compare total cost over the same period

Choose a common period and scope before comparing prices. A six-week project fee and an annual salary describe different purchases. Compare the cost of achieving and sustaining the same accepted workflow, including review and support. State what each estimate includes and where you still need a quote or internal cost figure.

For a hire, include employer costs as defined by your finance team, recruitment, equipment, onboarding, supervision, and any outside specialist support. Show the capacity available for this assignment after other duties. Allocate a share of cost when the person also supports other work, while keeping the full employment commitment visible.

For training, include tuition, staff learning time, mentor time, coverage of existing work, and supervised delivery. Distinguish incremental cash from the value of staff capacity. Don't count the same cover cost and displaced labour twice without explaining the relationship. Finance should make the treatment consistent across the options.

For a contractor, include discovery, implementation, the customer's participation, support, hosting or model usage, and any later transfer work. Identify optional items and exclusions. Keep software costs common to all options separate when they don't affect the staffing choice.

Use break-even arithmetic as a sensitivity check. If a hypothetical hire costs A$180,000 annually and comparable external capacity costs A$150 per hour, the simple crossover is 1,200 hours: A$180,000 divided by A$150. That is an assumed labour-cost comparison, not a market rate or a hiring recommendation. Recruitment, readiness, support coverage, and differences in capability can change the result.

Test the volume assumption. At 400 external hours, the same assumed rate gives A$60,000. At 1,400 hours, it gives A$210,000. A permanent employee may spend available time on other valuable work, but you need evidence of that work and realistic capacity. Compare accepted output and continuity rather than treating every paid hour as equivalent.

Include the cost of delay only with a stated basis. If waiting prevents a verified benefit, show the measurement and timing assumptions. Staff hours saved don't automatically become cash savings. Our article on time saved and money saved explains that boundary.

Make the decision for a 20-person firm

Consider an illustrative 20-person service company that needs a draft-job workflow and expects limited continuing engineering work. All figures below are planning assumptions in Australian dollars, excluding tax. They are neither market benchmarks nor a Waypoint quote. The company keeps a manager responsible for the process and human approval before scheduling.

Assume external delivery needs 240 engineering hours at A$150 per hour, giving A$36,000. Over the following nine months, assume support needs eight hours per month at that rate: 72 hours and A$10,800. Add 80 internal participation hours valued at A$60 per hour, giving A$4,800. The identified first-year delivery and support cost is A$51,600, before common software costs and any listed exclusions.

For an internal learning path, assume A$3,000 of tuition, 120 learning hours valued at A$60 per hour, and 60 mentor hours at A$150 per hour. That gives A$19,200 before implementation. Assume supervised implementation needs another 300 employee hours at A$60 and 40 mentor hours at A$150, adding A$24,000.

If continuing support then needs 108 employee hours at A$60 and 24 mentor hours at A$150, it adds A$10,080. The assumed training, implementation, and support total becomes A$53,280. This is a resource-cost view, not an incremental-cash budget. It assumes the employee can reach the required skill level and the company can release 528 hours of their time without uncounted disruption.

A hypothetical full-time hire with A$180,000 of annual employer cost and A$15,000 of recruitment and setup costs creates an A$195,000 commitment before other exclusions. That capacity may be justified by a larger confirmed backlog. For this single workflow, the business needs to identify the work that will use the rest of the hire's capacity.

The examples don't make training intrinsically cheaper or contracting intrinsically faster. The learning path has uncertain time to competence, while the external path depends on supplier availability and customer access. Replace the assumptions with a capability assessment, a scoped supplier proposal, and finance-approved cost definitions before deciding.

A practical initial choice may combine a bounded external build with internal training in operation and evaluation. If that mix fits, budget the training and receiving team's time within it. Review actual support demand after launch and revisit hiring when the ongoing backlog warrants a dedicated role.

Make the decision for a large corporate

A large corporate should examine its existing platform, integration, security, and business teams before creating a separate AI organisation. The gap may be expertise in evaluations, capacity for local deployment, or authority to coordinate several departments. Hiring more builders won't necessarily resolve a slow approval path.

Separate common engineering from local ownership. An internal team can maintain shared connectors, access patterns, and evaluation infrastructure. Business teams define their rules and acceptance criteria. External specialists can handle a bounded integration or help establish a capability, with a named internal receiver.

Consider an illustrative portfolio of workflows requiring 1,800 comparable engineering hours over a year. At the assumed external rate of A$150, the labour estimate is A$270,000. A hypothetical A$180,000 internal role with 1,200 hours available for this work leaves 600 hours uncovered; external cover at the same assumed rate adds A$90,000. The combined labour estimate is also A$270,000 before recruitment and other differences.

That equal estimate doesn't make the options equivalent. The internal role may maintain shared components and accumulate company knowledge, while external capacity may bring specialist skills or provide cover during peaks. Verify that the hours cover comparable work and quality. Neither plan is complete without domain review, security decisions, and production support.

For a PE portfolio, establish which common work can support several companies and which needs local engineering. A shared hiring plan should reflect real demand across those businesses. Don't add every proposed pilot to a full-time staffing forecast before its owner, access, and business case are ready.

For corporate procurement, include access preparation and the receiving team's availability in the schedule. A framework agreement may simplify buying capacity but doesn't establish acceptance or transfer responsibility. Review whether the engagement leaves maintained capability or an expanding set of supplier-dependent local implementations.

Set review points and an exit plan

Record the decision with its assumptions: expected workload, required skills, date for accepted delivery, total cost, and continuing owner. State what would change the choice. Higher support demand, a delayed learning path, or a confirmed new backlog can justify a different mix without making the original decision dishonest.

Use a bounded first commitment where uncertainty is high. That may be paid discovery, a supervised training task, or a limited implementation with explicit acceptance. Ask the team to produce the evidence needed for the next decision rather than promising the whole programme before understanding its dependencies.

Check continuity through a demonstration. Another authorised person can operate the supported workflow, recognise a failure, and follow the recovery process. Require the receiving team to perform that work while the builder can still help. Internal employment and a support contract both need that practical test.

Review actual effort after an agreed operating period. Compare delivery hours, support, customer or staff review, and outcomes with the plan. Distinguish a change in scope from a productivity improvement. Use the measured workload to revise capacity and training commitments.

Put the next commitment in writing: the work funded, the person who accepts it, and the evidence due at the review point. If readiness or demand is uncertain, keep the commitment bounded until that evidence arrives. Approve expansion when the team can show accepted outcomes and continuing coverage for the workload it will take on.