Builder Playbook
How to sell Kaphera Cloud into the builder archetype: system integrators and application builders whose job is to make sovereign data exchange work for someone else. The conversation lives on the open-source operators and the developer experience surface, CLI, Terraform, managed-server provisioning API.
Jobs to be done
- When I’m handed a dataspace project with a 6-week deadline, help me deploy a production-grade connector in days, so I can spend the engagement on integration work, not infrastructure.
- When I need to deliver connector infrastructure across multiple clients, help me reuse the same foundation for every project, so I stop rebuilding from scratch each time.
- When I need to integrate my SaaS product with a dataspace, help me register a data asset and implement the consumer pattern via API, so I can ship it as a product feature in one sprint.
- When my product needs to provision connectors for my own customers, help me do it with a single API call, so I don’t become an infrastructure team.
- When EDC releases breaking changes, help me stay insulated, so my deployments and integrations don’t break.
Signal → Product map
When you hear the signal, sell the product. The justification tells you why that product and not another.
| What you hear | What to sell | Why this product, not another |
|---|---|---|
| ”We’re running connectors ourselves but it’s taking 6-8 weeks per client” | kaphera-edc-operator • kaphera-edc-enablement-operator | They already have K8s skills. The open-source operators give them instant productivity without vendor lock-in. Managed platform is the upsell once they’re running 3+ clients. |
| ”We need to integrate our product with Catena-X” | kaphera-cloud-managed-server (shared tier) | They don’t want to run infrastructure, they want an API to build against. Managed connector with control plane API is the right entry point. Not the operators, those require K8s expertise they don’t have. |
| ”We want to provision connectors for our customers” | kaphera-cloud-managed-server • [[kaphera-cli|kaphera CLI]] (cloud backend) | Programmatic provisioning via API. Each customer onboarded = a new managed connector Kaphera operates. Self-hosting this topology doesn’t scale, the managed server does. |
| ”We manage infrastructure as code with Terraform” | kaphera-cloud-terraform-provider • kaphera-cloud-terraform-modules | Fits their existing workflow. The kubernetes backend means no server dependency. Modules give them production-ready patterns instead of assembling 15+ resources from scratch. |
| ”We need to be able to inspect the source” | kaphera-edc-operator (Apache 2.0) | Apache 2.0 is a procurement prerequisite for some clients. Point them to GitHub. The managed platform is the upsell when operational overhead exceeds what the team can absorb. |
| ”We’re evaluating this for multiple client projects” | kaphera-cloud-managed-server (dedicated tier) | Multiple participations need organisational isolation. Dedicated tier gives per-client isolation with centralised management. Not shared tier, the SI needs to keep client environments separate. |
Upgrade signals
- They start asking about certificate lifecycle management → they’ve outgrown self-hosting. Offer the managed platform.
- They mention 3+ client deployments → dedicated tier conversation. Shared tier doesn’t give them per-client isolation.
- They ask about additional dataspace profiles (MDS → Tractus-X or vice versa) → each profile is expansion revenue.
- Application builder mentions provisioning for their customers’ suppliers → kaphera-cloud-managed-server with programmatic provisioning API.
- They ask about digital twin metadata for Catena-X → add kaphera-digital-twin-registry.
Objections & responses
| Objection | Response |
|---|---|
| ”We can build this ourselves" | "You can. The operators are Apache 2.0 and we encourage it. The question is whether your team should spend 6 months building what’s already production-tested, or 6 months on the integration work that actually differentiates your offering." |
| "Why pay when it’s open source?" | "The operators are free and always will be. What you pay for is managed operations, certificate lifecycle, credential updates, upstream tracking, SLA-backed uptime. Same decision as self-hosting PostgreSQL vs. using a managed database." |
| "What if Kaphera disappears?" | "The EDC operator is Apache 2.0. The platform is source-available. You can inspect and run everything independently. We’ve structured it so the exit path is always open.” |
What closes the deal
For the SI Builder (lars-hoffmann): A live demo. Show a connector deployment that takes minutes instead of weeks. Use the CLI or Terraform provider against their target dataspace profile. When they see the time difference, the conversation shifts from evaluation to onboarding.
For the Application Builder (leila-brandt): A sandbox environment they can hit with curl immediately. Working API request → integration code → shipped feature in one sprint. The faster they get to a working request-response, the more likely they commit.
Related
- builder, the archetype this playbook serves.
- lars-hoffmann, leila-brandt, the two named scenarios under this archetype (system integrator and application builder).
- kaphera-edc-operator, the open-source entry point most builder conversations start from.
- kaphera-cloud-terraform-provider, kaphera-cli, the developer experience that closes builder evaluations.