Who owns the integration code?

Who owns the integration code in an epilot project? You do. Connecting epilot to your own systems means having interfaces and mappers built, and that code is part of your IT, not part of the platform. This article explains what that means in practice, what a handover into your own repository looks like and when a maintenance contract is the better fit.

It is written for IT leads at grid operators, municipal utilities and energy suppliers who are about to commission an epilot interface and want to know up front who owns the result.

Who owns the integration code in an epilot project?

The integration code belongs to the client. That applies to the interfaces and mappers I build for your project, and it is the starting point of the engagement, not something you have to negotiate for.

Integration code is software that connects epilot to your surrounding systems. It receives events, translates and validates data, and writes it into other systems or back into epilot. Without it, your processes stop at the system boundary.

Because this code captures how your business runs, it belongs with you. The specific rights to it are set out in the individual contract that comes with your quote.

How is integration code different from the epilot platform?

The epilot platform is the product of epilot GmbH, and the integration code is your own code around that platform. The two are kept clearly apart.

All rights to epilot lie with epilot GmbH. Platform licences are available only from epilot. I do not sell licences, and I only work on the platform itself in cooperation with epilot.

The integration code runs outside the platform. It talks to epilot through the official routes epilot provides for this, such as public APIs and webhooks. The epilot developer documentation on integrations gives an overview of these routes.

	epilot platform	Integration code
Who owns it?	epilot GmbH	the client
Where does it come from?	licence from epilot	custom development
Where does it run?	inside the platform	in your own environment or an agreed environment
Who develops it further?	epilot	your IT, a partner of your choice or me under a maintenance contract

How does this work alongside epilot?

I complement epilot’s consulting team, I do not replace it. For the rollout, configuration and the standard scope, epilot remains your point of contact.

I am Marcel R. G. Berger, a software developer and software architect with more than 20 years of experience. I work with epilot as an external consultant and developer for apps and customisations, and pick up where the standard ends.

That gives a clear split. epilot is responsible for the platform, and the integration code around the platform belongs to you. When such an integration is needed in the first place is covered in the article When is low-code in epilot no longer enough?.

What does a handover into your own repository look like?

After implementation, I transfer the code into your own repository on request. From then on, everything that makes up the integration sits in a place you manage yourself.

A handover usually covers the following:

• the complete source code of the interfaces and mappers
• the build and container definitions needed to build and run the code
• configuration templates, without credentials or other secrets
• documentation of the structure, data flows and operations
• the automated tests

Credentials never go into a repository. They stay in your own secrets management and are only referenced by the configuration templates.

The exact scope of the handover is set out in the quote, so both sides know in advance what will end up in the repository.

A short joint handover session makes sense, in which your IT builds and starts the code once on its own. After that it is clear that the material is complete and nothing is missing that only exists on someone else’s machine.

Why does owning the integration code matter for grid operators?

Owning the integration code makes grid operators independent of a single supplier. Whoever owns the code decides who runs it, reviews it and develops it further.

For grid operators, four points carry the most weight.

• Less vendor lock-in: the integration does not depend on one person or one company.
• Audits and documentation: if you have to evidence your processes, you need access to the code that runs them and to its documentation.
• Continuity: if a supplier drops out, the code is still there and operations can carry on.
• Free choice of who continues: your internal IT or another partner can take over without starting from scratch.

Audits often ask how a record gets from one system to another and which rules apply on the way. If those rules live in your own repository, the answer can be shown in the code, the tests and the documentation.

For workflows that span several systems, this is not a theoretical benefit. An integration is part of your infrastructure, and infrastructure should not depend on someone else holding the keys.

How does owning the code reduce vendor lock-in?

Owning the code reduces vendor lock-in because the knowledge about the integration lives in the repository, not only in one developer’s head. Code, tests and documentation together make the work understandable to others.

Lock-in rarely comes from contracts. It usually comes from missing material. If nobody except the original developer knows how an interface is built, every change is tied to that developer.

That is why build and container definitions are part of the handover. With them, the code can be built and started in a different environment without anyone having to guess the steps. The tests show what the code is supposed to do and guard against regressions when it changes later.

How are the mappers built technically?

The mappers are custom tools written in Java with Quarkus, containerised, scalable and maintainable. This approach is a deliberate choice for code that other developers can pick up.

Java is widely used in the IT departments of energy suppliers. Quarkus is a Java framework for lean services that run in containers. A container bundles a service with everything it needs to run, so it behaves the same across different environments.

For you as the owner, this means the code relies on common technology, not on a niche tool only one supplier understands. How such a mapper is put together in detail is covered in the article Mappers between epilot and surrounding systems, built with Quarkus.

In my current project at a grid operator in Hesse, several third-party systems are connected to epilot through interfaces like these, because many processes there run outside the platform. More on this in the in practice section on the home page.

Repository transfer or maintenance contract: which suits you?

Both options are available, and with both the code stays with the client. The difference is who takes care of maintenance and further development after implementation.

	Transfer into your own repository	Maintenance contract
Who owns the code?	the client	the client
Where does the code live?	in your repository	in your repository or an agreed location
Who maintains the code?	your internal IT or a partner of your choice	me, within the agreed scope
What do you need in-house?	developers or a partner who can run Java and containers	a contact person for requirements and approvals
When does it fit?	when you want to take the integration forward yourself	when you want to hand off care and further development
Basis	individual quote	individual quote

The choice is not final. A maintenance contract does not stop your IT from taking over later, and a transfer does not stop you from bringing in support again later.

What does a maintenance contract usually cover?

A maintenance contract covers the care and further development of the integration code after implementation. What exactly is included is set out in the individual quote.

Typical topics are adjustments when a surrounding system changes, new requirements from business teams and ongoing upkeep of dependencies. On top of that, new versions of Java, Quarkus and the libraries in use are applied regularly so the code does not go stale. Under a maintenance contract, too, the code remains yours.

What a maintenance contract covers day to day, from monitoring and error handling to updates, is described in Running epilot integrations. How a project runs from the intro call to the handover is shown in An epilot integration project at a grid operator.

Do you need a lawyer, or is the quote enough?

The specific rights to the code are set out in the individual contract and quote, and this article is not legal advice. It describes how the engagement is usually structured.

Your contracting party is DigitalFreedom Global LLC. For grid operators the contract can be made under German law on request, otherwise the law of the State of Wyoming applies. The details are in the contracting party section on the home page.

If your legal team needs particular terms on usage rights or the handover, raise them before the order confirmation. That way they go straight into the contract.

How do you start a project with your own integration code?

You start with a free intro call about your systems and workflows. Afterwards you receive an individual quote that also describes the code handover and, if you want one, a maintenance contract.

1. Intro call: free and non-binding, 30 minutes on Microsoft Teams.
2. Individual quote: tailored to your systems, with the scope of the handover and options for maintenance.
3. Implementation: interfaces and mappers are built, tested and put into operation with your systems.
4. Handover or maintenance: the code goes into your repository, or further development runs under a maintenance contract.

The whole route from the intro call to operation is described in how an epilot integration project at a grid operator runs.

Every service, from implementation to handover to maintenance contract, is based on an individual quote. Further answers are in the FAQ on the home page, and you can pick a slot directly in the booking calendar.