AR-Magic, rewritten alone

Moving a live product off MongoDB into a typed monorepo — four apps, four shared packages, and no window in which it could be down.

SPECIFICATION BRIEFEXTRACTED
ARCHITECTURE
Monorepo with data-layer entitlement enforcement · Shared validation schema across API and client
CONSTRAINT
Live production traffic with paying users · Zero maintenance window · Solitary engineering execution
TRADEOFF
Extended dual-read validation timeline over instantaneous cutover downtime risk
STACK & SCOPE
Turborepo · Fastify · Prisma · PostgreSQL · Redis · DockerRelational subscription entitlement and downgrade logic migrated off MongoDB via dual-read verification across 24 themes
DOWNTIME
0
APPS
4
PACKAGES
4
TESTS
45+

The problem

The platform sold subscription tiers, and tiers mean entitlements: which themes you can use, what you can publish, what happens when you downgrade. That is relational logic, and it was living in a document database that had no opinion about it.

The product was live and paying while I did this. There was no maintenance window to ask for, and nobody else to hold the other end.

The decisions

I moved it into a Turborepo monorepo on Fastify, Prisma, PostgreSQL and Redis — four apps over four shared packages, so the validation schema the API enforces is .

Entitlement locking went , so a plan change is enforced wherever the data is read from, not wherever someone remembered to check.

For the migration itself I ran the old and new stacks against the same data until the new one agreed with the old one on every read, and only then moved writes across. It cost more time than a straight cutover and it is the reason the number at the top of this page is zero.

The outcome

Production data moved off MongoDB with no downtime. The result is Dockerised, deployed through CI, and covered by more than forty-five tests — a 24-theme system that now enforces its own rules instead of trusting the client to.