Greenfield IDP build cost: year 0 to year 1, $400k to $1.2M

What greenfield means here

"Greenfield IDP build" describes the transition from no dedicated platform team and no formal IDP to a functioning platform with at least one golden path, a working service catalogue, and operational ownership of the foundational developer-facing capabilities. Most organisations cross this threshold between 50 and 100 engineers.

Before the greenfield build, the organisation typically looks like: engineers running CI/CD pipelines they configured themselves (with significant variation per repository); observability that is a mix of cloud-provider defaults, team-level dashboards, and ad-hoc Slack alerts; service catalogue that lives in a spreadsheet, a Notion page, or nowhere; secrets management that is inconsistent across teams; production incidents handled by whichever engineer happens to be available.

After year one of the greenfield build, the organisation looks like: a platform team of 2 to 5 engineers; one golden path shipping new services consistently; CI/CD with consistent secrets handling across major repositories; an observability foundation with paging integration and basic dashboards; a service catalogue with ownership and runbook data covering most services; the beginnings of an on-call discipline for production incidents.

The transition is the most expensive year of platform engineering the organisation will ever do per engineer of capacity delivered. Year two and onward are dramatically cheaper per unit of platform value because the foundational decisions are already made and the team is already in place.

The first 90 days

The first quarter of a greenfield build has three concrete deliverables:

• Hire 1 to 2 senior platform engineers. The first hire is the lead, typically a staff-level engineer with prior platform-engineering experience. The second hire is usually a senior who can absorb the operational work as the lead focuses on architectural decisions. Total cost of the hires: $20k to $40k in recruiting overhead (agency fees if used, internal interview time amortised) plus the loaded salary cost from the day they start.
• Lock in the major buy-vs-build decisions. Which CI/CD vendor? Which observability stack? Which IDP approach (hosted Backstage, commercial IDP, self-hosted Backstage)? Which secrets-management product? Which container orchestration platform? Each of these decisions has 3 to 5-year implications, so the time pressure is to make them deliberately within 60 to 90 days rather than to ship them immediately.
• Ship the first quick-win. Typically a working CI/CD setup with consistent secrets handling across the 5 to 10 most important repositories. The goal is not perfection; the goal is visible evidence that the platform team exists and is delivering value, so that internal credibility for the larger investment is established.

Total first-90-day spend is typically $80k to $200k, mostly hiring cost and initial vendor commitments. The platform team is small enough at this stage that the salary line is modest; the larger lines are the tooling-decisions that have multi-year cost implications.

The next nine months

Months 4 through 12 are the build-plus-adoption phase. The work breaks down roughly:

• Months 4 to 6: foundation. Roll out the observability stack across all services with basic dashboards. Roll out the secrets-management product. Roll out the service catalogue (typically hosted Backstage or a commercial IDP) and import the initial ownership data. Start standardising CI/CD pipelines across remaining repositories. Hire the third platform engineer if not already hired.
• Months 7 to 9: first golden path. Design and implement the first golden path, typically for the most common service type (web service). Test with one or two friendly teams. Iterate based on feedback. Document the path. Build internal credibility through the early adopters.
• Months 10 to 12: adoption. Roll the golden path out to the broader engineering organisation. Office hours, training sessions, scorecard launches. Track adoption metrics. Tune the path based on real usage patterns. Begin scoping the second golden path for year two.

Platform-team spend across this period: typically $300k to $750k loaded for the 2 to 4-engineer team operating across the nine months. Plus tooling commitments that ramp from the initial procurement to steady-state ($100k to $300k annual run-rate by month 12). Plus cloud infrastructure for the new platform components ($30k to $80k annual run-rate by month 12).

What ships vs what slips in year one

Across the typical greenfield build, the year-one ship-list is:

• Platform team of 2 to 4 engineers, with stable rotation pattern.
• One golden path live with adoption underway.
• Consistent CI/CD across major repositories.
• Observability foundation with paging integration.
• Service catalogue with ownership data covering most services.
• Secrets management with rotation policies in place.
• On-call rotation for the platform itself with reasonable escalation.

The typical year-one slip-list includes:

• Second golden path (often planned, rarely shipped).
• Adoption depth on the first golden path (path ships, but only 30 to 50 percent of new services adopt it; the rest continue with their own patterns until year two).
• Per-team observability dashboards and SLO tracking (the foundation ships, the per-team work slips).
• Mature scorecards (basic ownership scorecard ships, broader rubric slips).
• Self-service environment provisioning beyond what stock vendor products provide.

Planning for the slips honestly is the difference between a year-one build that engineering leadership perceives as successful (because expectations were calibrated) and one perceived as struggling (because expectations were not).

The over-confidence trap

The most common failure mode of greenfield builds is over-building in year one. The pattern: by month 6 the platform team has shipped the foundational work and is feeling good about progress. They start planning the next batch of capabilities (FinOps integration, multi-region operations, deep scorecard authoring, mature self-service infrastructure) while adoption of the first batch is still shallow.

The trap is investing in increasingly sophisticated capabilities while the foundational adoption work is incomplete. A platform with one well-adopted golden path is more valuable than a platform with five lightly-adopted ones; a service catalogue with 95 percent ownership coverage is more valuable than a catalogue with 60 percent coverage and five integrations. The platform team that does not internalise this tends to ship a wide capability surface in year one and discover in year two that adoption stalled and the wide surface is hard to maintain.

The discipline that prevents this: rigorous prioritisation of adoption depth on existing capabilities before scope expansion to new ones. Concretely, do not start the second golden path until the first golden path has reached 60 to 70 percent adoption in its category. Do not start the FinOps work until the observability foundation is genuinely delivering value to engineering teams. Etcetera.

Realistic month-12 ROI signals

A greenfield build at month 12 should produce these signals:

• The first golden path has produced hours of saved engineering time per new service (typically 8 to 16 hours per service, depending on how complex the previous service-creation process was).
• CI/CD pipeline consistency means build-time variance is materially lower than month zero (typical signal: P95 build time within 25 percent of P50, rather than 200 to 400 percent as is common in greenfield).
• Basic observability foundation means incidents are being triaged from one location rather than requiring engineers to assemble context from multiple tools.
• Service-catalogue ownership data covers at least 80 percent of services and engineers trust the data enough to use it for the "who owns this" question.
• Platform-team on-call response is consistent and incident-recovery times are shorter than month zero.

What you should NOT expect at month 12: dramatic deployment-frequency improvements at the organisation level (those typically appear at month 18 to 24); a full DORA Elite tier profile (typically appears at year 3 if at all); measurable engineer retention improvements attributable to the platform (the signal is real but typically takes 18 to 24 months to be statistically visible).

The bigger ROI conversation typically lands at month 18 to 24, when adoption depth catches up with capability scope and the platform's value is visible enough to be measured. Year one is investment; the return shows up later. See /roi for the broader ROI framework.

Comparison to brownfield and to mature platform investment

Greenfield is the most expensive year of platform engineering per unit of capability delivered. After year one, the same team continues to deliver platform value at much lower marginal cost because the foundational decisions are already made, the team is already in place, and adoption work compounds.

For an organisation that already has informal platform-engineering work happening (engineers spending 20 to 30 percent of their time on platform-flavoured tasks across multiple teams), the brownfield IDP build is meaningfully cheaper because much of the foundational work is already done. The challenge is consolidation rather than greenfield build.

For corresponding org-size cost pictures see /cost-for-50-developers and /cost-for-100-developers.

Cost bands triangulated from CNCF Platforms Working Group case studies, public adoption write-ups from organisations that have completed greenfield builds, Team Topologies framework material, and the multi-source salary reconciliation. Verified 2026-05-11.