IDP Build vs Buy for Technology & SaaS

A SaaS platform team compares building an internal developer platform against buying one, and the business case looks obvious: the vendor product costs less than two engineers for a year. Eighteen months later the product is deployed, adoption sits at four teams out of thirty, and two engineers are working full time on integrations, catalog data quality, and golden path templates. The purchase was not wrong. The estimate was, because it priced the software and ignored the work that makes any platform useful. Build versus buy is not a cost comparison. It is a question about which parts of the work you want to own, since you will own most of them regardless.

Buying moves the work. It does not remove it.

IDP build versus buy for SaaS is a decision about which layers you own, the underlying portal and orchestration versus the integrations, catalog quality, golden paths, and adoption work, given that the differentiating layers stay yours whichever way the procurement goes.

AIOps Without the Snake Oil.

AIOps can cut repetitive triage and speed investigation. It cannot replace service ownership, clean telemetry, or tested runbooks. This report separates production use cases from autonomy theater.

Download whitepaper

However, most teams compare licence cost against engineering headcount, and discover that the integration and content work is the bulk of the effort in both scenarios.

If you are a VP of Platform Engineering or Head of Developer Experience at a SaaS company, the intent of this article is:

Define which layers of an IDP are actually differentiating
Show why the buy case underestimates integration and adoption work
Lay out how to decide honestly for a multi-team org

To do that, let's start with the basics.

What Is the IDP Build vs Buy Decision for SaaS? The Basic Definition

At a high level, an internal developer platform has several layers: the portal or interface teams interact with, the orchestration that provisions and manages things, the integrations that connect it to your source control, CI, cloud accounts, and incident tooling, the catalog data describing your services and ownership, and the golden paths that encode how your org actually builds software. Buying a product gives you the first two layers and a framework for the third. The catalog data and golden paths are yours in every scenario, because they are specific to your organisation. That is the part that determines whether thirty teams use the platform, and it is also the part that never appears in the cost comparison.

To compare:

Buying an IDP is like buying a kitchen rather than building one from timber. You save real time on cabinets and plumbing. You still have to decide the layout, buy the ingredients, and learn to cook, and if the food is bad nobody cares which cabinets you chose. Most SaaS platform teams evaluate cabinets extensively and never plan the menu. The portal is the cabinets. Your golden paths are the cooking.

Why Does This Decision Matter for SaaS?

Issues that it addresses or resolves:

Cost comparisons that price software and ignore integration work
Platforms deployed but unused because the content layer was never built
Teams building portal infrastructure that a product would have provided

Resolved Issues by Deciding Honestly

Effort budgeted for the layers that actually drive adoption
Undifferentiated infrastructure bought rather than rebuilt
Ownership of golden paths and catalog data accepted upfront

Core Components of the IDP Build vs Buy Decision in SaaS

An honest inventory of which layers are differentiating for you
Integration effort estimated against your actual tool landscape
Catalog data quality treated as ongoing work, not a migration
Golden paths recognised as org-specific and unbuyable
Adoption planned as a programme, not an announcement

Modern IDP Options for SaaS

Commercial developer portals with integration frameworks
Open source portals requiring assembly and maintenance
Composed platforms built on existing tooling with a thin interface
Managed offerings that reduce operational burden
Hybrid approaches buying the portal and building the paths

These options differ mainly in how much undifferentiated infrastructure you avoid building. None of them supply your catalog quality, your golden paths, or your adoption, which is where most of the effort and all of the value sits.

Other Core Issues They Will Solve

Platform teams stop rebuilding portal infrastructure that exists
Effort concentrates on the layers unique to your org
Adoption gets planned rather than assumed

In Summary: IDP build versus buy for SaaSis a decision about which layers you own, since the integrations, catalog quality, golden paths, and adoption work remain yours in either case and account for most of the effort.

Importance of This Decision for SaaS in 2026

Platform teams are being asked to serve more teams with flat headcount. Four reasons explain why deciding well matters now.

1. The market matured, so building the portal is rarely justified.

Portal infrastructure is now well-served by products. Rebuilding it is a poor use of a small platform team.

2. The differentiating work is unbuyable.

Your golden paths encode how your org ships software. No vendor can supply that, and no product improves it.

3. Adoption failure is the common outcome.

Most disappointing IDP programmes deployed successfully. They just never got used, because nothing was there worth using.

4. Total cost is dominated by ongoing effort.

Licence cost is the visible number and rarely the largest one over three years.

Traditional vs. Modern SaaS Platform Sourcing

Build everything vs. buy undifferentiated infrastructure
Compare licence to headcount vs. compare total effort by layer
Treat catalog as a migration vs. treat catalog quality as ongoing work
Announce the platform vs. run adoption as a programme

In summary: A modern SaaS approach buys the layers that are the same everywhere and invests the team's time in golden paths, catalog quality, and adoption.

Details About the Core Components of This Decision in SaaS: What Are You Designing?

Let's go through each component.

1. Layer Layer

What is differentiating.

Layer decisions:

Portal and orchestration assessed as commodity
Golden paths recognised as org-specific
Catalog data acknowledged as permanent work

2. Integration Layer

Connecting to your tools.

Integration decisions:

Effort estimated against your actual toolchain
Custom integrations budgeted realistically
Maintenance of integrations owned by a team

3. Content Layer

What teams consume.

Content decisions:

Golden paths written for how your org ships
Templates maintained as software, not documents
Catalog quality measured continuously

4. Adoption Layer

Getting to thirty teams.

Adoption decisions:

Early teams chosen deliberately
Value demonstrated before mandate
Feedback loops from consuming teams

5. Ownership Layer

Who runs it long term.

Ownership decisions:

A named team with capacity, not a side project
Upgrade and maintenance burden accepted
Exit costs understood before commitment

Benefits Gained from Deciding Honestly in SaaS

Engineering time spent on differentiating work rather than portal plumbing
Adoption planned and resourced rather than assumed
Total cost understood across three years, not one procurement cycle

How It All Works Together

The SaaS platform team starts by separating the layers rather than comparing products. Portal interface and orchestration are commodity: every org needs roughly the same thing, and building them consumes a small team for a year with no differentiation to show for it. Buying those is usually the right call. Integrations sit in the middle: a product provides a framework, but connecting it to your specific source control, CI, cloud accounts, and incident tooling is real engineering work that scales with how unusual your toolchain is, and it needs an honest estimate rather than a vendor's implementation timeline. The content layer is entirely yours. Golden paths encode how your org ships software, which services need which controls, what a new service looks like in your world, and no product supplies that. Catalog data quality is likewise permanent work: ownership records go stale within weeks unless something keeps them current. Then adoption, which is the part that decides whether the whole investment matters. Thirty teams do not adopt a platform because it exists; they adopt it because using it is faster than not using it, and demonstrating that takes deliberate early partners, real feedback loops, and a willingness to fix what those teams complain about. The tooling decision is roughly a quarter of the problem.

Common Misconception

Buying a developer portal means we do not need a platform team.

This is the belief that turns a reasonable purchase into a shelved product. A portal with no catalog data is an empty directory. A portal with no golden paths is a nice interface to nothing. A portal with stale ownership records is worse than a spreadsheet, because people trust it briefly and then stop. Every one of those layers requires ongoing engineering effort from people who understand your org, and a vendor cannot supply any of it. The teams who buy successfully are the ones who buy specifically to free their engineers from building portal infrastructure so those engineers can spend their time on golden paths and catalog quality instead. The teams who buy to avoid staffing a platform team end up with an expensive login page and thirty product teams who never signed in twice.

Key Takeaway: Buying removes the plumbing work, not the platform team. The differentiating layers still need engineers who know your org.

Real-World IDP Sourcing for SaaS in Action

Let's take a look at how it operates with a real-world example.

We worked with a SaaS platform team whose purchased portal had four teams using it out of thirty, with these constraints:

Separate commodity layers from differentiating ones
Budget integration and content work honestly
Treat adoption as a programme with named early partners

Step 1: Separate the Layers

Commodity or not.

Portal and orchestration treated as commodity
Golden paths recognised as org-specific
Catalog quality accepted as ongoing work

Step 2: Estimate Integration Honestly

Against your toolchain.

Effort scoped to real tools, not a demo
Custom integrations budgeted
Maintenance owned by a team

Step 3: Build the Content

The part nobody sells.

Golden paths written for your org
Templates maintained as software
Catalog quality measured continuously

Step 4: Run Adoption Deliberately

Thirty teams, one at a time.

Early partners chosen carefully
Value demonstrated before mandate
Feedback acted on visibly

Step 5: Assign Long-Term Ownership

Not a side project.

Named team with real capacity
Upgrade burden accepted
Exit costs understood

Where It Works Well

Buying the portal when your requirements are ordinary
Building only where you have genuinely unusual needs
Teams that budget content and adoption work as the main effort

Where It Does Not Work Well

Buying to avoid staffing a platform team
Building portal infrastructure with a small team and no differentiation
Any approach that treats adoption as an announcement

Key Takeaway: Buy the commodity layers, build the differentiating ones, and budget adoption as the largest line item in either case.

Common Pitfalls

i) Comparing licence cost to headcount

The comparison ignores that most effort in both scenarios goes to integration, content, and adoption. Compare total effort by layer across three years instead.

The buy case looks artificially cheap
Integration work arrives unbudgeted
Adoption gets no resourcing at all

ii) Treating the catalog as a migration

Ownership data goes stale within weeks. Build automated sourcing and continuous quality measurement, or the catalog becomes another directory people stop trusting.

iii) Buying to avoid staffing

A purchased platform still needs engineers who understand your org to build golden paths and keep integrations working. Without them you have bought a login page.

iv) Mandating adoption

Telling thirty teams to use the platform produces compliance, not usage. Demonstrate that the golden path is faster than the alternative, and adoption follows without a memo.

Takeaway from these lessons: The decision is about which layers you own, and the failure mode in both directions is underestimating the content and adoption work.

IDP Sourcing Best Practices for SaaS: What High-Performing Teams Do Differently

1. Separate commodity from differentiating

Buy the portal and orchestration if your needs are ordinary, and spend your engineers on golden paths, because that is where the value actually is.

2. Estimate integration against your real toolchain

Scope the work using your actual source control, CI, cloud, and incident tools, not the vendor's reference architecture.

3. Treat catalog quality as permanent

Automate sourcing of ownership data and measure freshness continuously, since a stale catalog destroys trust faster than no catalog.

4. Resource adoption like a product launch

Choose early partner teams, demonstrate real time savings, act on feedback visibly, and let usage spread on merit rather than mandate.

5. Understand the exit before you commit

Know what leaving costs, in both directions, because platform decisions outlive the people who make them.

Logiciel's value add is helping SaaS platform teams make the build versus buy decision by layer rather than by licence cost, then build the golden paths and catalog quality that determine whether thirty teams actually use the thing.

Takeaway for High-Performing Teams: Buy the plumbing, build the paths, and budget adoption as the main effort rather than an afterthought.

Signals You Are Doing This Well in SaaS

How do you know it is working? Not by whether you shipped a portal, but by whether teams choose it. These are the signals that separate a used platform from a deployed one.

Teams use it voluntarily. Adoption grew without a mandate.

Golden paths are faster. Using the platform beats the alternative on time to production.

The catalog is trusted. Ownership data is current enough that people rely on it.

Engineers work on content. Your team spends its time on paths, not on portal maintenance.

Costs were predicted. Three-year effort matched the estimate reasonably well.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. IDP sourcing depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

Golden paths determine whether the platform is worth using. Your service catalog determines whether it can be trusted. Self-service infrastructure is what the portal actually invokes. Developer experience metrics tell you whether adoption is producing value. Naming these adjacencies upfront keeps the work scoped and helps leadership see the purchase as one input rather than the solution.

The common mistake is treating each adjacency as someone else's problem. The golden paths are your problem. The catalog quality is your problem. The adoption programme is your problem. Pretend otherwise and you own an expensive portal nobody visits. Own the adjacencies you depend on, partner with the teams that hold them, and share the roadmap.

Conclusion

Build versus buy is a question about which layers you own, not a cost comparison. Portal interface and orchestration are commodity, and rebuilding them consumes a small platform team for a year with nothing differentiating to show. Integrations are real work in either case, scaled to how unusual your toolchain is. Golden paths and catalog quality are entirely yours and no product supplies them, which is inconvenient because they are the layers that decide whether thirty teams use the platform at all. Buy the plumbing, build the paths, and budget adoption as the largest line item. The teams who fail at this usually bought correctly and then stopped.

Key Takeaways:

Buying moves the work rather than removing it; the differentiating layers stay yours
Golden paths and catalog quality determine adoption and cannot be purchased
Most disappointing IDP programmes deployed successfully and were never used

Deciding well requires honest scoping. When done correctly, it produces:

Engineering time spent on differentiating work rather than portal plumbing
Golden paths that are genuinely faster than the alternative
A catalog current enough that teams trust it
Adoption that grows on merit rather than by mandate

Agentic AI for Real Estate Operations: An Executive Blueprint.

The technology to automate a third of your operations already works. The hard part is that most firms buy it and watch it stall within 90 days. This blueprint is about landing on the right side of that gap.