Client Self-Service Portal

The Problem: The portal is a satellite of the core research platform. It maintains its own copy of brand data for operational purposes, while the core platform remains the authoritative source. Changes made in the portal exist in a staging state until approved and exported — but the two systems must stay consistent, and any divergence must be detectable and recoverable.

The Solution: The portal maintains its own PostgreSQL database with a full, consistent record of each brand, including references back to the corresponding entries in the core platform (which uses MongoDB). When a change is approved and exported, it is applied transactionally — either it completes cleanly or it does not apply at all. The staging model means the core platform is never left in an intermediate state due to a partially completed sync.

The Result: data consistency between the two systems is maintained reliably, with a clear, auditable record of what was changed, when, by whom, and whether it has been reflected in the core platform.

The Problem: The design team responsible for the portal does not use a standard component library — they produce fully custom component designs. This required the frontend team to implement highly specific, non-standard UI patterns from scratch rather than composing from a shared library.

The Solution: The Primotly frontend team implemented the designs with pixel-perfect fidelity using a custom component architecture, building each component from first principles to match the design specifications. The portal targets Chrome as its supported browser, letting the team focus on a single, consistent rendering environment rather than managing cross-browser compatibility across the full component set.

The Result: a polished, client-facing interface that meets the high UI standards expected of an enterprise product used by global FMCG brands.

The Problem: The portal enforces validation rules that must stay aligned with the business rules of the core research platform. When rules change — which fields are required, which market combinations are valid, or how brand tags are structured — the portal must be updated to reflect those changes consistently.

The Solution: Business rule updates are applied to the portal on a scheduled basis using a dedicated synchronization script. This controlled, deliberate process ensures rule changes are reviewed and applied intentionally rather than propagated automatically in ways that could introduce inconsistencies.

The Result: validation rules in the portal remain aligned with the core platform, with the team retaining full control over when and how rule changes are rolled out.