.svg)
Every internal platform is a stack of decisions: build a component from scratch, adopt an open-source project, or buy from a vendor. At KubeCon Paris, I moderated a panel with platform engineers from Saxo Bank, the LEGO Group, Chainalysis, and Wolt on how they make that call. This article compiles the key insights from that conversation.
How to decide: the short answer
The panel's collective guidance boils down to three rules:
- Buy when a vendor is years ahead of what your team could build, the problem is not your differentiator, and the vendor uses open standards so you keep ownership of your data.
- Adopt open source when the project has a healthy community, credible backers, and a sustainable business model behind it, and when hiring engineers who already know the tool matters to you.
- Build when nothing off the shelf meets your compliance, security, or scale constraints, and you can staff a team to maintain it long after launch.
Whichever mix you land on, the panel agreed on one constant: treat the platform as a product, and plan for the operational work that starts after launch, not just the initial decision.
Comparing the three approaches
Buying from a vendor
Best when: the vendor's engineering is far ahead of what you could build in a reasonable timeframe.
Advantages: speed to value, dedicated support, someone else carries the maintenance burden.
Risks: vendor lock-in, long-term cost commitments, integration work that starts after the contract is signed.
Adopting open source
Best when: a project with a healthy community and credible commercial backing solves your problem.
Advantages: no licensing lock-in, and a hiring pool of engineers who already know the tool.
Risks: open source is not free. Without a sustainable business model behind the project, you inherit the maintenance risk.
Building in-house
Best when: your compliance, security, or scale requirements rule out existing options.
Advantages: exact fit for your needs, full control over the roadmap.
Risks: you own everything, forever. Reliance on a few hero developers becomes a business continuity problem as the platform grows more critical.
Platforms drive compliance and developer experience
The implementation and goals of a platform vary from company to company, but you have to build toward tangible goals, as Victor Araujo, Senior SRE at Wolt, noted.
For larger organizations, simplifying compliance is a primary platform objective, according to Jinhong Brejnholt, Chief Cloud Architect and Global Head of Cloud and Container Platform Engineering at Saxo Bank. In a regulated industry like banking, providing battle-tested and scrutinized building blocks lets developers deliver value without repeatedly fighting the same compliance battles.
Leena Mooneeram, Senior Engineer (Platform & DevEx) at Chainalysis, pointed to reducing the cognitive load on developers as a main driver. Designing platform components with smart defaults and useful abstractions simplifies developers' work.
Platform teams can also act as facilitators between service providers and consumers within an organization. Enabling inner sourcing, the practice of applying open-source collaboration patterns to internal code so teams outside the platform team can contribute components, allows the platform to scale beyond the team that builds it.
Buying software is much more than paying
When a vendor has built something potentially years ahead of you in engineering terms, buying is the obvious choice. But costs and long-term commitments weigh heavily when you bring a vendor into your platform.
After signing, significant work remains to integrate the vendor's solution into your ecosystem. Watch for lock-in: prioritize vendors that use standard or open-source protocols, and make sure you own your data.
The panelists recommended developing a close relationship with your vendors to stay aligned as the ecosystem evolves. They also preferred buying in competitive markets. A monopolistic vendor is a future pricing or licensing problem waiting to happen.
Open source: tips for long-term success
Adopting open-source software takes more evaluation than counting GitHub stars. Assess the community's health and the project's backers before betting on long-term support.
Open source is not free. A project without a sustainable business model behind it is a risk, so understanding the commercial landscape around a project is part of estimating whether it survives.
Victor noted that adopting OSS also helps recruiting: you can hire people who already know the tool instead of training them on proprietary software from scratch.
Day-2 operations: future-proofing your platform
Day-2 operations covers everything required to run and evolve a platform after its initial launch: upgrades, replacing components, scaling, and responding to incidents. Platform teams must continuously evolve their platforms based on user needs, technological change, and what they learn along the way.
Jinhong argued that replacing components that no longer fit is a sign of health, and that a competent, adaptable team matters more than any single technology choice.
Edgaras Petovradžius of the LEGO Group added that a close vendor relationship keeps the roadmap aligned with your objectives. The same applies to open source: being an active community member mitigates the risks of OSS adoption.
Taking your platform forward
Platforms managed as products are the most effective. Listen to your customers, make sure you're meeting developers' needs, and enable them to do more rather than imposing another tool.
Staff the platform properly. Reliance on hero developers is a significant business continuity risk as the platform becomes more integral to the organization.
Curious to hear the full conversation? Watch the full panel recording on YouTube.
