Engagement Agents retail platform

Challenge

Engagement Agents coordinates field activations for globally recognized retail brands — in-store displays, promotional materials, and campaign execution that must land correctly across thousands of physical locations. A missed delivery in one mall is invisible at headquarters until a brand manager hears about it from a store lead.

The company needed a marketing-execution platform that could:

• Onboard and configure programs for multiple brands with different rules, assets, and approval paths.
• Operate reliably across 10,000+ retail locations in 5,000+ malls worldwide.
• Give field teams and brand coordinators a single source of truth for what should be live, where, and by when.
• Scale operationally without proportional headcount — configuration and visibility had to be self-serve where possible.

I joined as lead engineer and technical lead, owning the full stack plus UI/UX design and ongoing platform management.

Constraints

• Geographic and organizational scale — A platform that works in one region must not break when rolled out across continents, mall operators, and franchise structures.
• Multi-brand tenancy — Adidas, Sephora, Under Armour, Lego, and others each need isolated configuration without maintaining separate codebases.
• Field-reality UX — Users include brand coordinators in offices and field staff in noisy retail environments; interfaces must work on mid-tier hardware and spotty mall Wi-Fi.
• Continuous operation — Campaign windows do not pause for deploys; releases require backward-compatible API changes and graceful degradation.

Approach

I designed, architected, and shipped the platform on Vue 3, TypeScript, and Node.js, with end-to-end ownership from database-facing APIs through operator-facing interfaces.

Platform architecture

The system follows a classic three-tier pattern tuned for multi-brand retail operations:

// Illustrative API boundary: brand-scoped resource handler
export async function getActivationStatus(
  req: BrandScopedRequest,
): Promise<ActivationStatusResponse> {
  const { brandId, locationId } = req.params;
  return activationService.resolveStatus(brandId, locationId);
}

Core architectural decisions:

• Brand-scoped tenancy — Every query, cache key, and permission check carries a brand context. Cross-brand data leakage is structurally difficult, not merely forbidden by convention.
• Location-centric data model — Malls, stores, and activation sites are first-class entities so coordinators can reason in the language they already use in the field.
• REST APIs with typed contracts — Node.js services expose versioned endpoints; TypeScript types are shared between server and Vue client where practical.
• Event-driven status updates — Activation state changes propagate to dashboards and field views without manual refresh, reducing "is it live yet?" support tickets.

Front-end delivery (Vue 3 + TypeScript)

The operator and field interfaces were built in Vue 3 with the Composition API for reusable logic across brand-specific views:

• Composable business logic — Shared composables encapsulate pagination, filter state, and optimistic updates so brand skins differ in presentation, not behavior.
• Component library for retail patterns — Location pickers, activation timelines, asset previews, and status badges are standardized components with brand-theme tokens.
• Responsive layouts — Field views prioritize thumb reach and legibility; coordinator dashboards prioritize dense tabular data with export paths.
• UI/UX ownership — Because I owned design as well as implementation, iteration cycles were short: wireframe, prototype in Vue, ship to staging, validate with coordinators.

Backend and platform operations

On the Node.js layer, emphasis fell on operational predictability at scale:

• Indexed location queries — Cursor-based pagination and selective projection for subsets of 10,000+ locations.
• Idempotent write paths — Field retries do not create duplicate activations.
• Role-based access — Brand coordinators, field staff, and admins see different capability surfaces enforced server-side.
• Deployment hygiene — Staged rollouts with backward-compatible migrations across at least one release cycle.

Ongoing platform management

Beyond initial architecture, ongoing platform management included brand onboarding playbooks, quarterly performance audits as the location count grew, incident runbooks for partial mall outages, and roadmap alignment with brand retention risks.

Outcomes

The platform powers field activations for globally recognized retail brands at a scale few boutique agencies attempt.

Measurable impact

| Area | Result | | --- | --- | | Retail locations | 10,000+ stores supported on a single platform | | Mall coverage | 5,000+ malls worldwide | | Brand portfolio | 10+ global retailers including Adidas, Sephora, Under Armour, Lego, Pandora, and others | | Engineering scope | Full-stack ownership — Vue 3 / TypeScript / Node, UI/UX design, and platform management |

Scale figures are résumé-attested and cleared for public disclosure. Per-brand activation counts, contract values, and proprietary workflow details are omitted.

What this demonstrates

• Platform engineering at geographic scale — Data models, query patterns, and UX must account for field reality across tens of thousands of locations.
• Multi-brand tenancy without multi-repo sprawl — One codebase serving Adidas and Sephora requires disciplined scoping, not copy-paste forks.
• Technical lead breadth — Architecture, implementation, design, and long-horizon operations owned end to end.

For a complementary example of long-horizon enterprise platform delivery for a Fortune-500 brand, see the Coca-Cola / Judo case study.