Quick Summary: Stop chasing clients for email sign-offs before deployment; building a custom tool from scratch usually creates more technical debt than it solves. Instead, integrate approval gates directly into the communication channels your clients already use, like Slack or simple email triggers.

Client Approvals Are Broken: Why Building a New Tool Won’t Fix Your Trust Issues

I saw a thread recently asking, “Thinking about building a simple tool for client approvals — would this be useful?” My immediate, visceral reaction was to scream “No!” at my monitor, but then I took a sip of lukewarm coffee and remembered the deployment disaster of 2018.

Here is the war story: We were deploying a massive update to prod-finance-01 for a high-profile fintech client. My Project Manager, eager to leave for the weekend, told me, “Yeah, Darian, go ahead. The client gave the thumbs up.” I pushed the button. The pipeline went green. Twenty minutes later, the client’s CTO was on the phone screaming that the new tax calculation logic was wrong.

When we audited the trail, the “approval” turned out to be a vague text message sent to the PM saying, “Looks good mostly,” regarding a PDF mockup from three weeks prior. It wasn’t an approval of the UAT environment. It wasn’t a sign-off on the build. It was noise.

We spent the entire weekend rolling back database migrations because we treated a text message as a deployment gate. That is why I have strong feelings about this. Building a shiny new SaaS tool won’t solve this because the problem isn’t the interface; the problem is the process gap between technical execution and human authorization.

The Root Cause: The “Black Box” Effect

The reason client approvals are a nightmare isn’t that we lack buttons to click. It’s because the client lives in Email/Slack/Teams, and the deployment lives in Jenkins/GitLab/AWS.

When you ask a client to “log into this dashboard to approve,” you are asking them to leave their workflow and enter yours. They won’t do it. They will just email you “Approved,” and then you (the engineer) become the manual proxy, clicking the button for them. That breaks the chain of custody. We need to bring the approval to them, while keeping the audit trail for us.

Solution 1: The Quick Fix (The “Low-Code” Webhook)

If you are tempted to build a full-stack app for this, stop. You can prototype this in an afternoon using tools you probably already have. The goal here is to let the client approve via a form that triggers your pipeline.

The Strategy: Create a Google Form or Typeform that sends a payload to a webhook (Zapier or n8n) which triggers a Jenkins build or a GitHub Action dispatch.

// Example Payload sent to your CI pipeline
{
  "event_type": "client_approval",
  "client_payload": {
    "approver_email": "client@example.com",
    "environment": "staging-web-02",
    "status": "APPROVED",
    "timestamp": "2023-10-27T14:00:00Z"
  }
}

This is “hacky” but effective for small agencies. The client gets a URL, they click “Yes”, and the robot starts working. You have a timestamped record of who clicked what.

Solution 2: The Permanent Fix (ChatOps Integration)

This is where I try to push all my teams at TechResolve. If your client is in a shared Slack or Teams channel, put the approval gate right there. Do not make them leave the chat.

The Strategy: Use a Slack App (like the AWS Chatbot or a custom Lambda) to post a notification when UAT is ready.

Pro Tip: Never allow a “Deploy to Prod” button to work without Multi-Factor Authentication (MFA) or a restrictive permissions check on the backend, even inside Slack.

I use a simple Python script in a Lambda function that listens for a “slash command” or button press.

def lambda_handler(event, context):
    user_id = event['user']['id']
    action = event['actions'][0]['value']
    
    # Check if the user is actually authorized in your IAM/User DB
    if not is_authorized_approver(user_id):
        return {
            "text": "Nice try, but you don't have clearance for prod-db-01."
        }

    if action == "deploy_prod":
        trigger_pipeline("production", user_id)
        return {
            "text": f"🚀 Deployment initiated by <@{user_id}>. Hold on to your butts."
        }

This creates a public, immutable log in the chat history. Everyone sees who pushed the button. Social accountability is a powerful drug.

Solution 3: The ‘Nuclear’ Option (Hard Pipeline Gating)

Sometimes, clients are chaotic. They will approve things verbally and deny it later. For these scenarios, we use the “Nuclear” option: Environment Freezing.

The Strategy: We configure GitLab CI or GitHub Actions with a “Manual” gate that is strictly locked to specific external user accounts (Guest accounts). The pipeline pauses indefinitely at the pre-prod stage.

Here is what that looks like in a simplified GitLab CI config:

deploy_to_production:
  stage: deploy
  script:
    - ./deploy_script.sh
  environment:
    name: production
    url: https://prod.example.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
      allow_failure: false
  # The 'Nuclear' part: strictly limited access
  needs: ["uat_verification"]

This forces a specific human to log in and click “Play.” It’s annoying, but for mission-critical financial or medical apps, annoyance is a feature, not a bug.

Final Thoughts

Don’t build a new tool just because you are frustrated with email threads. The tool isn’t the issue—the audit trail is. Whether you use a simple webhook or a complex ChatOps bot, ensure you are solving for accountability, not just convenience.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions