FocusGoods began as a commerce project, but it quickly became a systems project. A storefront is easy to describe and hard to operate well: products need images, products need rights screening, orders need fulfilment, Stripe webhooks need reliability, and production traffic needs a rollback path.
Where it is now
The V2 stack is dark-deployed on the VPS and receiving live-shaped Stripe webhook shadow traffic. Production storefront traffic remains safely on V1 while the V2 system proves itself through webhook ingestion, queueing, ledgers, asset serving, and canary infrastructure.
The documented state includes PostgreSQL RLS, BullMQ, Redis, a webhook ingest service, scheduler, asset server, canary probe, traffic split schema, rights screening, quality gate, Printify MCP provider tools, and a deployment runbook that treats rollback as a first-class feature.
The barriers
The main barrier was risk. A store that takes payment cannot be treated like a toy pipeline. Stripe events must be idempotent. Asset URLs must be scoped. Printify calls need isolation. Rights and quality checks need to fail safely. Traffic must be introduced gradually.
Another barrier was the temptation to wire everything directly. Direct API calls feel fast until you need auditability, isolation, and a way to replace one provider without rewriting the rest of the system.
How I did it
I split admission from processing. Webhooks get accepted quickly, queued, and then handled downstream. The scheduler records job state in a ledger. Printify is exposed through MCP tools rather than scattered direct API calls. Rights screening uses text matching, phonetic comparison, and visual similarity policy decisions. Quality control has structured verdicts rather than vibes.
The canary controller is the important mental model. It treats deployment as risk management: small exposure, observed result, hold or increase, and rollback if failure clusters appear. That same discipline appears throughout the T-drive stack now.