Question 1

How do you recognize it?

Accepted Answer

Deploys work in week one, then a client's new developer pushes straight to main and the zero-downtime guarantee quietly disappears. Rollback instructions live in one engineer's head, so a Friday production incident waits until Monday for a fix. Each retainer client runs a different deploy path (one on DeployHQ, one on Railway, one on a hand-built SSH script), and nobody can say which is current. Onboarding a second engineer to a client account takes days of screen-sharing instead of a documented runbook. Clients start asking for change logs and approval trails that the agency cannot produce from its own tooling.

Question 2

Why does it happen?

Accepted Answer

Automation is sold as a delivery accelerant but never scoped as a billable line item, so no one owns pipeline maintenance after launch. Agencies standardize on whichever platform the founding engineer already knew, which means the stack choice is personal rather than client-driven. Client-side developers get repository access without guardrails, so the agency's release process is only as disciplined as the least disciplined contributor. Compliance and multi-cloud requirements surface after the retainer is signed, and retrofitting them into a single-vendor pipeline costs more than the original build.

Question 3

How do you fix it?

Accepted Answer

Write a one-page deploy runbook per client account covering trigger, rollback, and who to call, then attach it to the retainer scope. Move release control out of the repository and into a flag layer so a bad merge can be disabled without a redeploy, using something like FeatureFlags.app for .NET stacks. Audit every client pipeline for single-person dependency this week and name a secondary owner for each one. Price pipeline maintenance as a recurring line item (a few hundred dollars per client per month) instead of absorbing it into the build fee.

More for DevOps Automation