Case study 04 BUILD
An internal pipeline management platform: operations, delivery and compliance unified
A multi-entity technology business needed unified governance over multiple delivery pipelines spanning cloud infrastructure, application code and AI-augmented workflows. Off-the-shelf tooling would have meant assembling three or four overlapping SaaS products, at scale-up pricing, with ongoing integration and operational burden. The decision was made to build instead of buy. AI-augmented delivery made the numbers work.
Headline outcome Operations, delivery and compliance unified on one platform. Built instead of bought.
Situation
A growing technology business was running multiple delivery pipelines across cloud infrastructure, application code and AI-augmented workflows. Each pipeline was governed by its own tooling, its own approval logic and its own monitoring. Visibility lived in different places. Failures surfaced in different ways. The teams that needed to see what was happening (Customer Success, Delivery, IT and Compliance) each had a partial view at best.
The leadership question wasn’t “how do we manage one more pipeline?” It was “how do we govern all of them, coherently, without expanding the team to do it?”
What was considered
The instinct in most organisations is to reach for off-the-shelf tooling. We did the same.
Several SaaS platforms were evaluated. Each one covered part of the problem well: pipeline orchestration, AI workflow governance, deployment visibility, compliance reporting. None covered the full picture. Assembling three or four of them to do so would have meant multiple subscriptions at scale-up pricing, integration work across tools that weren’t designed to talk to each other, duplicate authentication and audit trails, and an ongoing operational burden on a two-person IT function that didn’t have spare capacity to run a stack of overlapping tools.
The cost wasn’t only financial. The time cost of assembling and operating several tools, then maintaining the integrations between them as each vendor evolved independently, would have exceeded the cost of building a focused platform that did exactly what was needed.
The decision was made to build instead of buy. Not as an ideological preference, but as the answer that genuinely made the numbers work.
What was built
A unified pipeline management platform sitting above the existing GitHub and GCP infrastructure, providing one place for the four functions that needed visibility and control.
For Delivery and Customer Success: real-time visibility into pipeline state across all active projects, with status surfaced in language non-engineers can act on. Failed deployments, stuck approvals and AI workflow anomalies are visible at a glance, without requiring access to the underlying CI/CD tooling.
For IT operations: a single console for pipeline health across the cloud estate. AI-assisted diagnostics (Gemini for infrastructure analysis, Claude for code-level diagnosis) surface the likely cause of a failure alongside the failure itself, compressing time-to-resolution for the small senior IT team.
For Compliance: governed control over AI-augmented workflows. Dual-approval gates for production changes. Three-tier auto-resolve logic that handles routine failures without human intervention while escalating anything that crosses a defined risk boundary. Full audit trail of who approved what, when, and on what evidence.
The platform consolidates the visibility and governance that would otherwise have required three or four separate SaaS products, at a fraction of the running cost, with a control surface designed for how this specific business actually operates.
How it was built
The platform was architected and delivered AI-augmented throughout. The same toolchain that the platform itself governs (Claude for code, Gemini for infrastructure analysis) was used to compress the build timeline and reduce the senior engineering hours required to deliver each phase.
The technology stack is deliberately conservative under the hood: GCP for hosting, GitHub for source control, Cloud Build and GitHub Actions for the underlying pipeline execution, BigQuery for the audit and analytics layer. The novelty is in the orchestration and the operator-facing console, not in the substrate.
This matters because the platform is not exotic to operate. The IT team can reason about it. The compliance team can audit it. If the operator who built it stepped away tomorrow, another senior engineer could pick it up. That’s a deliberate design constraint, not an afterthought.
Operating model
Built in three phases, each delivering value before the next begins.
Phase 1 — Visibility (operational). The Customer Success and Delivery views, with real-time pipeline state and status surfaced in plain language. Already in production use across active projects.
Phase 2 — Diagnostics (in flight). AI-assisted root-cause surfacing for IT operations. Gemini handling infrastructure-layer analysis, Claude handling code-layer diagnosis. Reduces time-to-resolution and reduces dependency on the most senior engineering hours.
Phase 3 — Governed control (in flight). Dual-approval production workflows, three-tier auto-resolve, and the full compliance audit trail. The piece that turns the platform from a visibility tool into a governance tool.
Each phase was scoped, delivered and operated before the next phase began, proving the model and earning the right to build the next layer. This is a deliberate choice. Custom platforms fail when they’re built end-to-end before anyone uses them; they succeed when each phase pays for itself.
Result
The platform is being measured against four outcomes, defined at the start of the engagement. More efficient IT operational management: senior engineering hours spent on pipeline incident response are reduced through AI-assisted diagnostics and auto-resolve handling of routine failures. Better visibility and monitoring for Delivery and Customer Success: pipeline state surfaced in language non-engineers can act on, without granting access to the underlying CI/CD tooling. Better control of AI workflows for Compliance: governed approval gates and full audit trail across all AI-augmented production changes, the control surface that makes AI delivery defensible to auditors and customers. Lower total cost of ownership than the SaaS-assembled alternative: across both subscription cost and the operational time required to integrate and maintain a multi-vendor stack.
Phase 1 is delivering against the visibility outcome in production today. Phases 2 and 3 will deliver the diagnostics and governance outcomes as they ship. The cost outcome is structural. It was true the moment the build-vs-buy decision was made and is reinforced as each phase ships without a corresponding subscription line item.
This engagement is what Build looks like at full scale: a senior operator owning the architecture, delivery and operational handover of a platform that genuinely couldn’t be bought off the shelf. At least not without paying significantly more for significantly less fit. The build-vs-buy answer wasn’t ideological. It came out of an honest evaluation of what the off-the-shelf options covered, what assembling them would actually cost, and what the operating burden would be on a small team afterwards. Sometimes the answer is buy. In this case the answer was build, and the case for building got stronger when AI-augmented delivery compressed the timeline and the team size required to make it real.