Rebuilding the infrastructure under a live luxury resale marketplace

The situation

We joined an existing pre-owned luxury fashion marketplace, live in the UAE with a Laravel API and Flutter apps on both stores, built originally by an outside vendor. The product worked. The problem was underneath it: infrastructure that had not been designed to be reproduced, redeployed, or handed to a new team without someone's private notes. When the person who remembers how the server was configured leaves, the business inherits a black box with a login screen on top.

Our job was not to rewrite the product. It was to keep it shipping, in public, on two app stores, while rebuilding the ground it stood on.

What we built

We put the Laravel API into a Docker image on Nginx and php-fpm, added structured JSON logging and request-ID propagation so a support ticket could actually be traced through the system, and gave it a proper health check endpoint. We moved the whole stack onto AWS ECS using Terraform and Terragrunt: VPC, ECR, the ECS cluster and services, RDS, load balancing, S3, SES, Secrets Manager, and a scheduled job that keeps the security group in sync with Cloudflare's IP ranges so the origin stays behind the CDN. GitHub Actions now handles the deploy, including the database migration task and the queue worker, so a release is a pipeline run, not a checklist someone follows from memory.

On the product side, we fixed checkout crashes and refactored the cart service, because a marketplace that drops a sale at the last screen loses more trust than it loses revenue. On mobile, we shipped an Apple sign-in fix, deep linking through Branch.io, and a native share flow, across a handful of releases on both platforms.

How it went

The app kept shipping throughout the migration, on iOS and Android, which was the entire brief: change everything underneath a live product without disrupting the product itself. We do not have a user or GMV number we are cleared to publish for this engagement, so we are not going to invent one to make the story rounder than it is. The honest measure here is operational: the platform moved from bespoke server configuration to infrastructure as code, and a release became something a pipeline runs rather than something a person remembers.

What we would do differently

We would have pushed harder, earlier, to document the pre-existing system's undocumented assumptions before touching anything, rather than discovering them one deploy at a time. We also would have separated the infrastructure migration from the ongoing feature work into two visibly different workstreams from day one, so the client could see which risk belonged to which change.