Skip to content
Pablo.
Selected work

Professional · Magazord Digital Commerce

Modernizing e-commerce at scale

Migrating legacy storefronts to React, Next.js, and TypeScript.

Role
Frontend Developer
Period
Feb 2022 — Aug 2025
Company
Magazord Digital Commerce
Status
2,000+ stores
  • React
  • Next.js
  • TypeScript
  • Storybook
  • Design System

01 / Overview

Magazord is a digital commerce platform used by more than 2,000 stores. I joined as a Frontend Developer and spent three and a half years on the modernization and evolution of its applications.

A large part of that work was moving interfaces off PHP and Twig onto React, Next.js and TypeScript — including the Customer Area — while integrating with existing APIs and improving the quality of the frontend itself.

02 / Context

The context.

The platform already served a large number of stores. Parts of the frontend still lived in server-rendered PHP templates. That stack could ship pages, but it made reuse, consistency and performance harder than they needed to be.

The job was not a greenfield rewrite. It was to migrate and evolve real product surfaces without breaking the experience for stores that were already live.

03 / Challenge

What made it hard.

Legacy templates collect exceptions over time. Migrating them means deciding which exceptions are business rules and which ones are just leftovers.

The frontend also needed a more durable shape: TypeScript, a Design System, Storybook and a component model that reduced duplication instead of copying markup from one template to the next.

04 / Role

My role.

I worked as a Frontend Developer on the applications that store customers actually use. That included migrating PHP/Twig views to React and Next.js, integrating APIs and contributing to the Design System.

Performance was part of the same work. A migration that looks modern but ships a heavier bundle is not a modernization.

05 / Work

What I actually built.

  • Legacy migration

    Rebuilding PHP/Twig interfaces in React and Next.js, in TypeScript, without treating the old templates as a visual spec to copy blindly.

  • Customer Area

    Developing and evolving the Customer Area — a dense, logged-in product surface — on the new stack.

  • Design System

    Shared components and Storybook, so common UI stopped being reimplemented in every template.

  • API integration

    Connecting the new frontend to existing APIs and handling loading, error and empty states explicitly.

  • Performance

    Reducing JavaScript sent to the browser. Bundle size on the surfaces I worked on dropped by about half.

Migration

From legacy surface to new frontend

Legacy surface

  • PHP / Twig
  • Repeated markup
  • Page-specific UI

Incremental migration

New frontend

  • React / Next.js / TypeScript
  • Shared components
  • Design System
  • Storybook

Migration by product surface, not a big-bang rewrite

06 / Engineering

Decisions I would still make.

  • Migrate in product slices, not as a big-bang rewrite

    Stores were already live. Replacing a surface only when the new one could carry the same rules — and then removing the old template — kept the risk contained.

  • A Design System is cheaper than another copy of the same component

    The legacy UI repeated the same markup across templates. Shared components and Storybook made the new frontend slower to start and faster to change.

  • Performance is a product requirement

    Moving to React is not automatically faster. The ~50% bundle reduction came from being careful about what the client actually needed to download.

07 / Stack

  • React
  • Next.js
  • TypeScript
  • Storybook
  • Design System

08 / Impact

Impact.

Stores
2,000+
Review conversion
6.7% → 9.2%
Bundle reduction
~50%

09 / Learned

What this work taught me.

  • I had to read the legacy templates to understand the business rules before replacing them.

  • A Design System helps when several surfaces share the same UI language — and only if those components are actually reused.