PayPal processed 1.4 billion transactions annually and employed over 12,000 customer service representatives at the time of this engagement. Seventeen separate development teams were building on top of their Pega platform simultaneously, each with its own sprint cadence, its own backlog, and its own definition of ready. When all of that converges on a single codebase without a governed deployment process, releases become events rather than operations, and every event carries risk.

Seventeen Teams, One Codebase, No Reliable Way to Release

Pega’s standard DevOps tooling in 2016 was built for teams, not programs. It handled releases well when one group owned the codebase and controlled the schedule, but had no answer for 17 teams contributing simultaneously with no single owner of the end-to-end release cycle. PayPal had spent more than ten years building out their Pega practice. They had the investment, the teams, and the roadmap.

What they needed was an architecture for releasing code at the pace their business required, without the risk of one team’s changes breaking another team’s work in production. Rulesware designed that architecture from scratch, inside Pega itself, building a deployment process that could be governed and versioned the same way any other business process on the platform could.

Rulesware Reframed the Release Problem as a Process Design Challenge

Instead of coordinating across 17 teams manually at the end of each sprint, the approach was to build automated quality gates at every check-in, give every team visibility into the shared pipeline without requiring manual coordination between leads, and define ownership clearly enough that no single approval layer became a bottleneck. Building that process inside Pega meant it could be improved, versioned, and audited using the same tools the teams already knew.

How Rulesware Built the Deployment Architecture Inside Pega Itself

Rulesware automated the end-to-end release process as a flow inside Pega, aligned to PayPal’s existing RPM-based deployment model rather than requiring them to change how they managed releases at the organizational level. Automated code review ran at every check-in, which meant quality problems were caught continuously rather than at the end of a sprint when the cost of fixing them was highest.

A test case and test suite management portal gave every team visibility into the release pipeline. Role-based access control kept governance intact across every delivery function without creating bottlenecks at any single approval layer.

Weekly Releases Across 17 Teams, 98% Automated Testing, and a PegaWorld Stage

Weekly releases from all 17 teams ran reliably, backed by 98% automated regression testing across the full application. PayPal presented the solution at PegaWorld, which for a Pega partner is the closest thing to an independent audit of the work. Rulesware has maintained a 100% client success rate across twenty years of Pega implementations, with 80% of clients returning for additional engagements.

What was built for one of the world’s largest digital payments platforms has been refined through every major Pega version since, across financial services, healthcare payer, and insurance programs running multi-team delivery at scale.

Constellation architecture, agentic AI integrations, multi-team delivery programs, and continuous delivery expectations from business stakeholders who do not think in release cycles have made deployment governance more complex than it was in 2016, not less. The organizations adding agentic AI and automation layers to their Pega programs today are introducing new deployment complexity on top of existing coordination challenges.

An AI component that behaves one way in development and differently in production because the release process is inconsistent is a governance risk, and the firms that built deployment discipline before AI arrived are the ones absorbing that complexity without incident.

If your organization is running Pega across multiple teams and the release cycle is the constraint, that is where this conversation should start.