Custom Engineering¶
Service ownership
Owner: professional-services (ps-pm@clouddigit.ai) — Status: GA — Last audited: 2026-05-11
Bespoke engineering work — Terraform modules, integrations, automation, glue.
What it is¶
When the off-the-shelf services don't quite line up with what you need to build, Custom Engineering bridges the gap. Typical work:
- Custom Terraform modules for your in-house IaC pattern
- CI/CD integrations with your existing pipeline (Jenkins, GitLab, Bitbucket Pipelines)
- Service-mesh integrations for K8s
- Identity federation (SAML / OIDC) with your IdP — Keycloak, Azure AD, Okta
- Custom backup / DR orchestration beyond what BaaS / DRaaS provide
- Migration tooling for unusual source systems
- Cost / chargeback automation that pulls from billing API and pushes to your finance system
Engagement shape¶
T&M, with a defined Statement of Work that lists deliverables and acceptance criteria. Most engagements are 2–8 weeks.
What you get back¶
- Source code (yours; we don't keep IP)
- Tests
- Deployment scripts
- Documentation
- A walkthrough session with your team
Pricing¶
T&M, by senior engineer-day. See Pricing.
Related¶
Operate this service¶
CD engineering team for one-off custom development — integrations, automation, custom features.
What fits¶
- Custom integration between CD service and a customer-specific system
- Automation scripts / IaC modules tailored to customer
- Performance work (kernel tuning, custom NIC drivers, low-latency)
- Custom dashboards / reports
- One-off compliance tooling
What doesn't fit¶
- Long-term application development (use a system integrator)
- Customer's product work (out of scope)
- Open-ended R&D (need scoped deliverables)
Engagement model¶
- T&M for exploration phases
- Fixed-price for well-scoped deliverables
- 4-12 week typical engagements
IAM¶
| Role | Can do |
|---|---|
custom-eng.viewer | View engagement deliverables |
custom-eng.requester | Submit requests |
custom-eng.admin | Sign off engagement scope and acceptance |
CD engineers get engagement-scoped access; output handed over to customer at completion.
Deliverables¶
Standard: - Working code (in customer's repo) - Documentation - Tests - Deployment instructions - Runbook for ongoing operation
Ownership transfers at acceptance; CD doesn't maintain post-engagement unless retained separately.
Pricing¶
- Senior engineer day rate (negotiable for multi-month)
- Discounts for fixed-price deliverables
- Materials at cost
Related¶
Request workflow¶
bash cd professional custom-eng request \ --title "Custom S3 → Splunk pipeline" \ --description "..." \ --budget-cap 40h
CD review: - Scoping conversation (1-2 sessions) - Feasibility assessment - Proposal (timeline, cost) - Customer approves; engagement starts
Sprint cadence¶
For multi-week engagements: 1-2 week sprints with demos. Short engagements: daily standups.
Acceptance criteria¶
Pre-defined at scoping: - Functional requirements (clearly defined "done") - Non-functional (performance, reliability) - Documentation deliverables - Test coverage
Acceptance is a checklist; ambiguity is the enemy.
Code ownership¶
Customer's repo, customer's branch policies. CD engineer commits with their CD principal; PRs reviewed by customer team.
Open source contributions: tracked separately if delivered output goes upstream.
Knowledge transfer¶
End-of-engagement: - Code walkthrough - Architecture document - Operations runbook - Q&A session - Handover sign-off
Customer team should be able to maintain post-handover.
Hypercare¶
2-week hypercare period post-engagement: - Bug fixes for defects in delivered work - No new features - Light support
Beyond: separate engagement.
Related¶
Scope creep¶
Customer adds requirements mid-engagement: - Document as change request - Estimate impact (cost, timeline) - Customer approves change or defers
Engagements without change control overrun.
Acceptance criteria disputed¶
CD delivers; customer says "not what we asked for": - Compare against signed acceptance criteria - If CD missed: fix as part of engagement - If criteria was ambiguous: extend scope (negotiated) - If customer wants different thing: change request
Knowledge transfer didn't take¶
Post-engagement, customer team can't operate: - Hypercare extended (paid) - Additional training engagement - Re-engagement to refactor for clarity
Prevention: continuous KT through engagement, not just at end.
Delivered code has bugs¶
Within hypercare: fix at no additional cost.
After hypercare: bug-fix engagement; customer pays for fix time.
Estimate exceeded¶
Engagement taking longer than planned: - Re-estimate with cause - Customer decides: continue (more cost), reduce scope, or stop - Document cause for future engagements
CD engineer assignment changes¶
Mid-engagement, a CD engineer rolls off: - Replacement engineer onboards (1-3 days ramp) - Engagement continues; some loss of momentum - For long engagements: pre-designated backup engineer
Customer team underpowered¶
CD doing 90% of work, customer team minimal: - Risk: customer team can't operate handover - Surface concern; re-balance involvement - May need to extend engagement for proper KT