Should we hire someone in-house for AI instead of using an integrator?
It depends less on cost than on continuity. An in-house hire accumulates deep context about your business and is available every day; the risk is that all of it lives in one person, and service businesses rarely have a second engineer to absorb it. An integrator brings patterns from many similar builds and shared maintenance; the risk is distance from your operations. The common answer is both, sequenced.
The real variable is bus factor
A single technical hire inside a non-technical company is a fragile arrangement. They have no peer review, no one to cover vacation, and no one who understands the system if they leave. In a software company that risk is diluted across a team. In a service business it is concentrated in one person who now holds the keys to your reporting.
This is not an argument against hiring. It is an argument for making sure that whatever gets built is documented, uses standard interfaces, and stores data somewhere the business can reach without that individual — the same ownership standard you would demand from an outside partner.
What each side is genuinely better at
- In-house advantage: context. They sit in the meetings, hear the complaints, and notice that the new pricing structure broke a definition. That awareness is hard to buy.
- In-house advantage: availability. Small changes happen the same day rather than entering a queue.
- Integrator advantage: pattern recognition. Someone who has connected the same category of systems repeatedly knows the traps in advance. Most first-time builds rediscover them the expensive way.
- Integrator advantage: shared maintenance. API deprecations, credential rotation and monitoring are absorbed across many implementations rather than falling on one person.
The pattern that tends to work
Build the first system with a partner, on a foundation designed to be handed over. Then hire when there is something concrete to own and enough demand for changes to justify a full-time role. Hiring first often produces a talented person spending six months building connectors that already exist.
It also gives the eventual hire a much better job. Inheriting a working system with documented mappings is a strong starting position; being handed a mandate to "figure out AI" with no data foundation is not.
A question that clarifies the decision
Ask how many distinct systems you expect to connect over the next two years, and how often your definitions change. Few systems and stable definitions favor a partner-built platform with occasional changes. Many systems, frequent change and genuinely unusual internal processes start to favor in-house capability, usually alongside custom development support rather than instead of it.
Either way, decide based on the shape of the ongoing work rather than on the first project. The first project is the smallest part of the commitment.
Topics: hiring · in-house · staffing · decisions
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.