Every company starting serious AI work hits the same fork: bring in external experts who can start next week, or build an internal team that will still be there in five years. Both camps have loud advocates, consultancies naturally argue for external, HR and engineering leaders for internal, and both are right about different things. The useful move is to stop treating it as an identity question and compare the options on the four dimensions where they actually differ: speed to start, cost profile over time, knowledge retention, and scaling flexibility.
The four dimensions that actually differ
Most external-versus-internal debates go in circles because they compare on vibes, control versus innovation, ownership versus agility. The differences that show up in budgets and delivery dates are narrower and more measurable: how fast can capability start working, what does it cost over the full duration, where does the knowledge live afterwards, and how easily can you scale the capacity up or down when the project's shape changes. Everything else is mostly downstream of these four.
The comparison, side by side
| Dimension | External experts | Internal team |
|---|---|---|
| Speed to start | Days to weeks with a vetted network; no recruiting cycle | Typically months per hire in the current German AI market |
| Cost profile over time | Higher monthly rate, but stops when the project stops; no idle or severance cost | Lower monthly cost, but permanent, salaries, benefits, recruiting fees, and it runs through quiet phases |
| Knowledge retention | Leaves with the expert unless transfer is contractually designed in | Compounds in-house; the system's context stays with the people who built it |
| Scaling flexibility | Scale up or down within weeks as project phases change | Slow both directions: hiring takes months, downsizing is costly and hard |
| Best suited for | Defined projects, scarce specialties, validation phases, deadline pressure | Long-lived core systems, durable competitive capability, steady multi-year demand |
When external experts are the right call
- Speed is the constraint: a market window, a committed deadline or an escalating problem that cannot wait out a six-month hiring cycle.
- The skill is scarce and phase-limited: senior LLM engineering to architect the system, MLOps to set up deployment, needed intensely for one quarter, not for five years.
- The project is well-defined with a clear end state, build the assistant, migrate the pipeline, harden the evaluation, so the engagement has natural boundaries.
- Follow-on demand is uncertain: paying a premium for flexibility beats committing permanent headcount to a capability you might not need at this intensity next year.
- You need to validate before you build: an external senior proving the use case in eight weeks is cheaper than discovering it with three permanent hires over a year.
When an internal team is the right call
- The system is core and long-lived: anything that touches your product's differentiation or will be operated and evolved for years belongs with people who stay.
- AI is becoming a durable capability, a portfolio of use cases, not a single project, so the fixed cost of a standing team amortizes across many initiatives.
- Deep domain context is the bottleneck: when understanding your processes and data matters more than frontier technique, tenure beats brilliance-by-the-day.
- Institutional knowledge is strategic: for regulated or safety-critical domains, having architecture decisions and their reasons live in-house is worth the slower ramp.
The hybrid path: the pragmatic default for the Mittelstand
For most mid-sized companies the honest answer is not a side but a sequence: external senior experts embedded in your organization deliver the first system at full speed, while internal engineers, existing developers or fresh hires with growth potential, work alongside them from day one with an explicit mandate to absorb the system. The externals carry architecture, hard calls and pace; the internals accumulate context, take over components as they harden, and own the system when the engagement ends. Done deliberately, pairing on real tickets, documented decisions, a staged handover plan with named dates, this converts an external engagement from rented output into a capability transfer. Done casually, with knowledge transfer as a slide rather than a plan, it produces exactly the dependency everyone fears. The difference is design, not luck, and it is worth writing into the contract: transfer milestones, joint ownership phases, and an end state where your people run the system. This is also where staffing models matter: an embedded expert matched for mentoring ability, not just technical depth, which is part of what Aiporate vets for, makes the hybrid model work in practice.
