EUR 2.1M for Graftcode to Eliminate Traditional Integration Complexity

• Warsaw-based developer platform Graftcode raised EUR 2.1M Seed funding led by Hard2Beat
• The startup’s founders previously built Javonet, enabling cross-platform runtime bridging for enterprises
• The new platform uses runtime bridging to remove APIs, middleware, and integration code layers
• With the funding injection, the company aims widespread adoption, targeting major developer and enterprise ecosystems globally

This April, the Polish developer tools startup Graftcode received EUR 2.1M Seed funding from the well-known Polish VC fund Hard2Beat (invested in Neuromedical, among others) as the lead investor, joined by another renowned Polish fund Digital Ocean Ventures (invested in Replenit, among others) and HEALTFELT_ (invested in Tingit, among others). The investment round coincided with Graftcode’s beta launch.

Founders and Their Early Problem Discovery

Graftcode’s co-founders are brothers Przemysław (CEO) and Łukasz (COO) Ładyński who have been building software most of their lives. The two started coding and founded their first company quite early to work together on a wide range of projects, including e-commerce platforms and large-scale healthcare systems. Along the way, the two kept running into the same problem: sharing software pieces in a single service or app was seamless, but cross-technology or remote integration was always a tremendous task occupying well over half of entire project development.

This inspired them to build Javonet, a runtime-bridging technology that enabled direct in-memory communication between platforms like Java and .NET. It was adopted by enterprise clients including Premier Bank, TotalEnergies, and IQVIA, which validated both the need and the approach within the use case of building monolith polyglot applications. Graftcode came out as a natural evolution of that work: once the concept was proved at an enterprise level in this niche use-case, the next logical step was to make this capability accessible to every possible software integration scenario.

Industry Critique of Integration Complexity and Evidence of Integration Overhead

‘For a long time, the industry has accepted integration as a necessary complexity. System connection depends on controllers-based—REST/SOAP—and IDL-based—thrift, gRPC—APIs, middleware, and the client code to consume them. Everyone has been so focused on standardising and optimising these layers that they have forgotten to question whether these layers should exist at all. What has escalated recently is the overall scale of the problem, in view of the rise of microservices and AI-driven workflows that require far more system interactions. The integration layer itself has become the bottleneck. Developers and AI spend too much time and over half of the codebase producing, analysing, understanding and debugging. It’s not easy to rethink something as major as integration from first principles, so it’s not surprising that this didn’t happen earlier,’ the CEO tells ITKeyMedia.

Indeed, software integration remains one of the largest consumers of engineering resources:

• The research from Forrester suggests that as much as 70% of development effort is spent connecting front-end, back-end, and third-party systems rather than creating new functionality.
• This complexity contributes significantly to technical debt, which McKinsey estimates accounts for roughly 40% of IT assets and increases project costs by 10–20%.
• Deloitte further estimates that technical debt costs organizations in the US alone around USD 1.5T annually.

As companies scale AI initiatives, these challenges become even more pronounced, with fragmented integration architectures creating barriers to reliable and scalable AI-driven workflows. The Gartner research predicts that this will lead to widespread abandonment of AI projects by 2027.

Runtime Bridging as the Direct Method Communication Model

‘With over 20 million developers globally, the need for simpler ways to connect software systems is only growing. This challenge becomes even more critical as companies build increasingly complex, AI-driven applications. Graftcode introduces a fundamentally new approach that has the potential to reshape how developers build and scale modern software,’ Hard2beat’s partner Maciej Zawadzinski comments.

Graftcode tackles those software integration challenges through a technology it calls ‘runtime bridging,’ enabling applications built in different programming languages to communicate directly without relying on APIs, middleware, or custom client libraries. Rather than spending time developing and maintaining complex integration layers, developers can establish connections between services using a single command that automatically generates the necessary components. The platform already supports 14 programming languages and works across major cloud providers, including AWS, Azure, and Google Cloud. It covers a broad range of integration scenarios and claims to deliver up to 70% faster service interactions, reducing cloud infrastructure costs by as much as 10%.

The core assumption behind Graftcode’s runtime bridging is that communication between systems does not need to rely on integration-method-specific predefined interfaces like controllers, IDL models, or other forms of dedicated APIs. Neither does it need to require any selected approach-specific methods to consume them. Instead, applications written in the same or different programming languages can connect directly based on pure method calls like working with local code. These methods stay up to date and get delivered as standard local dependency thanks to Graftcode’s seamless union with “package managers” of all technologies. Instead of processing requests through additional code layers, they are passed directly through the underlying runtimes and sent to the target system, enabling much faster and more efficient communication.

‘We’re blurring the lines between local and remote or same and cross-tech calls. This removes the need for manual integration code and allows systems to interact more efficiently. Downstream effects include reduced latency and complexity, and an end to dependency on specific architecture. Hypertube™ is doing the heavy lifting under Graftcode’s surface. It is the product of 11 years of R&D in runtime-bridging that began with Javonet. It is already working within in-memory integration scenarios of all kinds: high-frequency trading, banking systems, mediators, mainframes, connectors, medical devices, steel-bending machines in manufacturing 4.0 production lines. We’ve worked hard to make this engine applicable to virtually any remote software integration scenario across every cloud and system. The integration part of the product was exhaustively tested and holds up across millions of invocations in business critical production environments.,’ Mr Ładyński explains further.

Visibility Model and Security

When the integration layer is abstracted away, observability and debugging capability still needs to be ensured. The Graftcode team believes that some layers should be visible, while others should remain a black box. For the application part, the Grafts (strongly typed client) and Gateway (light app which bootstraps the runtime to host exposed modules) support market standard cloud-native monitoring and observability architecture. This leverages standard TLS TCP/IP based protocols, passing data correlation pointers (spanid, traceid) and allowing for standard logging or inspection of headers in http-based protocols for edge clients. From a code perspective, however, all of that is delivered as pure method calls that look like regular local dependency usage.

‘We can compare the handling to a stack which hides machine code and byte code from high-level programming languages and is trusted by design. Graftcode removes unnecessary legacy technical details from any type of software integration. It limits those to pure service reference and method invocation,’ Mr Ładyński specifies.

For enterprise adoption, governance, auditability, and compliance often require explicit interface definitions and contracts. Importantly, removing integration layers isn’t automatically equivalent to removing defining communication contracts. Local dependency usage within a single technology (like accessing modules from nuget, npm or maven) is the exact experience that Graftcode applies to every cross-tech and remote integration scenario.

Developer Experience, Language-Agnostic Architecture, AI Workflows, and Open Standard Ambition

‘Whatever should be callable must be a public method. This is the public interface in simplified UML diagrams. We bring simplicity back to real production environments and make public interfaces public again,’ the CEO clarifies.

From a developer experience perspective, teams still decide on accessibility, input, and output, but they do not implement any integration-method-specific controllers or artificial methods. The exposed public methods are consumed as a regular method call, preserving the independence of created code from the way such invocation intention gets processed in production.

This effectively opens up a world free of programming language barriers. The fully flexible software architecture enables clean and simple system design focused purely on business logic. This allows AI-assisted workflows to simplify code generation and reduce token usage. The overarching structure, in turn, allows for dynamic change of cloud, communication channels, protocols, and integration details as DevOps configuration.

To have cross-language and cross-system communication, especially in multi-tenant or regulated environments, properly governed, Graftcode is a deliberately open standard. Once implemented, it works purely in the end-consumer environment. The platform’s own cloud is needed only to generate grafts that are consumed at the development stage of the project. After deployment, the client and server side of any integration communicate directly in the consumer cloud.

To reiterate, Graftcode doesn’t change how security works, and the client’s system keeps the same security, scalability, and monitoring setup as before. Instead, the platform employs existing ways of sending data, whether it’s direct in-memory communication, secure network connections (TLS), message queues, or web protocols like HTTP and WebSockets. For authentication and authorization, it supports standard methods such as tokens, API keys, and credentials. These can be passed in familiar ways, like HTTP headers, message queues, or directly within method calls. For the client, this means that they can keep using the security approaches they already trust, without needing to learn or build anything new.

Industry Validation and Adoption Momentum

‘The interface/contract security is as simple as academic model systems. Graftcode is seamlessly leveraging standard programming languages structure. Developers create public methods with some input and output and that is the only thing that can be called. They can apply any authorization/authentication requirement for specific operation, even in a trivial way. They can utilize our built-in support for passing authorization/API-key data through headers of http-based protocols when working within edge-client (browser/mobile/IoT) space. If HTTP isn’t used, Graftcode sends the same request as a direct invocation message between runtimes, allowing systems to communicate more efficiently, and preserving the same experience across all use-cases,’ Mr Ładyński assures.

Such an approach creates a comfortable and predictable model for security, scalability, and observability, aligned with existing standards. It allows teams to easily transition from legacy integration methods like SOAP, REST, gRPC, or Thrift to Graftcode’s invocation-based intention protocol.

‘Most integration tools just add another layer on top of the problem. Graftcode takes a fundamentally different approach. Runtime bridging removes the integration code entirely instead of managing it. Przemysław and Łukasz Ładyński spent two decades building enterprise integrations before they decided the whole model was broken. Now, as AI workflows demand seamless service-to-service communication, that bet looks increasingly right. Companies were reaching out before the beta even launched—that kind of developer pull is the strongest signal we look for,’ Digital Ocean Ventures’ partner Adam Bartkiewicz shares.

Platform Expansion Plans, Developer-First Strategy, and Industry Standard Ambition

The recent EUR 2.1M funding is meant to support Graftcode’s expanded language coverage, deeper compatibility with AI-assisted development workflows, and continued platform development. More specifically, the company’s near-term focus is on expanding the platform’s capabilities and driving adoption:

• increasing the number of supported programming languages, particularly mobile ones;
• improving compatibility with AI-assisted development workflows to deliver effortless skill files for AI agents;
• continuing to develop the core platform to support all possible programming languages structures.

Another key priority is developer-first adoption. That’s why Graftcode made its platform free for developers to use it easily in their own projects and start building with it early delivering full production solutions at no cost. From there, the goal is to grow an active community, encouraging contributions and building out a broader ecosystem of plugins to allow plug-and-play selection and enterprise bus channels like Azure ServiceBus, SQS, Kafka, and RabbitMQ.

More generally, success for Graftcode looks like a large and active base of developers using its platform in production. The benchmark goals are to reach around 200,000 users by the end of 2026, then two million by 2027–2028. Beyond pure user numbers, success also means seeing Graftcode become a standard part of how modern systems are built. The team anticipates runtime bridging delivered through strongly-typed Grafts to be established as a new default for software integration.

‘We want to provide our Graft Intention Protocol as open specification and pass it to Cloud Native Foundation, enshrining it as the best reference implementation for this approach,’ Mr Ładyński states in conclusion.

Whether Graftcode can deliver on its ambitious vision remains to be seen soon enough, but it is challenging one of software development’s most entrenched assumptions: that complex integration layers are an unavoidable part of modern systems. At a time when organizations are struggling with technical debt, increasingly fragmented architectures, and the demands of AI-driven workflows, any technology that meaningfully reduces integration complexity could have far-reaching implications. If runtime bridging gains broad developer adoption, it is poised to deliver more than merely improve how software systems communicate: it could reshape the foundations of software integration itself.