Build vs Buy Your Platform Team

In this article

• The Real Cost of Building In-House
• What a Platform Team Actually Needs
• When Engaging a Consultancy Makes Sense
• When Building In-House Is the Right Call
• The Hybrid Model
• Red Flags to Watch For
• Making the Decision

Every few months, a CTO or VP Engineering sits us down and says some version of the same thing: “We need to build a cloud platform team. Can you help us figure out how?”

The conversation that follows is almost never about technology. It is about people, timelines, and money. The honest answer is usually more complicated than “hire five engineers” or “bring in a consultancy.”

Platform engineering has moved from conference talks to boardroom strategy. Gartner predicted that 80% of large software engineering organisations will have a platform team by 2026. Team Topologies gave everyone the vocabulary. But vocabulary and execution are different things. We see enterprises across Belgium and the EU wrestling with the same question: do we build this capability in-house, or do we buy it?

The Real Cost of Building In-House

Most enterprises underestimate the cost of building a platform team by a factor of two or three. The salary line item is the easy part. A senior cloud/platform engineer in Belgium costs between EUR 75,000 and EUR 110,000 gross annually (depending on seniority and the compensation package). But salary is maybe 40% of the actual cost.

The harder costs are time and productivity lag. A realistic hiring timeline in the current European market looks like this:

• Writing the job description and getting budget approval: 2 to 4 weeks
• Sourcing candidates, screening, interviewing: 6 to 12 weeks
• Notice period for the selected candidate: 4 to 12 weeks (Belgian notice periods are notoriously long)
• Onboarding and ramp-up to productive output: 8 to 16 weeks

That is 5 to 11 months from “we need someone” to “they are delivering value.” Per person. You do not need one person. You need a team.

Then there is retention. Platform engineers with Terraform, Kubernetes, and cloud-native experience are still in high demand. The post-2023 tech layoffs reshuffled talent at US big tech, but European enterprise demand stayed high. If your new hire gets a better offer 14 months in, you restart the cycle.

What a Platform Team Actually Needs

The most common mistake we see: an enterprise decides to “build a platform team” and hires two DevOps engineers. Two people are not a platform team. They are two people who will burn out trying to be one.

A functional platform team for a mid-to-large enterprise (50+ developers, multiple application teams) typically needs:

• 1 platform architect or tech lead who can make design decisions across networking, security, identity, and compute
• 2 to 3 infrastructure engineers who build and maintain the IaC codebase, CI/CD pipelines, and cloud foundations
• 1 person focused on developer experience (documentation, self-service tooling, golden paths)
• Part-time involvement from security and networking specialists

That is 4 to 5 FTEs minimum, plus specialist input. At Belgian market rates, you are looking at EUR 400,000 to EUR 600,000 in annual salary costs alone, before tooling, training, and management overhead.

The team also needs to cover a wide surface area: landing zones, infrastructure as code, CI/CD, container orchestration, monitoring, security posture, cost management, and developer self-service. Finding five people who collectively cover all of these and work well together is a genuine recruitment challenge.

When Engaging a Consultancy Makes Sense

Consultancies (ourselves included, so take this with appropriate salt) work best in specific situations:

You need to move fast. If you have a cloud migration deadline, a compliance requirement, or a product launch that depends on platform infrastructure being ready in 3 months, you cannot wait 11 months to hire. A consultancy can start in weeks and bring a team that has done this before.

You need specialised depth for a bounded period. Building an Azure Landing Zone is a 3 to 6 month effort that requires deep expertise. Once it is built, maintaining it requires less specialised knowledge. Paying full-time salaries for a skill set you need intensely for six months and lightly thereafter is not efficient.

You do not know what you need yet. If your organisation has never had a platform team, you might not know the right shape for one. A consultancy that has built platform capabilities for multiple organisations can help you define the target operating model before you hire into it.

You want to accelerate knowledge transfer. The best consulting engagements are not staff augmentation. They are structured to leave your internal team more capable than before. We build things like self-service infrastructure catalogs specifically so that application teams can operate independently after we leave.

When Building In-House Is the Right Call

Sometimes the answer really is “hire your own people.” These signals point that way:

Your platform is your product differentiator. If you are a SaaS company and your deployment pipeline, infrastructure reliability, or developer velocity is a competitive advantage, that capability should live in-house. You do not outsource your core.

You have a long time horizon and patient leadership. If your organisation understands that a platform team will take 12 to 18 months to reach full effectiveness and is willing to invest through that ramp-up, building in-house creates durable capability. The knowledge stays. The platform evolves with your organisation in ways that project-based engagements cannot replicate.

You already have strong engineers who want to specialise. Some of the best platform teams we have seen were seeded from existing application developers who had a knack for infrastructure and automation. They already know the organisation, the tech stack, and the politics. Training them in cloud and IaC is faster than teaching an external hire your business context.

You operate in a regulated industry with strict knowledge boundaries. Banking, defence, and some healthcare organisations have legitimate constraints on external access to systems and architecture. If a consultancy cannot touch production or see your full architecture, their effectiveness drops significantly.

The Hybrid Model

In practice, most successful platform buildouts we have been part of used a hybrid approach. The pattern looks like this:

Phase 1 (months 1 to 4): a consulting team builds the foundation. Landing zones, CI/CD pipelines, IaC structure, security baselines, and a first set of golden paths. In parallel, the organisation starts hiring.

Phase 2 (months 3 to 8): internal hires join and work alongside the consulting team. They inherit a working platform, documented decisions, and a team they can pair with. The consulting team shifts from building to coaching.

Phase 3 (months 6 to 12): the consulting team tapers off. They handle specific deep-dive projects (a Kubernetes migration, a complex networking redesign) while the internal team owns day-to-day platform operations and incremental improvements.

Phase 4 (ongoing): the internal team runs the platform. The consultancy is available for periodic reviews, architecture spikes, or capacity overflow during busy periods.

This model works because it solves the chicken-and-egg problem. You need a platform to attract good platform engineers (nobody wants to join a team with zero foundation). And you need platform engineers to build the platform. The consulting engagement breaks the deadlock.

Red Flags to Watch For

On the consultancy side: if a consultancy proposes a 24-month engagement with no knowledge transfer milestones, they are optimising for their revenue, not your capability. If they insist on proprietary tools or frameworks that only they can maintain, walk away. If they cannot explain their exit plan, they do not have one.

On the in-house side: if you have been trying to hire a “Head of Platform” for 8 months with no success, your job spec might be unrealistic. If your platform team of two is drowning in tickets and has no time for engineering, you have a support team, not a platform team. If leadership expects the platform team to “just handle cloud” without clear scope, priorities, or stakeholder alignment, the team will fail regardless of how talented they are.

Making the Decision

Skip the abstract frameworks. Answer these four questions:

When do you need the platform operational? If the answer is under 6 months, you need external help. Full stop.

What is your 18-month hiring confidence? If you believe you can attract and retain 4 to 5 strong platform engineers within 18 months, plan for in-house with a consulting bridge. If that feels unlikely given your location, brand, or compensation bands, plan for a longer hybrid model.

Is platform engineering a core competency for your business? If yes, invest in building the team even if it is slower. If the platform is a means to an end (you are a logistics company, not a tech company), a thinner internal team supplemented by external expertise is a pragmatic choice.

What does your existing engineering team look like? If you have senior developers who are curious about infrastructure, you have internal candidates for the platform team. Invest in their growth. If your engineering team is entirely application-focused with no infrastructure interest, you are hiring from scratch, and the timeline extends accordingly.

The worst outcome is not choosing the wrong model. It is choosing no model and letting the platform question drift while application teams build shadow infrastructure, each team solving the same problems differently, and accumulating technical debt that a future platform team will inherit.