Technical Delivery Scoping Guide
6 min read
This page cover the technical delivery for Customer Hosted Tenants (CHT) on Azure, AWS and OpenShift — from kickoff to Go-Live, and the ongoing operation after.
At a glance
One offering: Customer Hosted Tenant (CHT). The customer owns the cloud environment, Unique operates the platform.
CHT | |
|---|---|
Time to Go-Live | 6 months from kickoff |
Unique effort, setup | 12 SE-weeks |
Unique effort, ongoing | 40% FTE per tenant |
Customer effort, setup | 0.5 to 1 day per week |
Customer effort, ongoing | 5 to 10% FTE per tenant |
Total ongoing effort | 45 to 50% FTE per tenant |
Customer must have | Approval authority |
Unique effort is Solutions Engineer time. SE-weeks and Unique's FTE percentages refer to this role.
These figures are the baseline. Any divergence from the standard adds effort, duration, or both — see Section 5.
The delivery timeline starts at kickoff, not at signature. What the customer must prepare comes first and is not counted — see Section 3. Anything still open at kickoff is carried into delivery and adds effort and duration.
Go-Live means the platform is available for productive use. Forward Deployed Engineering (FDE) deliverables and product features named in a proposal are not part of it.
What these numbers exclude
The figures above cover technical delivery only: standing the platform up, integrating it, and operating it.
Programme delivery — project and programme management, governance, steering, status reporting, change management
Forward Deployed Engineering — use-case build, assistant and agent configuration, prompt and workflow work
Product engineering — feature development, roadmap commitments, product changes
These activities are not included in these timelines and efforts.
What is included as standard
Everything below is covered by the effort in Section 1. Anything else is a divergence — Section 5.
The setup
Standard | |
|---|---|
Architecture | The Unique reference platform for the chosen cloud, with the customer's configuration values and no structural change |
Source | The customer forks the reference platform and takes releases from upstream |
Cluster | Dedicated to the tenant |
Environments | Two — one non-production, one production |
Data services | As deployed by the reference platform — managed cloud services where the cloud offers them, in-cluster on OpenShift |
Key management | The cloud key service used by the reference platform, with customer-managed keys |
Observability | The bundled observability stack deployed by the reference platform, with logs and metrics delivered to one customer sink |
The reference platforms are maintained as public code. What they deploy is the standard. Anything they do not deploy is a divergence, priced in Section 5.
Platform | Reference platform | Normative scope |
|---|---|---|
Azure | Full platform | |
AWS | Full platform | |
OpenShift | Application layer only — the customer provides the cluster |
The ongoing service
What it covers | |
|---|---|
Releases | Unique's release cadence applied to the tenant |
Requests | Changes to the platform |
Incidents | Restoration of service after degradation or outage |
Duty | Monitoring, alert response and availability |
Responsibilities
Covers setup and ongoing operation. R = responsible, A = accountable, C = consulted, I = informed.
Layer | Responsibility |
|---|---|
Cloud environment — accounts, subscriptions or cluster tenancy, transit network, guardrails, provisioning | Customer RA · Unique CI |
Identity and access — cloud IAM and RBAC, identity provider tenant, users and groups | Customer RA · Unique CI |
Identity and access — identity provider connection to the platform | Unique RA · Customer CI |
Platform layer — deployment, upgrades, configuration, connectors (reference platform scope) | Unique RA · Customer CI |
Requests — changes to the platform | Unique RA · Customer CI |
Custom integrations and extensions | Customer RA · Unique CI |
Model provisioning and access | Customer RA · Unique CI |
Monitoring, alerting and threat detection | Unique RA · Customer CI |
Backup and disaster recovery | Customer RA · Unique CI |
CI/CD pipelines | Unique RA · Customer CI |
1st level support | Customer RACI |
2nd level support | Unique RA · Customer CI |
3rd level support | Unique RA · Customer CI — product engineering, outside the effort on this page |
User training and use-case documentation | Customer RACI |
Unique's access is scoped operational access, federated and audited. Unique monitors using its standardized tooling. Work management runs on Unique's task management and operating model, with one intake channel through Unique's tooling. The customer reviews and approves at stage gates.
What the customer must provide
Every item outstanding at kickoff is carried into delivery. It adds effort, and moves Go-Live by at least as long as it takes to resolve.
Before kickoff
Data protection | Every approval required for the data classifications in scope for the target environment — including approval to process client-identifying data in the chosen cloud and region where that applies |
Security approvals | Security review complete and the guardrail list final |
Network | Connectivity and DNS approved and in place. On Azure and AWS, the hybrid transit network established |
Firewall rules | Approved egress from the target environment to the identity provider, software artifact sources, and any external data sources the platform must reach. On OpenShift, also approved firewall access for end-user devices |
Cloud environment | Accounts or subscriptions provisioned, sized per the reference architecture. On OpenShift, the cluster provided and running |
Identity | Identity provider ready to federate |
Model access | Foundation model inference and embedding model inference, both enabled in the customer's own cloud, each with approved quota — where models are consumed from the customer's own cloud |
People | A named owner with decision authority, plus a deputy |
Timeline to Go-Live
Five stages, in order. Each gates the next.
Stage | What completes | Elapsed | Unique effort |
|---|---|---|---|
Discovery and configuration | Customer landing zone mapped onto the reference platform, configuration values agreed and signed off | 4 weeks | 2 SE-weeks |
Landing zone validation | Customer environment verified against the reference | 4 weeks | 1 SE-week |
Platform build | Cluster and platform services running and reconciling | 6 weeks | 4 SE-weeks |
Integration | Identity provider, model access and data sources connected | 6 weeks | 3 SE-weeks |
Verification and Go-Live | Acceptance met, tenant transferred to the ongoing service | 6 weeks | 2 SE-weeks |
Total | 26 weeks | 12 SE-weeks |
What changes effort and duration
A divergence is any requirement that does not match the standard in Section 2. Add its delta to the baseline in Section 1 rather than rebuilding the estimate. Deltas are additive across divergences. Every divergence needs Solutions Engineering review and Solutions Engineering Lead approval before it is quoted.
Divergences are technical or operational. A request for programme delivery, use-case build or a product change is not a divergence and has no delta on this page. It is out of scope, and it is priced by the function that owns it.
The table is not exhaustive. A requirement that is not listed is still a divergence. It has no published delta and is sized at review.
Factor | If the customer wants | Setup | Duration | Ongoing (FTE percentage points) |
|---|---|---|---|---|
Source structure | A customer-specific deployment configuration and source structure rather than forking the reference platform and taking upstream releases | +3 SE-weeks | +3 weeks | +15 to +25% FTE |
Shared cluster | The platform on a shared cluster rather than a dedicated one | +2 SE-weeks | +2 weeks | +10 to +20% FTE |
Release tooling | A different GitOps or CD controller rather than the one the reference platform deploys | +2 SE-weeks | +2 weeks | +5 to +10% FTE |
Ingress controller | A customer-specific ingress controller rather than the one the reference platform deploys | +2 SE-weeks | +2 weeks | +5% FTE |
Key management | An external key store or HSM rather than the cloud key service the reference platform uses | +2 SE-weeks | +2 weeks | +5% FTE |
Access | No standing access — every action raised, approved and executed per ticket | +3 SE-weeks | +4 weeks | +10 to +25% FTE |
Observability stack | A customer-specific observability stack rather than the one the reference platform deploys | +2 SE-weeks | +2 weeks | +5 to +10% FTE |
Log and metric destinations | Delivery to additional sinks, or SIEM integration beyond one sink | +1 SE-week | +1 week | +5% FTE |
Environments | Each environment beyond the standard two — per environment | +2 SE-weeks | +2 weeks | +5% FTE |
Data services | Existing customer data services consumed rather than those deployed by the reference platform | +2 SE-weeks | +2 weeks | +10 to +20% FTE |
Work management | The customer's task management system rather than Unique's | +1 SE-week | none | +5% FTE |
Review model | Review and approval of every change rather than at stage gates | +2 SE-weeks | +2 weeks | +10% FTE |
Migration | An existing tenant moved rather than deployed new | +6 SE-weeks | +8 weeks | none |