Why your deploy process is scaring your investors

I sat on a diligence call last month. A seed-stage startup in Amsterdam was raising a Series A. The lead investor had brought in a technical advisor, the kind of person who has been a staff engineer at three companies and can smell a fragile deploy process in two questions. The founder was nervous. He should have been.

The advisor did not ask about the product roadmap. He did not ask about the market size or the cohort retention numbers. Those questions came later. The first thing he asked was: “Walk me through what happens when one of your engineers merges a pull request to main.”

The founder paused. Then he said: “We have a script.”

That pause cost him the round. Not immediately. The round closed, the lead investor had already decided on the market thesis. But the valuation came in 15% below the term sheet they had been discussing, and the investment agreement included a specific milestone: “Operational maturity review at 90 days, tied to tranche release.” The deploy process was the reason.

I have been on that call from the other side too, as the person brought in to do the technical diligence. I know what the questions mean and what the answers reveal. Most founders do not. So I am writing it down.

The five questions investors actually ask

Technical diligence for a funding round is not a code review. Nobody reads your source. They ask five questions, and each one is designed to expose a specific kind of operational risk. Here they are, in the order they usually come.

1. What happens when someone merges to main?

This is the deploy question. The investor is listening for whether deploys are automated, manual, or somewhere in between. The wrong answer is any sentence that contains the word “script” or “SSH.” The right answer describes a pipeline: CI builds, tests run, an artifact is produced, something syncs it to the cluster.

The investor is not asking because they care about your CI tool. They care because a manual deploy process is a single point of failure. If the person who wrote the deploy script leaves, or is on vacation, or makes a mistake at midnight, production is down. That is operational risk, and operational risk is investment risk.

2. How long does it take to roll back a bad deploy?

This is the recovery question. The investor wants to know that when something breaks, you can undo it quickly. The wrong answer is “we would figure it out” or “we have not had to yet.” The right answer is a number, measured, in minutes. A GitOps setup with ArgoCD gives you this for free: revert the manifest commit, ArgoCD syncs, the bad version is gone in under a minute. A manual deploy process does not, because rollback requires the same fragile steps that the deploy required, in reverse, under pressure.

3. What is your uptime and how do you know?

This is the observability question. The first half of the answer is a number. The second half is the trap. If you say “four nines” and then cannot explain how you measure it, the investor knows you are guessing. If you say “we track it in Grafana, here is the dashboard” and you can show the SLO panel with error budget burn rate, the diligence moves on. The number matters less than the measurement. A startup that says “99.2% over the last quarter, measured by Prometheus, with a one-hour error budget window” is more credible than one that says “basically always up.”

4. What happened in your last incident?

This is the postmortem question. The investor is not asking to find out if you have incidents. Everyone has incidents. They are asking whether you have a process for learning from them. The wrong answer is “we have not had one.” That tells the investor either that you are lying, that you are too small to have meaningful traffic, or that you do not notice when things break. None of those are reassuring. The right answer is a story: what broke, how long it took to find, what you changed to prevent it. If you can show a written postmortem, you are ahead of 80% of startups at your stage.

5. Who has access to production?

This is the security question, asked without using the word security. The investor wants to know whether a single compromised laptop or a disgruntled engineer can take down the company. The wrong answer is “everyone” or “the founder has the root password.” The right answer describes RBAC, scoped access, an audit log, and a break-glass procedure for emergencies.

What the pause reveals

Back to the Amsterdam call. The founder said “we have a script.” The advisor did not react. He wrote something down and moved on. What he wrote, I found out later, was: “Manual deploy. Single point of failure. No CI/CD. Operational risk: high.”

The founder lost the room in that one sentence. Not because a deploy script is inherently disqualifying. Plenty of well-funded startups run on scripts for longer than they should. He lost the room because the pause before the answer told the advisor three things.

First, the founder had never been asked the question before, which meant nobody on the team had thought about it. Second, the founder was embarrassed by the answer, which meant he knew it was not good enough but had not fixed it. Third, the answer signaled that operational maturity was not a priority, which for a Series A investor is a proxy for whether the team can scale beyond the founders.

The pause is what investors remember. A confident, specific answer, even if the current process is not perfect, signals that the team is aware and in control. A hesitant, vague answer signals that the team is hoping nobody looks.

What a deploy process that passes diligence looks like

I am going to describe the deploy process I install for startups before they go into a raise. Not the ideal process. The one that survives a technical diligence call without requiring anyone to stretch the truth.

The pipeline looks like this. An engineer merges a pull request to main. GitHub Actions runs the test suite, builds a container image, pushes it to GitHub Container Registry, and updates a manifest in a separate deploy repository. ArgoCD, running in the cluster, detects the manifest change and syncs it. The new version is live in under five minutes from merge. No human touched the cluster. No human ran kubectl.

# .github/workflows/ci.yaml
name: ci
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  update-manifest:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: ${{ github.repository }}-deploy
          token: ${{ secrets.DEPLOY_TOKEN }}
      - run: |
          sed -i "s|image: ghcr.io/.*|image: ghcr.io/${{ github.repository }}:${{ github.sha }}|" apps/api/deployment.yaml
          git commit -am "deploy: ${{ github.sha }}"
          git push

That is the entire pipeline. Build, test, push, update manifest. ArgoCD does the rest. When the investor asks “what happens when someone merges to main,” the founder can answer in one sentence: “CI builds and tests, pushes the image, updates the manifest in the deploy repo, and ArgoCD syncs it to the cluster. No human touches production.” That answer ends the question.

Rollback is the same flow in reverse. Revert the manifest commit, ArgoCD syncs, the previous version is live. When the investor asks “how long does it take to roll back,” the answer is “under a minute, it is a git revert.” That answer also ends the question.

The observability side is Prometheus scraping the services, Grafana showing an SLO dashboard with error rate and latency, and five alerting rules routed to Slack. When the investor asks “how do you know your uptime,” the founder opens Grafana and shows the panel. The measurement is visible. The number is defensible.

The incident side is a written postmortem from the last real incident, in a folder in the repo, with an action item that is closed. When the investor asks about the last incident, the founder pulls up the document. The story has a beginning, a middle, and a fix.

The access side is RBAC scoped per namespace, no cluster-admin for developers, a break-glass account that is audited. When the investor asks who has access to production, the answer is specific and bounded.

None of this is exotic. None of it requires a platform team. It is the same foundation I have described before, and it is the thing that turns a nervous pause into a confident answer.

The cost of the pause

I want to put a number on this, because founders respond to numbers and this one is concrete.

The Amsterdam startup I described was discussing a term sheet at a pre-money valuation of EUR 14 million. After the diligence call, the valuation came in at EUR 11.9 million. That 15% gap, on a EUR 2.5 million raise, cost the founders roughly EUR 375,000 in dilution. The deploy process was the proximate cause. The investor used it as a signal that the team was not operationally mature enough for the valuation they were asking.

The tranche milestone cost them more. They had to hire a consultant, me as it happened, to build the CI/CD pipeline, the observability stack, and the runbooks within 90 days to release the second tranche. That work took seven weeks and cost a fraction of the dilution they had already taken. They could have done it before the raise, kept the full valuation, and avoided the tranche entirely.

I see this pattern regularly. The deploy process is the cheapest part of the infrastructure to fix, and it is the part that shows up first in diligence. The founders who fix it before the raise keep their valuation. The founders who fix it during the raise pay for it in equity. The founders who never fix it do not raise, or raise on terms that punish them for the gap.

What I tell founders before a raise

When a founder comes to me and says they are raising in three months, I have one piece of advice: get your deploy process in order before the first diligence call. Not because the deploy process is the most important thing about your company. Because it is the first thing a technical advisor will probe, and a weak answer there colors every answer that follows.

The work is not large. A CI/CD pipeline with GitOps, an observability stack with five alerting rules, a written postmortem from your last incident, and an access policy you can describe in two sentences. That is the surface area a diligence call covers. If you can answer all five questions without pausing, you will spend the call talking about your product and your market, which is where you want to be.

If you are a startup reading this and recognizing the gap, Basecamp exists for exactly this reason: digitalaultis.com/basecamp

The investors are going to ask. The only question is whether you will pause.