Suat Erken

Engineering leadership / international commerce

Building an EMEA commerce platform—and the organisation to run it

How I built the engineering organisation and shared platform practices behind reliable launches across 13 countries and 27+ locales.

Role
Engineering Manager, EMEA
Period
2022-present
Status
Delivered and operating
Focus
Platform engineering · Engineering leadership
Conceptual EMEA operating model connecting market and customer signals to a shared roadmap, cross-functional delivery, local launches, and common platform standards.
An original, deliberately generic view of the operating model—no internal systems, screenshots, or employer-owned architecture.
13 countriesMarkets launched
27+ localesLocalised experiences
18+ contributorsOrganisation scaled
Zero major incidentsLaunch reliability

Launching a commerce experience across EMEA involves far more than translating a storefront. Payments, compliance, campaigns, integrations, and market priorities vary, while customers still expect one coherent product.

As Engineering Manager for EMEA, I was responsible for the technical direction and for building the organisation that could deliver and operate the platform. This case study uses approved public facts only. It leaves out internal system names, screenshots, commercial data, and employer-owned architecture.

One roadmap, clear ownership

A replatform of this scale cannot sit with engineering alone. Product, design, engineering, regional markets, partners, and compliance all needed to work from one prioritised roadmap, with clear ownership when priorities conflicted.

I grew the EMEA engineering organisation from zero to more than 18 contributors across internal and partner teams. Shared quality standards, regular coaching, and a predictable planning cadence gave teams room to solve local problems without creating a different platform for every market.

Platform boundaries that travel

The platform combined Next.js and TypeScript with commerce APIs, cloud services, and edge caching. I stayed involved through proofs of concept and owned decisions around server rendering, caching, edge behaviour, third-party integrations, code quality, and observability.

We established a small set of boundaries that every team could use:

  • Consistent rendering and edge behaviour across markets.
  • Integration contracts that kept upstream differences away from customer journeys.
  • Automated tests and release checks shared by internal and partner teams.
  • Observability and incident practices in place before launch.
  • SEO and Core Web Vitals treated as product requirements.

Performance during a replatform

A new platform can launch on schedule and still damage search visibility or interaction quality. I owned SEO through the transition and made performance review part of normal pull-request and release work.

Caching, rendering, image delivery, and third-party scripts were assessed against customer experience as well as delivery speed. This kept performance in everyday engineering decisions instead of leaving it for a final audit.

Results

The platform launched on time across 13 countries and more than 27 locales with zero major incidents. At the same time, the organisation grew to more than 18 contributors without losing a shared technical direction.

We watched delivery cycle time, reliability indicators, team health, automated checks, and incident readiness. Those signals were there to expose risk and guide discussion, never to rank individual engineers.

What stayed useful

The launch left behind more than a new storefront. It established clearer platform boundaries, stronger ownership, and teams that could change the system without relying on a small group of specialists.

I use the same approach when introducing AI tools: set the boundaries, decide who owns the result, measure what changes, and give the team enough context to challenge the tool.