Be Digital · Case study

A day-1 starter for a lean ML/Ops team

A team splitting Ops off from Enterprise to sit alongside a growing ML org needed three things at once: a path off a GitLab instance that had fallen out of security compliance, guardrails for AI tooling that wasn't standardized on one vendor yet, and a way to keep a growing AWS surface patched without dedicated infra headcount. This is the starter I built — and where it deliberately leans on a guardrail pattern already proven out rather than reinventing it.

The problem

Three constraints were arriving at once, and none of them had a dedicated owner yet. The GitLab instance running years of proven CI/CD had fallen out of compliance because IT stopped patching it — migration had to preserve that work, not just move source code. New AI tooling was arriving fast, with no standardization on one vendor, which meant tool-specific guardrail config (deny-rules, hooks) would only ever cover part of the team. And everything in AWS outside the already-owned Databricks and Kubernetes platforms had no owner at all, on a team too lean to watch it by hand.

The common thread: none of these could be solved with a bigger team. They needed to be solved with better defaults.

The approach: three starters, one enforcement pattern

Rather than three unrelated deliverables, the guardrail piece became the connective layer. The same "enforce it where every tool passes through, not where one tool happens to read config" lesson — documented in depth here for a single-repo, Copilot-only case — generalizes directly to a multi-tool team standing up from scratch.

Enforcement that survives a tool swap

Tool-level guardrails — .claude/settings.json deny-rules, PreToolUse hooks, copilot-instructions.md — only cover the tool they're configured for. A team that hasn't standardized yet, or that adds a second tool six months in, needs the real boundary somewhere every tool passes through regardless. That's CI, not tool config.

The AWS piece: patching without headcount

Renovate operates on declared dependencies in Git — base images, Terraform provider pins, Helm charts, manifest tags — and opens PRs against them. It does not patch a running host directly. For a lean team, that's still the highest-leverage first move: it requires no new infrastructure, targets the class of vulnerability most likely to go unwatched, and turns "someone should check for CVEs" into a PR that shows up on its own schedule.

What I'd carry to the next team

1. Enforcement has to survive a tool swap. If the guardrail only works for the AI tool you're using today, it's not a guardrail — it's a default that happens to hold until the next tool arrives.
2. Migration exports don't include secrets, by design. CI/CD variables have to be re-entered or synced separately — worth catching before the first pipeline run, not after.
3. "Patch it without headcount" means automating the boring 80%, not hiring for the 20% that's actually hard. Renovate plus a scan-and-rebuild loop covers most of the surface a lean team would otherwise have to watch by hand.
4. Start with the two pieces that map to the next 90 days. The migration and the guardrail gate are usually the ones with a deadline attached; the AWS baseline is the one to grow into as the team's scope grows.