Coca-Cola / Judo promo platform

Challenge

Coca-Cola runs promotional programs across a large, distributed retail footprint. Subsidiaries and regional teams each need to configure, approve, and track promos without a separate engineering effort for every market. The business required internal enterprise promo-management tools that internal operators could rely on daily — not a one-off campaign site, but a durable platform with predictable releases and long-horizon support.

When I joined as technical lead, the front-end and cloud environment needed an owner who could translate Coca-Cola leadership priorities into architecture decisions, ship incrementally, and keep the system maintainable as requirements evolved over years — not quarters.

Constraints

Several constraints shaped every technical decision:

• Enterprise operator workflows — Users are internal promo managers, not consumers. Flows emphasize validation, auditability, and error recovery over marketing polish.
• Multi-year ownership — A platform that outlives any single feature team needs clear module boundaries, typed contracts, and deployment patterns that new contributors can adopt quickly.
• Cloud cost and reliability — AWS resources had to scale with usage without surprise bills; environments needed parity between staging and production.
• Organizational continuity — Direct partnership with Coca-Cola leadership meant architectural choices were explained in business terms as well as engineering terms.

Approach

I owned the Angular front-end and AWS cloud architecture end to end: environment design, delivery pipelines, and ongoing platform support.

Front-end architecture (Angular + TypeScript)

The UI was built as a modular Angular application with strict TypeScript boundaries. Feature areas — promo configuration, approval queues, reporting views — were isolated into lazy-loaded modules so teams could work in parallel without entangling shared state.

// Illustrative pattern: feature module with typed service boundary
@NgModule({
  imports: [CommonModule, PromoRoutingModule, SharedUiModule],
  declarations: [PromoListComponent, PromoDetailComponent],
  providers: [PromoApiService],
})
export class PromoFeatureModule {}

Key front-end decisions:

• Typed API contracts — DTOs and service interfaces kept the UI aligned with backend payloads; breaking changes surfaced at compile time rather than in production.
• Reactive forms with validation layers — Complex promo rules were expressed as composable validators, reducing duplicate client-side logic across screens.
• Shared component library — Repeated patterns (data tables, status chips, date-range filters) lived in a shared module so subsidiary-specific screens stayed consistent without copy-paste.
• Observable async flows — RxJS pipelines handled pagination, filtering, and in-flight request cancellation for data-heavy operator screens.

AWS cloud environment

Cloud work focused on a predictable, repeatable deployment model rather than bespoke per-release infrastructure:

• Environment separation — Distinct AWS accounts or namespaces for development, staging, and production with IAM roles scoped to least privilege.
• CI/CD integration — Automated build, test, and deploy stages so releases were repeatable and rollback-friendly.
• Infrastructure as code — Core resources were defined in version-controlled templates, making environment drift visible and reversible.
• Monitoring and alerting — Health checks and error-rate thresholds gave operators confidence that overnight batch jobs and daytime interactive use were both covered.

Delivery and long-term support

Over five-plus years of direct Coca-Cola leadership partnership, delivery followed a cadence of small, verifiable releases:

1. Requirements intake — Leadership priorities mapped to bounded epics with explicit acceptance criteria.
2. Incremental ship — Features landed behind feature flags where rollout risk warranted it.
3. Regression safety — Automated linting, unit tests on critical validators, and staged deploys before production promotion.
4. Knowledge transfer — Documentation covered environment access, release runbooks, and module ownership so support did not depend on a single engineer.

As the engagement approaches its July 2026 conclusion — with Coca-Cola bringing promo management in-house — the emphasis shifted to transition readiness: stable releases, clear ownership boundaries, and operational runbooks that survive the handoff.

Outcomes

The platform delivered durable internal promo-management capability for Coca-Cola and its subsidiaries at enterprise scale — not as a single campaign build, but as a multi-year ownership surface with an orderly handoff.

Decisions that held

| Decision | Why it mattered | Cleared result | | --- | --- | --- | | Lazy-loaded Angular feature modules | Subsidiary screens and approval queues needed parallel work without shared-state entanglement | Maintainable UI boundaries across years of incremental delivery | | Typed DTO / service contracts | Promo payloads change; silent client/server drift is expensive in operator tools | Contract breaks surface at compile time instead of in production | | Shared UI library for operator patterns | Tables, status chips, and date filters repeated across markets | Consistency without copy-paste forks per subsidiary | | Environment parity + IaC on AWS | Staging that lies about production burns release confidence | Repeatable deploys and reversible environment drift | | Feature-flagged incremental ship | Promo calendars do not pause for big-bang releases | Risky changes land behind flags with staged promotion | | Runbooks before Jul 2026 handoff | Coca-Cola bringing promo management in-house | Continuity without a single-engineer dependency |

Measurable impact

| Area | Result | | --- | --- | | Partnership tenure | 5+ years of direct Coca-Cola leadership collaboration | | Platform role | Technical lead for front-end and cloud environment | | Stack delivered | Angular + TypeScript + AWS with CI/CD and long-term support | | Lifecycle | Sustained delivery from 2019 through 2026 with an orderly in-house transition |

Metrics are framed to publicly attestable facts. No confidential promo volumes, revenue figures, or internal system identifiers are disclosed.

What this demonstrates

• Enterprise platform ownership — Years of architecture, delivery, and support for Fortune-500 promo operations — not a campaign microsite.
• Judgment under constraints — Balancing leadership priorities, cloud economics, and front-end maintainability across a multi-year horizon.
• Clean handoff discipline — Designing for continuity as ownership transitions in-house, not optimizing only for the next sprint.

For a parallel example of multi-brand retail platform delivery at even larger geographic scale, see the Engagement Agents case study.