Consulting Partner or In-House AWS Team? A Build-Versus-Buy Cost Model

Build-versus-buy decisions on cloud engineering capability are usually made on a comparison that is not a comparison. One side of the sheet has a partner's annual fee. The other has salaries. The salaries look smaller, the decision gets made, and eighteen months later the organisation is carrying a half-staffed team and a backlog.

The model below is deliberately structured to make the two sides commensurable. It is not a recommendation — for a genuinely continuous roadmap across many teams, building is usually right — but it forces the comparison onto the lines that actually differ.

Key Takeaways

• Salary is roughly half the true cost of an internal engineer once recruitment, ramp, management, and benefits are counted.
• The crossover point is a function of roadmap continuity, not organisation size.
• Time-to-first-value differs by months and is worth pricing, because an estate running unimproved has a carrying cost.
• Key-person risk is the hidden liability of a small internal team and the reason two-person teams so often fail.
• The hybrid shape — small permanent core, partner capacity around it — is not a compromise; for most mid-size enterprises it is the lowest-cost stable answer.

Building the Model Honestly

The internal side

Start with the fully loaded cost of an engineer, not the salary. In the US and UK, employer taxes, benefits, equipment, software licences, and workspace typically add a substantial multiple to base pay. Then add the lines that only exist because you are building rather than buying.

Recruitment. Agency fees or an internal recruiting allocation, plus the hiring manager's time. Senior cloud engineers are among the harder roles to fill, and the search is rarely short.

Vacancy. The estate is not improving while the role is open. This is a real cost and almost never appears on a business case. If a modernisation programme is worth doing, every month it is not happening has a value.

Ramp. New engineers are not productive on day one. On a complex estate, meaningful productivity commonly takes one to three months.

Management. A team needs a lead, and the lead's time is not delivery time.

Attrition. Assume it. A team of four with an eighteen-month average tenure is re-hiring roughly twice a year, and each cycle re-incurs recruitment, vacancy, and ramp.

The partner side

Start with the contracted fee, then add what the partner does not carry.

Your internal owner. Someone senior must hold the architecture and the relationship. This is not optional and it is not junior.

Your team's time. Discovery, access, decisions, review, testing support. Substantial in year one.

Knowledge-transfer cost. Documentation, pairing, and the deliberate slowdown of having your people learn while the partner works. Skipping it saves money now and creates dependency later.

Transition or exit cost. What it takes to move to another provider or bring it in-house. Worth pricing even if you never use it.

Where the Crossover Actually Sits

The variable that decides this is not headcount or revenue. It is whether the work is continuous.

Continuous roadmap. Multiple product teams shipping regularly, an ongoing migration programme, a platform with an indefinite owner. Here an internal team wins clearly after the first year, because the fixed costs of building the capability amortise across sustained demand and institutional knowledge compounds.

Bursty roadmap. A modernisation push, then steady state. Here a partner wins, often decisively, because you are not paying for a bench through the trough and you are not carrying the recruitment cycle for a demand curve that has already passed.

Mixed. The common case, and the reason the hybrid model dominates. A small permanent core covers steady state and holds the knowledge; partner capacity flexes with the peaks.

The judgement call is honest forecasting. Most organisations describe their roadmap as continuous during a business case and discover it was bursty during year two. Testing that assumption against the last three years of actual delivery is a useful discipline.

Time to First Value

An internal build has a start-up delay that a partner engagement does not. Defining roles, recruiting, notice periods, onboarding, and ramp put months between the decision and the first useful output. A partner engagement can begin within weeks.

That gap has a price. If the modernisation is worth what the business case claims, the months of not doing it cost something, and that cost belongs on the internal side of the sheet. It is frequently the largest single differentiator in the first year, and it is almost never modelled.

The corollary is that these are not mutually exclusive in sequence. Engaging a partner to start while recruiting in parallel is a legitimate and common pattern — it buys momentum without giving up the long-term position. Our comparison of offshore and in-house engineering teams covers the staffing variant of the same trade-off.

Key-Person Risk

Small internal teams concentrate knowledge, and the concentration is the risk. In a three-person team, one person usually understands the network topology, one understands the identity model, and one understands the pipeline. Any departure removes a category of understanding, not a fraction of capacity.

This is why teams below roughly five engineers are fragile in a way the cost model does not show. Mitigations exist — documentation, pairing, deliberate rotation — but they all cost delivery time, which means the effective capacity of a small team is lower than its headcount suggests.

Partners carry this differently. They have a bench, and the contractual obligation to maintain service does not depend on one individual. In exchange, you carry a different risk: the knowledge lives outside your organisation unless you have contracted for it to move inside. Both risks are manageable, and neither is manageable by accident.

Governance Either Way

Whichever route you take, three things need an owner with a name.

Architecture decisions. Provider-native versus portable tooling, account structure, network design, identity boundaries. These have long half-lives and are expensive to revisit.

Cost accountability. Someone must own the cloud bill and have the authority to act on it. Unowned cloud spend rises without anyone deciding it should. The patterns are covered in our notes on where cloud spend accumulates.

Security posture. Identity, boundaries, secrets, and audit evidence. A partner can implement it; accountability stays with you. The same applies to the reliability practice that grows around a maturing estate.

If these three do not have named internal owners, the build-versus-buy decision is somewhat academic — the estate will drift either way.

Running the Comparison

A workable process takes about two weeks. Model four years rather than one, because the first year flatters the partner and the fourth flatters the internal team, and the truth is in the shape of the curve.

Include every line above on both sides. Sensitivity-test the two assumptions that matter most: roadmap continuity and internal attrition rate. If the answer flips when attrition moves from eighteen months to thirty, you have learned something more useful than the headline number.

Then, whichever way it points, contract for the transition. If you build, budget partner support for the first year while the team ramps. If you buy, contract knowledge transfer with a defined handover point. The failure mode in both directions is treating the decision as permanent when it is a position on a curve. IdeaGCS works both sides — delivery automation services where the requirement is delivered capability, specialist hiring services where it is people.

Conclusion

The comparison is only meaningful when both sides carry their full cost. Salary alone understates an internal team by roughly half; a partner fee alone understates the buy option by the internal owner, your team's time, and the knowledge transfer that has to be paid for one way or another.

Model four years, sensitivity-test roadmap continuity and attrition, and price the months of delay that an internal build entails. For most mid-size enterprises the answer that survives the model is a small permanent core with partner capacity around it — not because it is a compromise, but because it is the cheapest stable arrangement available. Talk to IdeaGCS if you want the model run against your own numbers.