Interview with CTO: Build vs Buy at Developer Tools 2025

Strategic decision areas: Build vs buy rethought

The "build vs buy" analysis in the context of developer tools has been occupying IT managers for years. In 2025, however, this question will take on a new weighting. The growing demands for modernisation, cost efficiency and speed of innovation are leading to a fundamental reassessment of this classic topic in many IT organisations. Added to this are increased expectations from the development teams themselves. In an interview with Dr Andrea Krings, CTO of a medium-sized SaaS company, current challenges, decision-making processes and new priorities in the selection and implementation of developer tools emerge. She provides concrete practical insights and explains why the choice between in-house development and purchasing is rarely a clear-cut either-or in reality.

CTOs today are faced with particularly complex trade-offs when it comes to developer experience, automation and system integration. The tool landscape remains dynamic, product portfolios are fragmented and standardisation is challenging. While solutions developed in-house used to be considered a panacea in many cases, aspects such as time-to-market, security and maintainability now take centre stage. In conversation with Dr Krings, typical lines of development, frequent pitfalls and proven methods can be identified, which offer IT managers guidance in the decision-making process.

Why developer tools make the difference

For many companies, developer tools now form the basis for both productivity and innovation. Dr Krings makes it clear that the targeted use of such solutions also has a significant impact on how employers are perceived by technical talent. "A strong developer experience is now key - tools that enable smooth processes and high-quality automation significantly increase our competitiveness," she emphasises in the interview.
Fundamental technical decisions in the area of build vs. buy go far beyond the mere tool level: they have an impact on the corporate culture, the onboarding of new colleagues, operational security and, last but not least, the motivation of the development teams. For example, sophisticated CI/CD tooling has a significant impact on efficient work processes and the willingness to innovate in engineering. Such decisions are therefore always a reflection of the technological and organisational attitude of the company.

Build vs buy: practical scenarios in the evaluation

Dr Krings' practical experience makes it clear that the path between in-house development and external purchase is rarely clear-cut. Hybrid solutions or customised hybrid forms are often the best option. Two case studies described by her illustrate this clearly:

1.Release automation through CI/CD: "We were faced with the task of automating on-premises deployments of our SaaS solution in a regulated environment. Initial approaches with open source products failed due to the extensive need for customisation, security-related aspects and the effort involved in continuous maintenance. Ultimately, we were able to reliably map the necessary SLAs and security standards with a commercial, flexibly expandable pipeline solution - comparable to GitHub Actions including enterprise support. In such scenarios, the buy approach is convincing because certified support and compliance features are crucial."

2.Customised monitoring architecture: "When it came to application monitoring, it quickly became clear that the SaaS solutions available on the market covered around 80 percent of our requirements, but lacked highly specific metrics and complex, dynamic alerting logic. Here, the pure buy solution led to noticeable compromises in compatibility. In the end, we opted for a customised in-house development based on OpenTelemetry and our own alerting engine. The initial extra effort was worth it thanks to the customised coverage of our requirements and complete development sovereignty."

Criteria for the decision-making process: The view of the CTOs

The discussion reflects a variety of evaluation criteria that go beyond purely technical analyses. Dr Krings recommends structured processes with intensive stakeholder involvement, extensive proof-of-concept phases and an honest review of the company's own personnel skills. One of the decisive factors is the total cost of ownership (TCO) over the entire life cycle. In particular, long-term maintenance costs, regular security updates and integration costs in build projects are often overlooked.

"For every decision regarding developer tools, we record both direct and hidden costs in a detailed matrix," reports Dr Krings. Factors to be considered include: the time to productive usability, flexibility of interfaces, responsibilities for security and restrictions due to closed systems. Issues such as vendor lock-in, compliance and integration into existing system landscapes often cause follow-up costs that can subsequently relativise an initially attractive buy approach. In today's complex IT environments, only gradual introduction and continuous evaluation can protect against technical legacy issues and limited scalability.

Technical depth: integration and automation as key factors

Technology decisions in 2025 will rarely be based solely on functional comparisons or graphical user interfaces. Rather, questions about API architecture, extensibility, authentication and support for modern infrastructure-as-code approaches will be decisive.

A practical example from Dr Krings' experience with an internal developer portal makes this tangible: "We set it up on an open source basis, developed custom plug-ins and realised critical security workflows specifically with commercial DevSecOps tools." The following code example shows how closely internal services are interlinked in build operation:

const createInternalPlugin = ({ httpClient }) => { return async function syncUserProjects(userId) { const projects = await httpClient.get(`/internal/projects/${userId}`); // Enrich internal data and trigger events publishCustomEvent('projects_synced', { userId, projects }); return projects; }; }

Such projects prove that the depth of integration, adaptability and automation are increasingly taking centre stage in the build vs. buy decision-making process. Proven architectural approaches - such as API-first, modern authentication (OIDC/OAuth2) or infrastructure automation via Terraform and Pulumi - are now an integral part of well-organised tech teams.

Economic and cultural implications

Economic considerations often go hand in hand with cultural and structural changes in the company. Interviews with CTOs often lead to surprising insights: Dr Krings reports that in-house developments promote strong identification within the development team and ensure a broad transfer of knowledge. At the same time, however, the risk of investing resources in costly non-core projects increases - an often underestimated problem that can manifest itself in the form of overwork and limited market presence.

In contrast, commercial tools create clear responsibilities and enable SLA-bound collaboration with manufacturers, although the innovation dynamics within the team are not always addressed equally. A customisable, transparent tool ecosystem is often more attractive than proprietary complete solutions, especially for young professionals or younger developers. CTOs are increasingly taking on the role of mediators who build bridges between traditional IT structures, agile teams and external partners. Formats such as mentoring, targeted tech talks and peer-based review processes are essential to ensure the quality of decisions.

Best practices and specific recommendations from CTO practice

Dr Krings' experiences provide tangible recommendations for CTOs in 2025: tools should be geared towards flexible interfaces and modular expansion, as requirements can change quickly. Structured proof-of-concepts that cover all phases of the development and operating process are of central importance: from local development environments and release management to monitoring, security and compliance.

Even before a new tool is introduced, it is worth developing exit strategies to enable any changes or migrations without major friction. The need for loose couplings and API-driven data exports is becoming increasingly apparent, especially for cloud-native solutions. Particularly in medium-sized IT organisations, close coordination with HR and management departments is essential, as skills in product integration, API design and multi-cloud architectures are considered essential for sustainable software provision.

Conclusion and outlook: The future of tool decisions

The interview with Dr Krings confirms that the question of build vs. buy has long since become a strategic management tool. Organisation-specific objectives, technological developments, team dynamics and economic key figures cannot be viewed in isolation, but require solution-oriented evaluation models. "Our task today is to make decisions based on the situation and with a view to readiness for change and a sustainable development path," summarises Dr Krings.

In 2025, it is clear that CTOs who regularly re-evaluate, remain open to technological and cultural changes and make decisions together with their teams will ensure greater competitiveness in the long term. The build vs. buy discussion remains an ongoing learning process that clearly benefits from active knowledge sharing and structured dialogue - as in this CTO interview.