Build an in-house FDE team vs hire a partner
A partner gets the first system live. An in-house team is the only way to run the next twenty without asking anyone.
The short answer
Building an in-house forward-deployed team gives the company lasting capability, at the cost of time to hire and train. A partner delivers the first systems quickly, with experience you may not have yet. The strongest path for most companies is a hybrid: a partner delivers the first slices alongside a team that is growing, with a planned handover.
Decision table
| Question | In-house team | Partner |
|---|---|---|
| What it is | Engineers you hire, train and keep | An outside team that delivers named work |
| Who owns the outcome | Your company, permanently | Shared at first, then transferred at handover |
| Typical duration | Months to hire and train, then ongoing | Weeks to a first system, then the engagement ends |
| What you get at the end | A team that carries the work forward | Working systems, and a handover to your owners |
| Main risk | Slow to start, and hiring is hard | Knowledge leaves with the partner if handover is weak |
| Best for | Continuous agent work, and knowledge kept in-house | Urgent first systems, and experience you lack |
Use cases for in-house team
- Agent work that runs every quarter. A product area with a steady stream of agent changes needs people who know the systems permanently.
- Regulated work that must be explained internally. Risk and audit questions are easier to answer when the team that built the system is employed by the company.
- A company with a clear product roadmap for agents. The team can plan around known workflows, and build capacity to match.
- Knowledge that is a competitive asset. The method and the systems are part of what the company sells or relies on.
Use cases for partner
- A first system that is urgent. A workflow must reach production within a quarter, and no internal team has shipped an agent yet.
- An unfamiliar technology area. The partner brings patterns the team has not yet seen in production.
- A pilot to test whether a team is needed at all. A partner engagement shows what capability the company needs before it hires.
- Surge capacity for a defined period. A large programme needs more engineers for a fixed time, and the company will not need them after.
Trade-offs
In-house team
Advantages. Knowledge and systems stay in the company. Work can be planned around a stable team. Builds a method that compounds over time.
Disadvantages. Hiring and training take months. Strong engineers are scarce and expensive to keep. Early mistakes are made by the team that is still learning.
Partner
Advantages. Systems can reach production sooner. Experience from other engagements is available from day one. Capacity can be scaled up and down.
Disadvantages. Knowledge can leave with the partner. Dependence grows if handover is not planned. Costs continue for as long as the partner is retained.
How each option runs
In-house team, step by step:
- Step 1. Define the roles: forward-deployed engineer, evaluator, and the owner on the business side.
- Step 2. Hire the first engineers and train them on one workflow, with a method written down.
- Step 3. Add engineers as the workflows grow, and keep the method in a shared repository.
Partner, step by step:
- Step 1. Choose one workflow, with a named owner on the company side.
- Step 2. Work alongside the partner's engineers, with your own engineers in the room.
- Step 3. Plan the handover from the start: runbook, decisions recorded, and internal owners named.
What drives the effort
- How long the company needs the capability for, and how steady the demand is.
- How much time is available before the first system must be live.
- How hard the required skills are to hire in your market.
- How much knowledge the company is willing to let an outside team hold.
This site does not publish prices. The engagements page describes what each shape includes.
A checklist before you choose
- Will agent work continue for years, not one project?
- Is there a named owner inside the company for each workflow?
- Can the company hire and keep the engineers the work needs?
- Will the handover be written into the first engagement?
If the first two are yes and the last two are yes, build the team. If the first is no or the last is no, start with a partner and plan the transfer.
What people get wrong
- They hire a team before any workflow has an owner, and the team waits for direction.
- They engage a partner with no handover plan, and the system depends on them for years.
- They judge the partner on the first demo, not on the second year of the system.
A hybrid that often works
Start with a partner on one workflow, with two or three company engineers in every session. Hire the core team as the second workflow is chosen. Make the handover a written milestone, with internal owners named before the partner leaves.
Common questions
How many engineers does a team need?
It depends on the number of workflows and their change rate. Start with the workflows you can name, and add capacity when the backlog shows a real need.
How do I judge a partner?
Ask for an example of a system they handed over and how the owner ran it afterwards. The handover is the proof.
What should be in the handover?
A runbook, the decisions and their reasons, the evaluation set, and named owners. See the handover pack term.
Does a partner replace the in-house team?
Not if the work is continuous. A partner is most useful for first systems and for capacity the team cannot yet cover.