Qualify
Confirm that the use case fits the current release, target environment and responsibility boundary.
Technical evaluation
Prove one Kubernetes customer-delivery workflow before expanding the scope.
A bounded paid pilot connects your real environment, one expensive manual workflow and the technical evidence needed for a decision.
Good fit
Use a real delivery constraint.
- You deliver self-hosted software into customer Kubernetes environments.
- Provider, host, cluster or validation work still depends on manual runbooks.
- Customers need an inspectable result and responsibility handover.
- Hetzner or IONOS can represent the first supported provider path.
Not this offer
Clear boundaries save evaluation time.
- × Outsourced managed Kubernetes operations
- × A broad multi-cloud fleet-management promise
- × Unrestricted remote shell or generic Kubernetes writes
- × A fixed-price public package without environment review
Paid, fixed-scope technical evaluation. Final scope and commercial terms are agreed after the technical fit check. Approximately 10 business days is a planning range, not a guarantee when customer prerequisites are incomplete.
Four phases
From fit check to technical acceptance.
Each phase has an exit result. The evaluation can stop honestly when a prerequisite or product boundary does not fit.
Fit decision · prerequisites · explicit exclusions
Prepare
Install the customer-hosted control plane, connect one supported provider path and validate release artifacts.
Prove
Run one agreed delivery or lifecycle workflow, including one controlled failure and recovery scenario.
Accept
Review results with delivery, platform and customer stakeholders and document the next supported step.
What you bring
Enough context to test the real constraint.
- Target customer/environment pattern
- Current delivery runbook and ownership
- Network, registry and trust constraints
- Required success and failure evidence
- Stakeholders for technical acceptance
What you receive
A decision record—not a generic demo.
- Use-case and requirements review
- Clear environment and workflow baseline
- Operation, validation and recovery results
- Measured time and support effort
- Technical handover and recommended next step
Start with specifics
Send the environment, workflow and evidence you need.
No finished requirements document is necessary. Five concrete lines are enough to qualify the first conversation.