Skip to content
Book a call

E-commerce · E-commerce

Dope Places

A storefront and its admin, localized from one codebase, live in two languages at launch.

Role
Full stack
Duration
8 months
Team
2 from our side
Sector
E-commerce
dope places — storefront
dope places — checkout
dope places — order admin

The situation

A multi-language storefront with PayPal and social login, plus a full admin portal for the people who actually run orders, stock, and refunds.

Both languages had to be live on day one, and both sides — shopper and operator — had to be localized.

The problem

Localization added late means two codebases wearing a trenchcoat. Strings drift, currencies and dates get formatted in whichever locale the developer had open, and the admin is quietly English-only forever.

Payments and social login are also where a launch slips. Each one is a third-party integration with its own review process and its own failure modes.

What we built

  1. 01

    i18n as an assumption, not a feature

    One codebase, no hard-coded strings, locale-aware currency and dates. Adding a third language is a content task rather than a project.

  2. 02

    PayPal and social login live at launch

    Integrated and reviewed before launch week rather than during it, with failure paths that tell a shopper something useful.

  3. 03

    An admin built for operators

    Orders, stock, and refunds in a portal designed for someone doing this all day — localized on the same system as the storefront.

  4. 04

    Django REST behind a React front end

    A clean API boundary, so the storefront and the admin evolve independently without one's release blocking the other's.

Django RESTReacti18nPayPalSocial loginPostgreSQL

The outcome

Storefront and admin localized from one codebase, with PayPal and social login live at launch.

Adding a language is a content job on both sides of the product, and no part of the operational tooling is stranded in one locale.