The CI/CD Scorecard Technical Diligence Keeps Flagging Across Portfolio Companies

Founder-led and lower-middle-market software businesses often grew without a dedicated platform or DevOps hire, which means their pipeline, if one exists, reflects whatever the founding engineer set up years ago and never revisited. DevOps spend as a share of revenue at that stage tends to run well under what a more mature software company would budget¹, which is consistent with underinvestment in this specific area rather than a deliberate choice.

That's useful context for a 100-day plan: this isn't usually a company-specific failure, it's a predictable pattern across this segment, and it responds well to a standard playbook applied consistently.

Score each newly acquired company against a fixed set of rows, in place, partial, or missing, so the operating partner can compare portfolio companies against each other on the same scale rather than relying on each company's own self-assessment. The scorecard should be short enough to complete during the first thirty days, since the goal is triage, not a full audit.

Keep the scorecard itself standard across every acquisition, even when the underlying tech stacks differ significantly, so it produces a comparable number the operating partner can track across the whole portfolio over time.

Score each newly acquired company on these rows:

• Pipeline exists: is there an automated build and test step that runs on every code change, or does a deploy still mean someone running a script by hand?
• Deploy gating: does a passing test suite have to succeed before anything reaches production, or can a failing build still ship?
• Lead time for changes: how many days pass between a commit and that change reaching production, once a basic pipeline exists?
• Ownership: does every row scored partial or missing have a named owner and a timeline attached in the value creation plan?

The most basic and most revealing row: is there an automated build and test step that runs on every code change, or does a deploy still mean someone running a script from their own laptop. A surprising number of otherwise healthy lower-middle-market businesses score missing on this row, and it's usually the fastest, cheapest fix on the whole scorecard.

Standing up a basic GitHub Actions or GitLab CI pipeline, whichever matches where the company's code already lives, is typically a days-long project once someone owns it, not a months-long one.

Lead time for changes, the days between a commit and it reaching production, is one of the clearer signals of pipeline maturity once a basic pipeline exists². A company where a deploy can happen regardless of whether tests pass, or where tests barely exist, tends to show up with a longer, less predictable lead time because releases get held up by manual verification instead.

This row also tends to correlate with engineering morale at the portfolio company level in a way that's easy to underweight during diligence: engineers who've been shipping without a safety net for years are often the most receptive to finally getting one.

Attach a specific owner and timeline to every row scored partial or missing, and fold it into the standard 100-day plan rather than treating it as a separate technical initiative that competes for attention against commercial priorities. A CI/CD gap is cheap to fix relative to almost everything else on a typical 100-day plan, and closing it reduces deployment risk across the business immediately.

Revisit the scorecard again at the next portfolio review, since a company that scored well shortly after acquisition can drift back toward missing once the initial attention moves elsewhere.

A newly placed technical leader at a portfolio company gets more credibility from fixing the basic CI/CD gap quickly than from almost anything else they could do in the first month, because it's visible, it's fast, and it immediately reduces a risk everyone already half-knows exists. Use that early win deliberately to build trust with the existing engineering team before tackling harder, slower organizational changes.

An engineering team that's been shipping without a real pipeline often knows exactly where the risk is; they usually just haven't had the authority or budget to fix it themselves. Give that team credit for the fix publicly, since it builds the trust you'll need for harder changes later, and it signals that the new leadership notices and fixes real problems rather than just reorganizing the ones already visible.