A marketplace with games inside it, and the pipeline that ships it

A marketplace with playable games inside it is not one product. It is a mobile client, game runtimes, an API, an authentication service and an admin surface, each with its own release cadence and its own reasons to break.

Running that on self-managed infrastructure rather than a managed platform is a deliberate trade: it costs far less and gives complete control, and in exchange the delivery pipeline has to be as dependable as the product. Nobody is going to page a cloud vendor at 3am on your behalf.

The coordination problem is sharper than in a normal web product, too. Mobile releases move at the speed of app store review while server changes can ship in minutes, so the two cannot be allowed to depend on each other. A backend fix that requires a new build in review is a backend fix that is not shipping this week.

We also joined an existing product rather than starting one, which changes the nature of the work. Nothing can be paused while it is improved, every change has to be safe for people already mid-session, and the areas most worth attention are the ones the product has already proven people use.

The mobile client is React Native with Unity embedded, so game content lives inside the marketplace app rather than alongside it as a separate download.

The backend is an Express API with background work on BullMQ and Redis, media handled through S3 with presigned URLs so large uploads never pass through the API, and Firebase for messaging. Authentication is split into its own service rather than living inside the API, which keeps the surface that holds credentials small and separately deployable.

The admin panel is a separate static build served by nginx. Giving an internal tool no server runtime of its own removes an entire class of failure and makes it the cheapest thing in the cluster to operate.

Everything runs on self-managed Kubernetes, delivered by GitOps: the cluster state lives in its own repository as an umbrella Helm chart with a subchart per service, and Rancher Fleet reconciles the cluster to whatever that repository says.

Delivery is fully automated from a push. CI builds each service image, tags it with the branch and commit, pushes it to the registry, and then patches the image tag in the GitOps repository — at which point Fleet rolls it out. Production and staging are two branches with two Fleet files, so promoting a change is a merge, and TLS is issued and renewed automatically by cert-manager behind a Traefik ingress.

Alongside the platform work, the engagement has been a continuous run of interface and usability improvements, shaped by how the product is actually used rather than by a redesign brief. That is the advantage of joining a live product: the evidence for what to change already exists, and it does not have to be guessed at from a wireframe.

Deploys are commits and rollbacks are reverts, which is the property that makes shipping on a Friday a non-event rather than a debate.

Every environment is described in code, so staging and production cannot quietly drift apart — the difference between them is a file you can read.

Services release independently. A change to the API does not wait on an app store review, and the admin panel can ship ten times a day without touching either.

Certificates renew without anyone remembering they exist, which is the correct amount of attention for certificates.

The client reports that revenue has grown over the course of the engagement. Revenue moves for many reasons and we would not claim it alone — but the interface work was aimed squarely at it, and the delivery pipeline is what made shipping those changes cheap enough to keep making them.