GRAFTCODE helps developers simplify software development by reducing integration code and making functionality accessible across programming languages, services, and environments.
Przemysław, could you introduce yourself and GRAFTCODE and tell us what inspired you to start the company?
I got into coding almost by accident when I picked up a programming book at the age of nine, and I’ve been building software ever since.
When I was 19, my brother Łukasz and I founded a software development company. Over the years, we delivered a range of projects, including a diabetes management system for hospitals and patients that is now used in 63 countries. Then, the idea behind GRAFTCODE dates back to when I was considering pursuing a PhD. I developed an early proof of concept for runtime bridging, allowing Java applications to use .NET runtimes directly. What started as a fairly niche solution made us realise there was a much bigger opportunity to simplify how different technologies work together.
Over the following years, we invested our own funds and secured more than €6 million in EU grants to develop the technology, eventually expanding it to support 52 technology pairs.
The real turning point came when we extended runtime bridging to support remote communication. Developers could now call functionality from another service almost as easily as a local dependency, without writing and maintaining separate integration code. We realised this could fundamentally change how software is built, allowing the same business logic to be used locally, across microservices, through APIs or exposed to AI agents via MCP.
At the same time, we were seeing growing interest from developers and investors, which led us to establish GRAFTCODE as a standalone company. We were also fortunate to bring together a talented team willing to tackle the technical challenges involved. Since then, we’ve completed our seed funding round and are now looking towards Series A funding.
You and your cofounder have extensive experience in enterprise integration technologies. Which problems did you repeatedly encounter that ultimately led to the idea behind GRAFTCODE?
Since around 2000, we’ve seen several major shifts in integration technology, from SOAP and REST to gRPC, GraphQL and cloud-based messaging systems. Each solved certain problems, but developers still had to write technology-specific integration code.
Every technology introduced its own framework, SDK or programming model for exposing and consuming functionality. This tied applications to specific integration approaches, making significant refactoring necessary if you wanted to change them later.
The problem became even more apparent as software systems grew more complex. Developers were spending increasing amounts of time maintaining controllers, routes, data contracts and other integration code, even when the underlying business logic remained unchanged.
This brought us back to a simple question: why should calling a function remotely be so much more complicated than calling it locally? If you want to unzip a file, you simply install a package through PyPI, NuGet or Maven and call a method like Zip.Unzip(filename). But move that same functionality to a remote service, and suddenly you need HTTP routes, API contracts or SDKs just to call it.
We wanted to return to a basic principle we learned at university: a public method is an interface you can call. That inspired our idea of making the “public method public again”, allowing developers to use remote services like local dependencies. With GRAFTCODE, the underlying communication, whether through HTTP/2, WebSocket, a queue, an event bus, direct TCP/IP or MCP, becomes an implementation detail rather than something developers have to build around.
GRAFTCODE describes its technology as an “integration-free development layer.” What does this mean in practice, and which problem are you solving for developers?
The key distinction is that we’re not removing the integration layer itself but the need to write and maintain integration-specific code. Developers still need to design proper public interfaces, deciding which methods to expose, how exceptions should be handled and how those interfaces can evolve without breaking existing applications. GRAFTCODE removes the extra work required to make that functionality available across different technologies and environments.
In practice, developers add GRAFTCODE Gateway to their project, container or cloud service and expose the modules they want to make available. GRAFTCODE then makes the public methods accessible through strongly typed replicas of those interfaces, distributed via standard package managers like NuGet, PyPI or Maven.
From the consumer’s perspective, it looks like importing and using a normal typed dependency. They do not need to read an API specification or manually work with routes, schemas or protocol-specific SDKs. The available functions appear directly in the IDE, making them easier for both developers and AI coding tools to discover and use correctly.
Then, frontend and mobile applications, IoT devices, robots, and other microservices can consume the same service through load balancers, queues, or event buses; as a public B2B API; or via MCP by an AI agent.
Crucially, developers can also change how they deploy their applications without rewriting the business logic. A module might initially run locally within a monolith and later move to a remote service, or vice versa, with much of that change handled through configuration rather than new integrations.
That’s what we mean by integration-free development: developers still design clean public interfaces but no longer need to build and maintain separate integration code for every transport, protocol or deployment model. It’s close to the idea of a truly polyglot modular monolith, where modules can run locally or remotely, communicate synchronously or asynchronously, and still be consumed in the same way.
APIs and middleware have been fundamental to software development for decades. Why do you believe the traditional approach to connecting software systems needs to change?
APIs are here to stay, and they should be, as long as we understand them as a way of defining what a system exposes to the outside world. What needs to change is the extra code required to make that functionality accessible.
Why should developers have to write more integration code than actual business logic just to make a service available to a JavaScript or React application? Or write another layer of code to expose the same functionality through Azure Service Bus? All of that code then needs to be maintained, reviewed, and understood by both developers and AI coding tools.
AI coding tools are making this problem more noticeable. We’re seeing more AI-generated code and pull requests, and engineering teams can now produce software much faster. But the traditional approach also means developers and AI tools have to manage more integration code, even when the underlying business logic hasn’t changed.
At the same time, developers are also becoming increasingly polyglot. Someone who has spent most of their career working with Java can now use Python for machine learning, C# for business logic and TypeScript for the frontend. Yet each technology can bring its own integration requirements, adding more code to write and maintain.
Developers should be able to choose the best technology for each task and focus on business logic and public methods, rather than learning and maintaining different integration frameworks every time.
AI is generating an increasing amount of software and code. How is this development changing the integration problem that GRAFTCODE is addressing?
AI is making it much faster to build software, but it’s also generating more integration code. When an AI agent creates a new service, it still has to produce controllers, routes, DTOs, schemas and SDKs alongside the actual business logic. When that logic changes, you have to update all those additional layers.
We initially thought AI might solve the integration problem by writing all this code for us. But generating more integration code doesn’t really solve the problem. It just makes generating the problem cheaper.
There’s also the context issue. AI needs to read and understand all that integration code, keep it consistent with the business logic and account for it whenever something changes. That consumes tokens, creates more opportunities for errors and leaves developers with more code to review.
With GRAFTCODE, we want AI to work directly with public methods, their types, parameters and return values. An agent calling a remote service shouldn’t need to know whether the underlying communication uses REST, gRPC, WebSocket, a queue or MCP. It should simply see a strongly typed function it can call. In fact, the best integration code may simply be the integration code you never had to generate in the first place.
What I find particularly interesting is where this could lead. AI could eventually monitor a system and decide when a module should be extracted into a microservice, when to introduce a queue, when to move from Kafka to Azure Event Hubs or when to replace WebSockets with HTTP/2.
In the future, GRAFTCODE could let some of these changes happen through configuration rather than rewriting business code. An AI agent could potentially adjust the Gateway and graft configurations to change how services communicate, without developers having to rebuild the integrations around them.
What makes GRAFTCODE technically different from existing API, middleware and integration solutions, and where do you see your strongest competitive advantage?
I think our biggest differentiator is the technology and system design itself. GRAFTCODE allows developers to build simpler codebases focused on business logic, without compromising on security, authentication, scalability or observability.
We’re not trying to replace cloud messaging platforms, queues or event buses. We want developers to keep using them. What we’re challenging is the traditional way of exposing and consuming functionality through technology-specific controllers, API contracts, SDKs and frameworks just to make functionality accessible across different systems.
This also has implications for AI-assisted development. With less integration code to process and maintain, AI coding tools need less context, reducing token usage and making generated code easier to review. We also support MCP natively, allowing the same public methods to be exposed to LLMs and AI agents without building separate integrations.
On the performance side, runtime bridging operates largely through the underlying runtimes’ native layers, which can reduce overhead compared with traditional integration stacks. Depending on the use case, this can improve resource efficiency and let you process more calls with the same CPU and memory.
Another important difference is architectural flexibility. Developers can build a modular monolith and later extract individual modules into microservices through configuration without changing the consuming code. Those modules can even be written in different languages, such as Java, .NET or Python, while remaining part of the same architecture. Access to queues, event buses and other cloud services is also being simplified through open-source extensions developed by our team and the community.
All of these capabilities build on the same underlying approach: making public methods accessible across different runtimes, deployment models and communication channels.
Which companies and development teams are your primary target customers, and in which use cases does GRAFTCODE currently provide the greatest value?
Almost every software project could benefit from GRAFTCODE, but right now our POCs and early adopters are mostly teams building business-critical distributed systems designed to run for years. These might be systems at the core of an organisation’s operations or the software product itself.
For these teams, the benefits add up over time. Less integration code means less maintenance, fewer breaking changes, easier onboarding and more flexibility to change the architecture as requirements evolve.
That’s also why we’ve made the core platform free. We want developers to be able to try GRAFTCODE without barriers, while offering paid plans for enterprises that need higher SLAs, the ability to run the grafting process within their own cloud tenant or fully on-premises deployment to keep their public interfaces isolated. Our goal is to make grafting as natural a part of software development as using Docker, Terraform or Bicep.
Building core developer infrastructure is technically demanding. What have been the biggest challenges in developing GRAFTCODE so far?
The first challenge was getting the architecture right and staying disciplined about its underlying principles. When you’re building something that needs to work across different technologies, deployment models, communication channels and cloud environments, the underlying design has to be universal.
Programming languages are a good analogy. With a relatively small set of concepts in C#, Java or Python, developers can build anything from a simple IoT device to a complex AI system or global e-commerce platform. We wanted GRAFTCODE to work similarly, using a consistent set of abstractions that could support very different use cases without introducing new exceptions or complexity every time we added a capability. Getting that right has been one of our biggest technical challenges, and it remains so as we expand the platform.
The second challenge is keeping the technology reliable as more developers use it. Once people build their systems around GRAFTCODE, they need to know it won’t break when we introduce something new. That means maintaining backward compatibility, introducing changes gradually and making sure existing projects can upgrade without issues.
GRAFTCODE recently raised €2.1 million in funding. What convinced investors about your approach, and how will you use the new capital to accelerate the company’s development?
Initially, convincing investors wasn’t straightforward. GRAFTCODE was still a concept rather than a usable product, and explaining something so different from traditional integration approaches through slides alone was difficult, even to experienced CTOs and technology leaders.
The turning point came when we developed a way to demonstrate the actual developer experience. Once investors could see how it worked and the layers of complexity it could remove, they found the value much easier to understand. There was often an initial “wow” moment, followed by another as they started to realise the broader implications.
We’ve used the €2.1 million investment to bring GRAFTCODE to market and develop it towards a stable, production-ready release, including the enterprise capabilities needed for larger projects.
We’re now moving beyond the alpha and beta early-adopter phase, with larger proof-of-concept projects involving enterprise systems, including IBM Maximo environments and distributed applications developed by software houses. We’re also seeing growing interest in the free tier, with more than 4,000 grafts generated monthly by anonymous users, a figure that has recently been close to doubling month over month.
And we’re preparing for a pre-Series A round, with plans to scale more broadly next year after Series A funding. The seed investment helped us turn the technology into a product developers can use. The next stage is about demonstrating that GRAFTCODE can become a widely adopted approach to software development.
You are building a developer-infrastructure company from Europe. What advantages and challenges come with developing a globally relevant technology company from Warsaw?
Poland has an incredible pool of engineering talent, with Polish engineers contributing to major technology projects at companies like OpenAI, ElevenLabs and SpaceX. Warsaw combines that technical expertise with a creative, increasingly international startup culture. Mindsets have also shifted, with more founders thinking globally from the start and pursuing ideas that might once have seemed out of reach.
Building a global technology company from Warsaw comes with challenges, particularly around international visibility and relationships, but we’ve found fewer barriers than expected. We’re already having promising conversations with US-based venture capital firms and receiving positive feedback about our technology and company structure, so being based in Poland hasn’t been an obstacle.
What are the next major milestones for GRAFTCODE, and where would you like to see the company over the next three to five years?
Our immediate priority is getting more developers to try GRAFTCODE and making it easier for them to create their first graft. It’s still a new concept for many developers, so we need to make the benefits clear from the moment they start using it.
Looking five years ahead, our goal is to have around two million projects actively using GRAFTCODE, alongside a strong base of enterprise customers on paid plans to support sustainable growth.
Our ambition goes beyond building another integration tool. We want to make traditional REST or gRPC integration unnecessary in many scenarios by offering developers a simpler way to connect software.
We also plan to make most of GRAFTCODE’s code source-available or open source and eventually contribute our Intention Invocation Protocol (IIP) to the Cloud Native Computing Foundation as an open standard. This would allow other developers and companies to build their own tools and infrastructure around the same approach.
Ultimately, I’d like grafting to become a normal part of how developers build software.
What are the three most important pieces of advice you would give to founders building highly technical startups today?
First, build for a category, not just a feature. Think about how your idea could change an industry or even become a global standard. Improving an existing process by 10 or 20% is one thing, but creating something fundamentally different opens up much bigger opportunities.
Second, give your vision enough time to become reality. Deep technology takes time to develop, so make use of non-dilutive funding wherever possible. Grants and research programmes can give you the freedom to solve difficult technical problems and bring your product closer to market readiness without giving away too much equity too early.
Third, don’t be afraid to think even bigger, and find a team ambitious enough to build it with you. Once your original concept starts working, you’ll often discover applications and opportunities you couldn’t have anticipated at the beginning. Some of the most interesting possibilities only become clear when you start building.
Image Credits: GRAFTCODE Fotografia Wizerunkowa. Your Professional Image. www.ArekMarkowicz.pl
Thank you Przemysław Ładyński for the Interview
Statements of the author and the interviewee do not necessarily represent the editors and the publisher opinion again.
