Client Environment Intake (Onboarding)
A checklist with 7 steps: Inventory every deploy target the client owns before writing a single pipeline config.
By InnovaAI ResearchPublished
What are the steps?
Client Environment Intake (Onboarding)
- 01
Inventory every deploy target the client owns before writing a single pipeline config
List production, staging, and any legacy hosts by IP or hostname, then note which provider each sits on. Agencies that skip this step discover a forgotten shared-hosting box during the first Friday deploy.
- 02
Map repository-to-environment bindings and confirm branch strategy
Record which Git remote feeds which environment and whether the client uses trunk-based or long-lived release branches. DeployHQ and Railway both behave differently when a repo has three remotes and no documented default.
- 03
Document the client's change-approval chain in writing
Name the person who signs off on production pushes, the channel where approval happens, and the expected response window. A retainer client with no named approver will stall every release at the same gate.
- 04
Capture secrets and access ownership, not just the values
For each credential, record who created it, who can rotate it, and where the recovery path lives. Feature flag keys, database passwords, and SSH keys all need an owner outside the agency.
- 05
Baseline current deploy duration and failure rate over the last 30 days
Pull timestamps from the client's existing logs or ask their team for a rough figure. Without a baseline, no agency can prove that a new pipeline cut release time or reduced rollbacks.
- 06
Flag compliance and data-residency constraints that limit tool choice
Note any requirement that code or client data stay in a specific region or on-premise. Stonebranch and FeatureFlags.app both support self-hosted paths, which matters when a client contract forbids shared infrastructure.
- 07
Publish the intake summary to the client and get written acknowledgment
Send a one-page summary of environments, approvers, and constraints, then ask the client to confirm or correct it. This document becomes the reference point when a deploy breaks at 6pm on a Friday.