In-House Team vs Implementation Partner
Building your own Salesforce team and bringing in a partner both have real costs. This guide sets out when each makes sense and how a hybrid model can give you both.
Most Salesforce programmes eventually face the resourcing question: hire and build an internal team, bring in an implementation partner, or combine the two. Each option has real costs that are easy to underestimate. As a consultancy we have an obvious interest here, so this guide tries to be straightforward about when you do not need outside help.
What an in-house team does well
- Continuity. Your people know the business, the politics and the history of every odd configuration decision.
- Ownership after go-live. Someone has to run the platform every day. An internal team does this naturally.
- Lower cost over time for steady, predictable work, once the team is hired and up to speed.
- Faster small changes. No contract, statement of work or onboarding for a new field or report.
The challenges are hiring time, breadth of skills and single points of failure. One experienced admin can run a stable org, but the same person is unlikely to be equally strong in Data Cloud, Marketing Cloud, integration design and Apex.
What an implementation partner does well
- Speed to start. A partner can begin within weeks rather than waiting on recruitment.
- Breadth of skills across products you only need occasionally, such as data migration, Data Cloud identity design or deliverability.
- Pattern experience. Seeing many implementations helps a partner spot design problems early.
- Flexible capacity for a peak, a migration or a specific build, without permanent headcount.
The risks are cost for long-running work, knowledge leaving when the engagement ends, and designs that the internal team does not fully understand.
How the options compare
| In-house team | Implementation partner | Hybrid | |
|---|---|---|---|
| Time to start | Slow, hiring first | Fast | Moderate |
| Depth across products | Limited by team size | Broad, on demand | Broad where needed |
| Knowledge retention | High | Low unless planned | High if pairing is deliberate |
| Cost profile | Fixed, lower for steady work | Variable, higher per day | Mixed |
| Flexibility | Low | High | High |
| Best for | Ongoing operation and small changes | Large builds, specialist work | Most growing organisations |
Decision criteria
- Is the work a project or a permanent capability? A one-off migration suits outside help. Running marketing automation every week is a permanent capability that should live inside.
- How specialised is it? Rare skills you need for a few months are expensive to hire for.
- How urgent is it? If a deadline is fixed, hiring time may make the decision for you.
- Who will own it afterwards? If nobody internal will own what is built, neither option will succeed for long.
- How mature is your governance? A partner works best with a clear product owner, decision-making process and backlog. Without them, an internal team is better placed to establish those foundations. See programme governance for growing teams.
Hybrid models that work
The most durable setup for many organisations is a small internal core (a product owner, a lead admin, perhaps a developer) supported by outside specialists for projects and peaks. Common shapes:
- Partner-led build, internal-led run. The partner delivers the implementation with your team embedded, then hands over.
- Specialist augmentation. A consultant joins your team for a defined skill or period. See specialist resource support.
- Ongoing support alongside an internal admin. Outside help covers specialist products and overflow while your admin owns the day to day.
Making outside help leave you stronger
Pair on everything
Make sure an internal person works alongside the partner on design and build, not just in final handover sessions.
Own the backlog
Keep the product owner and prioritisation inside your organisation, so decisions reflect your goals.
Insist on documentation
Ask for design decisions, data dictionaries and runbooks as named deliverables. Our data dictionary template is a useful starting point.
→Keep access and credentials yours
Your organisation should own every org, integration user, repository and credential.
Plan the exit from day one
Agree what handover looks like before the work starts, including knowledge transfer sessions and a support period.
Our view: it depends on whether the work is a project or a capability
If the work is ongoing and predictable, build it inside. If it is specialised, time-bound or urgent, bring in help, and structure the engagement so your team owns the result. Most organisations benefit from a mix, adjusted as the internal team grows. If you are evaluating firms, our guide to choosing an implementation partner and the Salesforce RFP template will help you compare them fairly. Our own options are described on engagement models.
Questions we hear
How do we avoid dependency on a partner?
When should we hire our first Salesforce admin?
Is a partner more expensive than hiring?
Can a partner work inside our sprints?
What should we ask a potential partner?
Work out the right mix
Tell us about your team and your plans, and we will give you a frank view of where outside help adds value and where you should build internally.
