Build in-house or bring in help: deciding who does your data and AI work

Sooner or later a piece of data or AI work lands on the table: sorting out customer information, replacing a report that's still built by hand, trying an internal assistant, connecting two systems that don't talk to each other. And with it, the question of who does it. The real options are three: your current team as it stands, your current team with training, or outside help. The decision deserves more thought than it usually gets, because getting it wrong is expensive in both directions: keep everything in-house and you accumulate eternal projects nobody finishes; send everything out and you buy dependency on things you should know how to do yourselves.

The prior question: is it time, knowledge or judgement that's missing?

Before deciding who does the work, it's worth knowing exactly what's missing — because they're not the same thing, and each gap is closed differently.

Time is missing when someone on the team could do it but has no hours. Bringing in help absorbs the peak, but if the work is recurring you're permanently renting something you ought to own.

Knowledge is missing when nobody inside knows how it's done. The key question here is whether you'll need that knowledge again: learning it for a single use is a poor investment; failing to learn it for something you'll do forever is worse.

Judgement is missing when the problem isn't executing but deciding: which system to choose, where to start, whether something is worth doing at all. This is where an outside perspective adds the most, precisely because it doesn't execute — it evaluates without the weight of the house's habits.

If you can't tell which of the three is missing, you'll end up buying the wrong one: training for a problem of hours, or a vendor for a problem that was really a decision.

What belongs in-house

There are clear signals that a piece of work belongs to your current team:

• It will repeat. Whatever is part of daily operations — keeping customer data in shape, feeding a report, reviewing what an automation produces — has to be doable without calling anyone.
• It sits close to the business. The more it depends on knowledge only your people have — how each customer is handled, why that order is different — the worse an outsider will do it.
• The learning error is tolerable. If getting it wrong the first time costs little and teaches a lot, it's internal learning territory.

With one honest condition: "in-house" only exists if there are real hours. Assigning the work to the person who is already stretched, "whenever they get a moment", is deciding it won't happen — just without saying so out loud.

What training fixes

Between "we'll do it ourselves" and "let's bring someone in" there's a third path that's often forgotten: the team already has the tools — spreadsheets, a CRM, generative AI — and what's missing is method and judgement to use them well. That gap doesn't close by outsourcing the execution, because the vendor finishes and the gap is still there.

Training works when it's applied to the team's own cases, on their tasks and their data, not as a generic catalogue of possibilities. And it has a limit worth respecting: training your team solves the how, not the what. If the open question is "what should we do with AI?", that's a judgement problem, and sending it to a course is postponing it.

When the work calls for outside help

There are honest signals in the other direction too:

• The decision commits you for years. Choosing an architecture, replacing a system, defining how your data will be organised: decisions taken rarely and lived with for a long time. If nobody inside can evaluate the options independently, outside help is cheaper than the mistake.
• It's one-off and deep. Work that won't repeat and demands real craft — a migration, a delicate integration — doesn't justify anyone on the team learning it.
• The cost of getting it wrong far exceeds the cost of help. Not because of the invoice, but because of what it drags along: lost data, months of delay, burnt trust.
• You need distance. When a problem has lived in the house for years, the people inside stop seeing it; they route around it out of habit.

The dishonest signals, in both directions

Outside: be wary of the vendor whose conclusion is always that more vendor is needed, and of proposals where knowledge is never transferred. If after every project you know exactly as much as before, you're not buying help — you're buying dependency.

Inside: the pride of "we do this ourselves" has its own trap. The eternal internal project — no date, no owner, moving forward in the gaps — is the most expensive way of saying no. And one rule sorts most cases: if the work will repeat forever, the knowledge has to end up in-house, wherever the first push comes from; if it's one-off and critical, buying it done is usually wiser than learning it.

One separate decision remains, which we're not covering here: whether the help you need is a fixed project, someone alongside you over time, or another arrangement. That question comes after this one, not before.

Five questions before you decide

1. What exactly is missing: time, knowledge or judgement?
2. Will this work repeat, or is it a one-off?
3. Who inside could do it — and do they have real hours, not theoretical ones?
4. What happens if the first attempt is mediocre? Can we afford to learn?
5. If someone comes in from outside, what stays behind when they leave?

Answer these five honestly and the decision is usually made before you reach the end of the list. What you can't afford is not asking them: that's how a company ends up with a drawer full of half-finished internal projects and a list of vendors nobody remembers what they left behind.