Accelerating Tech Development: Make, Buy, or Borrow in Platform Engineering
Technology leaders in platform engineering face a pivotal decision that quietly determines whether their platforms become accelerators or bottlenecks: should they build capabilities in-house, purchase them from vendors, or leverage existing ecosystems and expertise?
These choices directly impact time-to-market, developer velocity, security posture, and long-term sustainability. When done well, organizations unlock compounding gains—faster releases, happier developers, and resilient platforms. When done poorly, they accumulate tooling debt, fragmented workflows, and stalled innovation.
Leading companies like Netflix, Spotify, Uber, and Capital One have shown that acceleration rarely comes from a single strategy. Instead, it comes from deliberate blending of make, buy, and borrow, guided by clear principles and reinforced by strong DevSecOps and platform engineering foundations.
Understanding Make, Buy, and Borrow in Platform Engineering
At its core, platform engineering exists to reduce cognitive load for developers while increasing delivery speed and safety. The make–buy–borrow framework helps leaders decide where engineering effort is best spent.
- Make involves building bespoke tools and platforms in-house, often on top of cloud services and open source. This is justified when the capability encodes a competitive advantage or regulatory nuance that cannot be commoditized.
- Buy means adopting SaaS or managed platforms—CI/CD, observability, security tooling, internal developer portals (IDPs)—to achieve fast, reliable outcomes using vendor roadmaps.
- Borrow leverages existing internal assets, open-source ecosystems, or external experts to accelerate adoption without reinventing the wheel.
The most effective organizations blend all three. Over-investing in “make” creates maintenance drag. Over-buying leads to vendor sprawl. Borrowing without intent risks long-term dependency. Acceleration lies in choosing deliberately.
Why Is Acceleration a High-Stakes Platform Problem?
Platform teams don’t ship customer features directly—but every product team depends on them. A slow platform decision today can delay multiple releases tomorrow.
Faster CI/CD pipelines shorten feedback loops. Unified observability reduces mean time to recovery. Secure, self-service IDPs eliminate ticket queues. Conversely, fragmented tooling, manual compliance steps, and inconsistent pipelines silently tax every engineer.
Industry benchmarks consistently show that optimized DevSecOps and platform practices can:
- Increase deployment frequency by 2–5x
- Reduce change failure rates by 30–50%
- Improve developer satisfaction and retention meaningfully
The hidden cost is opportunity. Senior engineers maintaining undifferentiated tooling are not innovating. In regulated industries—BFSI, healthcare, and life sciences—poor platform choices compound risk and compliance exposure.
When to Make: Building for Strategic Speed
“Make” is the right choice when the capability is the product or when it encodes deep operational differentiation.
Netflix’s decision to build Spinnaker is a canonical example. At massive microservices scale, off-the-shelf CI/CD tools couldn’t support progressive delivery, region-aware rollouts, and Chaos Engineering experiments. By building Spinnaker, Netflix reduced deployment cycles from days to minutes and enabled thousands of safe releases daily.
Similarly, regulated enterprises often build custom compliance-aware pipelines. Capital One’s internal golden paths enforce security and regulatory controls by design, allowing teams to move fast without repeated audits or approvals.
Making works when:
- Requirements are stable and long-lived.
- Deep domain expertise exists.
- Leadership commits to operating the platform as a product.
Without these, “make” slows velocity rather than accelerating it.
When to Buy: Fast Wins with Proven Platforms
Buying is often the fastest path to acceleration—especially for capabilities that are important but not differentiating.
Spotify’s adoption of Backstage illustrates this well. Instead of building an IDP from scratch, Spotify embraced an emerging ecosystem, rapidly standardizing service discovery, documentation, and self-service workflows for thousands of engineers. Productivity gains were realized in months, not years.
Uber’s use of GitLab for CI/CD reduced pipeline setup time from weeks to hours by pairing a bought platform with internal templates. Slack’s adoption of Datadog unified observability, cutting debugging time by nearly 40% during hyper-growth.
The key to sustainable buying is abstraction. Successful teams isolate vendor-specific concerns behind interfaces, ensuring that speed today doesn’t become lock-in tomorrow.
When to Borrow: Jumpstarting Velocity with Ecosystems and Expertise
Borrowing accelerates early momentum. It’s ideal when teams want to validate patterns, bridge skill gaps, or move quickly without long-term commitment.
Airbnb borrowed Kubernetes patterns internally and contributed upstream rather than building orchestration tooling from scratch. This halved setup times while benefiting from community innovation.
Borrowing also includes leveraging experienced platform and DevSecOps practitioners to bootstrap foundational capabilities—pipelines, security automation, and IDPs—while transferring knowledge to internal teams. In these scenarios, the goal isn’t outsourcing ownership but compressing the learning curve.
Borrowing works best when it’s intentional:
- Time-boxed experiments
- Clear handoff plans
- Defined criteria for when to make or buy next
A Practical Decision Framework for Leaders
To avoid ad hoc decisions, platform leaders should evaluate make, buy, and borrow across five dimensions:
- Strategic Fit – Is this a differentiator or a commodity?
- Time-to-Value – Do we need results in weeks, or can we invest for years?
- Capability & Capacity – Do we have the skills and bandwidth today?
- Lifecycle Cost – What is the true TCO, including operations and change?
- Risk – Lock-in, security exposure, compliance, talent dependency
Many high-performing teams score each option quantitatively and revisit decisions quarterly as priorities shift.
