Marco · White-labelling Kaphera as the connector backbone
The Head of Product & Partnerships at an established managed-EDC service company has a board mandate to pivot to the application layer without disrupting forty-plus production customers. He white-labels Kaphera as the connector backbone, migrates customers under a service-notice framing, and frees three engineers to start shipping the differentiated products the next phase depends on.
Scenario
Marco is Head of Product & Partnerships at a company that has spent three years operating managed EDC connector services for organisations across the automotive and freight sectors. The business works, they have forty-plus active customers running connectors in production, established SLAs, and a recognised name in the dataspace ecosystem. But the board has made a strategic decision: the company’s competitive advantage is not in operating connector infrastructure, it is in the application layer above it, the use cases, the data products, and the industry-specific workflows that turn sovereign data exchange into business value. The connector infrastructure is becoming a commodity concern, and the engineering capacity being spent on it is engineering capacity not being spent on the differentiated products the company needs to build in its next phase.
The operational problem this creates is significant. Forty-plus production customers cannot be disrupted. Three engineers whose primary job is keeping connector deployments operational cannot simply be reassigned to product work while those deployments still need someone to own them. The strategic pivot to the application layer requires a credible answer to the question of what happens to the infrastructure layer, and that answer has to be invisible to existing customers.
Marco’s proposal: white-label an infrastructure provider as the company’s connector backbone. Their customers continue to see their brand. Their engineers stop maintaining connector infrastructure and start building the application layer. The infrastructure runs on someone else’s platform, operated to a standard Marco’s team no longer has to maintain themselves.
flowchart TB subgraph STRAT["Strategic track"] S1["Board approval"] S2["Vendor evaluation"] S3["Commercial negotiation"] S4["New customer acquisition"] S1 --> S2 --> S3 --> S4 end subgraph OPS["Operational track"] O1["Migration plan"] O2["Cohort 1: 18 straightforward"] O3["Cohort 2: 2 edge cases"] O4["Engineers redirected to app layer"] O1 --> O2 --> O3 --> O4 end S3 --> O1 O4 --> S4
Storyline
Step 1: Defining the infrastructure problem the strategic pivot creates
Action
Marco writes the internal case for the white-label arrangement alongside the application-layer pivot proposal. He documents the production constraint explicitly: forty-plus live customer deployments, three engineers whose availability is the operational dependency, and a migration that must be invisible to customers at the service level. He also documents what he needs from an infrastructure partner that he has not found in the market before: source-available licensing so he can audit what runs under his brand, a commercial model that lets him set his own pricing rather than reselling at a fixed margin, and a governance structure that gives him confidence the partner’s incentives will not diverge from his customers’ interests after a funding round or an acquisition. He presents the case to the board alongside the application-layer strategy. Both are approved.
Thoughts
“The board approved both decisions in the same meeting, which means the pressure to execute on the application layer is already real. I have a limited window to get the infrastructure transition done cleanly before the product team starts asking why the engineers are still maintaining connectors.”
Emotions
Strategically committed but operationally aware that the transition is where this can go wrong. Marco has seen partnership arrangements fail when the infrastructure provider’s priorities shifted post-agreement. He is going into this evaluation with more specific criteria than he has ever applied to a vendor selection.
Step 2: Evaluating infrastructure partners against criteria that matter
Action
Marco evaluates four potential infrastructure partners. Two are proprietary managed connector services, he eliminates them immediately on source-availability grounds, having experienced a previous arrangement where a proprietary provider changed terms after a Series B and left him with no leverage and no exit path. One is a large telco-backed provider with IDSA certification, the compliance credentials are strong but the commercial model is reseller-only, which compresses his margin to a level that does not support the application-layer business he is trying to build. The fourth is Kaphera. He reads the Apache 2.0 operator, the source-available platform layer, the production track record, and the steward-ownership documentation before requesting a commercial conversation.
Thoughts
“The source-available answer is the one I have been looking for. The telco provider has better certification today, but I cannot build a business on a reseller margin, and I cannot tell my customers their infrastructure is sovereign if it runs on a proprietary platform I cannot inspect. Those two things are not negotiable.”
Emotions
Clear-eyed and experienced. Marco’s evaluation process is faster than it looks, most of the criteria are binary. The two proprietary providers did not make it past the first question. The telco provider failed on commercial terms. Kaphera clears every criterion he has set. The remaining question is whether the commercial arrangement can be structured in a way that works for both sides.
Step 3: Commercial negotiation: structuring a partnership, not a reseller agreement
Action
Marco enters a commercial negotiation with Kaphera focused on three terms: the right to operate the platform under his company’s brand with no Kaphera attribution visible to end customers, a licence fee structure that leaves him sufficient margin to price his managed connector offering competitively, and a source-available licence that gives his legal team confidence he can take over operations independently if the relationship changes. He also negotiates a mutual roadmap commitment, his company’s application-layer use cases generate dataspace deployment patterns that Kaphera’s platform benefits from supporting, and he wants formal input into the connector profile roadmap in exchange for his team’s implementation knowledge. The negotiation takes four weeks. Both sides sign.
Thoughts
“The roadmap input clause is the one that makes this a partnership rather than a supplier arrangement. If I am going to build my application layer on top of Kaphera’s infrastructure, I need confidence that the infrastructure will evolve in ways that serve the use cases my customers care about. A contract that only covers today’s capabilities is not sufficient.”
Emotions
Satisfied with the terms and genuinely interested in the relationship. The roadmap input clause reflects something Marco has not had with an infrastructure provider before, a formal mechanism for his team’s knowledge to flow back into the platform. That changes the dynamic of the arrangement in a way he thinks matters.
Step 4: Migration planning: forty-plus customers, zero visible disruption
Action
Marco and his engineering lead spend two weeks mapping the existing customer deployments against Kaphera’s platform capabilities. They identify three categories: straightforward migrations where the current deployment maps cleanly to a Kaphera managed instance, migrations that require a configuration translation step, and two edge-case deployments with custom integrations that need a bespoke migration path. They agree a migration sequence, straightforward deployments first, edge cases last, and a rollback plan for each that preserves the ability to revert within minutes if a migration produces unexpected behaviour. They also define the customer communication strategy: customers will receive a brief service notice about a platform upgrade, framed around performance and reliability improvements. The word “migration” does not appear in any customer-facing communication.
Thoughts
“The two edge-case deployments are the ones I am watching. Everything else I am confident about. Those two need a joint session with Kaphera’s engineering team before we touch them, I want their people in the room when we migrate those, not just documentation support.”
Emotions
Methodical and appropriately cautious. Marco has done enough infrastructure migrations to know that the ones that go wrong are always the edge cases that seemed manageable during planning. He is treating the two custom deployments as the critical path items from the start.
Step 5: First migration cohort: straightforward deployments
Action
Marco’s team migrates the first cohort of eighteen customer deployments over three weeks using a DNS-based cutover approach. Each migration runs in parallel, the new Kaphera-backed deployment is validated against the existing one before the cutover, and the rollback is tested before it is needed. Fifteen of the eighteen migrations complete without incident. Two require a configuration adjustment identified during validation. One triggers the rollback path, runs cleanly back to the previous deployment, is diagnosed over two days, and is remigrated successfully the following week. No customer experiences a service interruption. No customer asks what changed.
Thoughts
“One rollback out of eighteen is within the range I planned for. The fact that the rollback worked exactly as designed is more reassuring than the fifteen clean migrations, it means the safety net is real, not theoretical.”
Emotions
Relieved and increasingly confident. The rollback working cleanly is the most important thing that happened in the first cohort. Marco knows that the remaining migrations will go more smoothly because he has now tested the full process end to end, including the failure path.
Step 6: Edge-case migrations: joint engineering session
Action
Marco’s engineering lead and a Kaphera engineer work through the two edge-case deployments together over two days. One involves a custom data plane integration that maps to a configuration option in the Kaphera platform that the migration documentation did not cover clearly, resolved in the joint session. The other involves a legacy credential format from an earlier IDSA specification that requires a one-time conversion step before the migration can proceed. Both deployments migrate successfully. Marco files the credential format issue as a formal feedback item with Kaphera’s team, noting that other white-label partners migrating legacy deployments will encounter the same issue.
Thoughts
“The credential format issue will not be unique to us. If Kaphera builds a migration utility for it, the next white-label partner who encounters legacy deployments will have a smoother path. That is worth flagging formally rather than treating as a one-time problem we solved for ourselves.”
Emotions
Collaborative and forward-thinking. The joint engineering session has shifted Marco’s perception of the Kaphera relationship from a vendor arrangement to something that feels more genuinely mutual. Filing the feedback formally is a small act that reflects a larger shift in how he is thinking about the partnership.
Step 7: Engineers redirected to the application layer
Action
With the migration complete, Marco formally reassigns his three infrastructure engineers to the application-layer product team. They retain on-call responsibility for customer escalations, if a customer has a connector issue, Marco’s team is still the first point of contact, but the operational burden of keeping deployments running has transferred to Kaphera. In the first month after reassignment, the three engineers contribute the equivalent of six weeks of prior output to the application-layer roadmap, simply by no longer spending half their time on infrastructure maintenance. Marco presents this productivity figure to the board as the first measurable return on the white-label decision.
Thoughts
“Six weeks of engineering output recovered in a single month. That is the number the board cares about, and it is the number that makes the licence fee cost irrelevant as a line item.”
Emotions
Vindicated in the most concrete possible way. The strategic rationale for the white-label arrangement was always about engineering capacity. Having a measurable figure within the first month of the migration being complete makes the internal narrative very clean.
Step 8: New customer acquisition under the white-label platform
Action
Marco’s company onboards three new customers using the Kaphera white-label platform. The onboarding process is faster than it was with the previous infrastructure, the Kaphera connector profiles for MDS and Tractus-X are pre-built and validated, which removes the dataspace-specific configuration work that previously consumed the first two weeks of every new customer engagement. The new customers see Marco’s company’s brand throughout. The application-layer features Marco’s product team has built in the previous two months are the primary commercial hook in the sales process, the connector infrastructure is the foundation, not the pitch.
Thoughts
“The pitch has changed. We are no longer selling managed connector infrastructure with some application features on top. We are selling industry-specific data exchange workflows with sovereign connector infrastructure underneath. That is a fundamentally different conversation, and it is a better one.”
Emotions
Energised. The three new customers were acquired in conversations that looked nothing like the connector sales process Marco’s team was running a year ago. The application layer is doing the commercial work the infrastructure used to have to do.
Step 9: Roadmap input: first formal contribution
Action
Marco’s team identifies a connector profile requirement for a freight sector dataspace that is not currently supported by Kaphera. Under the roadmap input clause negotiated in Step 3, Marco submits a formal specification document covering the credential requirements, trust anchor structure, and onboarding flow the profile would need. Kaphera’s team reviews it, asks three clarifying questions, and adds the profile to the six-month roadmap. Marco’s team commits to providing a reference customer for the profile’s validation once it is built. The collaboration feels like the one Marco anticipated when he negotiated the clause, his implementation knowledge flowing into the platform in exchange for a platform that evolves to serve his customers’ use cases.
Thoughts
“This is what the roadmap clause was for. We have a freight sector customer who needs this profile. Kaphera has a platform that will be better for having it. The incentives are genuinely aligned, which is not something I have said about an infrastructure provider relationship before.”
Emotions
Genuinely collaborative. The formal roadmap contribution is the moment the partnership becomes something more than a commercial arrangement. Marco is invested in Kaphera’s platform succeeding because his own product’s roadmap depends on it.
Step 10: Advocacy within the ecosystem
Action
Marco speaks at an IDSA ecosystem event about Nexyo’s application-layer strategy, describing the white-label infrastructure model without naming Kaphera directly. Two other managed connector providers approach him afterwards, both facing the same strategic question about the application layer versus the infrastructure layer. He connects both of them with Kaphera. He also introduces Kaphera to a systems integrator he has worked with for two years who is evaluating the Builder path. The referrals are not transactional, Marco makes them because the partnership has worked and because he believes the model is the right structure for the ecosystem.
Thoughts
“The ecosystem is going to stratify, some players will go deep on the application layer, some will go deep on the infrastructure layer. The ones who try to do both will be outcompeted on both. I made that choice, and the infrastructure partner I found made it viable.”
Emotions
Settled and clear on the market structure. Marco’s advocacy is the most credible kind, it comes from a migration he has already completed, with results he can point to, from a partner relationship he believes in. He is not recommending something he is still evaluating.
Key features
🏷 Full white-label branding: platform operates entirely under the partner’s brand with no Kaphera attribution visible to end customers at any touchpoint
💼 Partner commercial licence: margin structure that supports the partner’s own pricing model rather than a fixed reseller arrangement, with terms that do not compress on volume growth
🔍 Source-available platform layer: partner’s legal and technical teams can audit what runs under their brand, and the partner retains the contractual ability to take over operations independently if the relationship changes
🔄 DNS-based migration tooling with validated rollback: migration path for existing customer deployments with per-deployment rollback capability tested before cutover, not after
📋 Legacy credential migration utilities: conversion tooling for customers on older IDSA credential formats that pre-date current connector profile specifications
🗺 Formal roadmap input mechanism: contractual pathway for the partner’s implementation knowledge and customer use cases to flow into the platform’s connector profile and feature roadmap
📡 Customer escalation layer: partner remains first point of contact for customer issues; platform provides the operational foundation the partner escalates into rather than bypassing the partner relationship
🔌 Application layer integration surface: clean API and event interface for the partner’s application-layer products to sit on top of the connector infrastructure without tight coupling to platform internals
Related
- marco-ferretti: the protagonist: Head of Product & Partnerships at a managed-EDC service company executing a strategic pivot to the application layer
- white-label-partner: the archetype: companies operating connector services under their own brand, on top of someone else’s infrastructure
- kaphera-cloud-managed-server: the managed platform that runs his customers’ connectors under his brand, with no Kaphera attribution at any customer touchpoint
- kaphera-cloud-server: the control-plane API and integration surface his application-layer products sit on top of
- white-label-partner-playbook: sales motion for the white-label-partner archetype