Build In-House, Hire, or Partner: How to Staff AI Features

You have decided what AI feature to build. Now you have to decide who builds it, and the answer is less obvious than it looks, because the AI talent market is the tightest it has ever been.

ManpowerGroup’s 2026 Talent Shortage Survey, covering more than 39,000 employers across 41 countries, found that AI skills have overtaken traditional engineering and IT to become the hardest capabilities in the world for employers to find, with 72% of employers reporting difficulty filling roles overall [1]. A regional breakdown of the same survey put AI model and application development at the top of the technical list, defined to include selecting and adapting models, building retrieval systems grounded in company data, designing evaluation pipelines, and keeping AI applications running reliably at scale [2].

That last definition is the useful part. It describes exactly the skills an AI feature needs and exactly the skills most product teams do not yet have.

This guide lays out the three realistic paths, what each actually costs in money and time, and how to structure the decision. It is the closing piece in our series on adding AI features to an existing product.

Start with the strategic question

Before comparing costs, answer one question honestly: is AI going to be a core differentiator of your product, or a supporting feature?

If AI is becoming core, meaning it is what customers will choose you for, you need to own the capability in-house eventually. Any outside help should be structured as a transfer of capability rather than a permanent dependency.

If AI is a supporting feature that makes your existing product better, you may never need a dedicated AI team. What you need is the feature built properly and maintained, and the cheapest reliable way to get that is often not hiring.

Most products are in the second category and plan as though they are in the first.

Option 1: Build with your existing team

Your engineers know the product, the codebase, the data model, and the customers. That context is worth a great deal, and none of it transfers to an outside hire or partner for free.

What they will need to learn: retrieval design and evaluation, prompt and context engineering, building eval harnesses, cost and latency engineering, LLM-specific security, and the operational patterns that keep a model-dependent feature reliable. None of it requires machine learning research skills. Most of it is software engineering applied to an unfamiliar failure surface.

Best when: the first feature is a single model call or a contained retrieval feature, timelines are flexible, and you have a senior engineer with the appetite to own it.

Worst when: the first feature is customer-facing and high-stakes, the deadline is external, or nobody on the team has shipped anything like it. The predictable failure is a demo that works beautifully and a production feature that quietly degrades because nobody built evals.

Real cost: whatever those engineers were going to build instead. That opportunity cost is usually the largest number in this entire comparison and the one most often left out of the spreadsheet.

Option 2: Hire AI engineers

What it costs. US salary sources disagree considerably, which itself tells you something about how unsettled this market is. Reported figures for AI and machine learning engineers in 2026 range from roughly $128,000 to $186,000 in base pay depending on the source [3], with one analysis putting the honest base range for real production AI work at a mid-to-large company at $155,000 to $200,000 [4], and a national median around $173,000 with a 90th percentile near $270,000 [5]. Frontier labs and big tech pay multiples of that, largely in equity [4][5], and you will not win those bidding wars.

Add the usual loading. Benefits, taxes, equipment, and software typically bring fully loaded cost to something like 1.25 to 1.4 times base, and recruiting fees run 15% to 30% of first-year salary when you use an agency.

What it costs in time. SHRM’s broad benchmark for time to fill sits near 44 days across all roles, while engineering runs well past that, with reported averages around 62 days globally and senior roles commonly taking 60 to 120 days [6][7]. Then add notice period, onboarding, and ramp to real productivity. A realistic read is four to seven months from “we need this” to “this person is shipping,” and that is before AI specialization narrows the pool further.

The other risk: one AI hire is a single point of failure. If they leave, the capability leaves with them. Two hires doubles the cost and the timeline.

Best when: AI is core to your strategy, you have a multi-year roadmap of AI work, and you can afford to wait a quarter or two.

Worst when: you need one feature shipped this quarter, or when you cannot technically evaluate AI engineers yet, because interviewing for skills nobody on your panel has is how expensive mishires happen.

Option 3: Work with a partner

An AI development partner brings people who have already shipped production AI features and can start in weeks rather than months.

There is suggestive evidence this works. MIT’s NANDA research found that AI tools built with external partners reached deployment roughly twice as often as purely internal builds, about 67% versus 33% [8]. That figure is self-reported and does not establish causation [9], so treat it as a signal rather than proof. The plausible mechanism is simply experience: a first production AI feature demands evals, retrieval engineering, cost control, and LLM security practices that most product teams are encountering for the first time.

What it costs. Rates vary enormously by region and firm. A scoped first feature, meaning discovery through production launch with evals and telemetry, typically runs in the low tens of thousands to low hundreds of thousands of dollars, depending on scope, data complexity, and compliance requirements. Ongoing support is usually a fraction of that. Our guide to what it costs to build an enterprise AI assistant breaks down the drivers.

The real risks, stated plainly:

• Dependency. If the partner builds everything and documents nothing, you have rented a capability rather than acquired one.
• Context loss. Outsiders do not know your product, customers, or data quirks. Ramp-up is real and you pay for it.
• Misaligned incentives. Time-and-materials billing rewards duration. Fixed-price rewards cutting scope. Neither is inherently wrong, but know which pressure you have created.
• Quality variance. Anyone can write “AI” on a website. The field is new enough that credentials are hard to read.

Best when: you need one or two features built well and soon, your team is capable but unfamiliar with AI specifics, or you want an experienced second opinion on architecture before committing.

Worst when: AI is your core product and you plan to keep building on it indefinitely, or when you cannot dedicate anyone internally to work alongside the partner. A partner engagement with no internal counterpart produces a system nobody inside your company understands.

Side-by-side

A hybrid that usually works better than any pure option

For most companies adding their first AI feature, the effective structure is not a choice between these three but a sequence:

1. A partner builds the first feature with your engineers embedded, not in parallel. Your people are in the repo, in the design discussions, and in the eval reviews.
2. The engagement explicitly delivers the shared infrastructure, not just the feature: the model gateway, the eval harness, the cost and quality telemetry, and documented prompt and retrieval design.
3. Your team takes over maintenance at an agreed handover point, with the partner on a support retainer for a defined period.
4. You hire later, if at all, once you know from real experience what the role actually requires. Interviewing for AI engineers is much easier after you have shipped an AI feature than before.

This gets the first feature out at reasonable speed, leaves the capability inside your company, and defers the most expensive and slowest commitment until you can make it well.

How to evaluate an AI development partner

Ask questions whose answers are hard to fake:

• What did you ship, and what failed? Ask for a specific production feature, what the evaluation approach was, and what went wrong in the first month after launch. Anyone who has shipped real AI has failure stories; anyone who does not is selling demos.
• Show me an eval harness you built. This is the sharpest filter in the list. Teams that skip evals produce features that degrade invisibly [10].
• How do you handle cost and latency? Listen for routing, caching, context trimming, and per-tenant budgets. See LLM API costs in production.
• What happens when the provider has an outage? Listen for timeouts, backoff, fallbacks, and graceful degradation. See making LLM features reliable.
• How do you enforce tenant isolation and permissions? The only acceptable answer is in code at the data layer, never in the prompt.
• How do you pick models? Listen for task-level evals and multi-provider shortlists, not brand loyalty. See choosing an LLM for your product.
• What do we own at the end? Code, prompts, eval sets, and documentation should all be yours, in writing.
• Who actually does the work? Names, seniority, and whether the people in the pitch are the people in the repo.

Warning signs: a proposal with no evaluation plan, no discussion of cost per request, model choice presented as settled before any testing, unwillingness to work alongside your engineers, or a pitch that treats AI features as a normal web build with an API call bolted on.

Structure the contract to transfer capability

If you engage a partner, these terms matter more than the day rate:

• Your repositories, your cloud accounts, your provider keys. Not theirs.
• Full IP assignment covering code, prompts, eval datasets, and documentation.
• Named embedded engineers from your team, with their participation written into the plan rather than assumed.
• A defined handover milestone with documentation and a walkthrough, not a final invoice and a zip file.
• Acceptance criteria based on evals, cost per request, and latency targets, so “done” is measurable rather than a matter of opinion.
• A support period after handover at a known rate, since the first month of real traffic always surfaces something.

A decision shortcut

• AI is core to your product, and you have 6+ months of AI roadmap: hire, and use a partner to bridge the gap while you recruit.
• AI is a supporting feature, and you need it this quarter: partner, with your engineers embedded and a handover clause.
• AI is a supporting feature, and the timeline is flexible: build with your existing team, and buy a short architecture review rather than a full build.
• You do not yet know which category you are in: scope one contained feature, ship it, and decide with evidence. That is a cheaper way to learn than a year-long hiring process.

Keep reading

• How to add AI features to an existing software product (the pillar for this series)
• LLM API costs in production: how to estimate and cut them
• Choosing an LLM for your product
• Latency, rate limits, and fallbacks: making LLM features reliable
• AI copilots inside B2B SaaS: UX patterns users actually adopt
• What it costs to build an enterprise AI assistant

CMW AI Labs builds AI features for software companies with client engineers embedded, and hands over the gateway, eval harness, and telemetry at the end so the capability stays with you. If you are weighing whether to hire or partner for your first AI feature, talk to our team and we will give you a straight answer, including when the answer is that you do not need us.

Sources

1. ManpowerGroup, “Global Talent Shortage Reaches Turning Point as AI Skills Claim Top Spot,” February 26, 2026. https://www.manpowergroup.com/en/news-releases/news/global-talent-shortage-reaches-turning-point-as-ai-skills-claim-top-spot
2. Quartz, “10 in-demand skills employers can’t find enough of,” August 2026 (covering ManpowerGroup’s 2026 survey). https://qz.com/skills-employers-cant-find-enough
3. KORE1, “Machine Learning Engineer Salary Guide,” July 2026. https://www.kore1.com/ml-engineer-salary-guide/
4. The AI Rankings, “AI Engineer Salary 2026: What AI Jobs Actually Pay,” August 2026. https://theairankings.com/ai-jobs/salaries/
5. Pin, “AI Compensation Benchmarks 2026,” June 2026. https://www.pin.com/blog/ai-compensation-salary-guide/
6. Rockstar Developer University, “Software Developer Hiring Statistics 2026” (citing SHRM and Workable benchmarks). https://rockstardeveloperuniversity.com/software-developer-hiring-statistics/
7. KORE1, “Time to Fill a Software Engineer Role in 2026.” https://www.kore1.com/time-to-fill-software-engineer-2026/
8. Fortune, “MIT report: 95% of generative AI pilots at companies are failing,” August 18, 2025 (covering MIT NANDA, The GenAI Divide: State of AI in Business 2025). https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
9. Let’s Data Science, “MIT NANDA’s 2025 Report Says 95% of Organizations Saw No GenAI Return” (methodology and caveats). https://letsdatascience.com/news/mit-report-documents-genai-pilot-roi-gap-e0924d7d
10. Hamel Husain, “Your AI Product Needs Evals.” https://hamel.dev/blog/posts/evals/