Choosing an operable platform for a multi-tenant future

Context

Platform V2 is an ongoing modernization from a single-tenant PHP platform toward a multi-tenant Node.js and TanStack system. Each tenant needs its own domain and progressive web application experience, while the team also needs preview environments, a controlled release path, and a safe way to migrate existing customers in batches.

My role spans platform architecture, delivery workflow, supporting cloud services, observability, and application contributions when the migration work crosses into code.

Constraints

The new platform has to improve maintainability without creating an operating model the team cannot sustain. It also has to coexist with the existing system during migration. That makes reversibility, tenant isolation, domain handling, data movement, and batch control more important than choosing the most fashionable infrastructure.

The broader migration program is still in progress, so this case study focuses on the architecture decisions, delivery model, and controlled migration path established so far.

1. 01Application

   Node.js · TanStack · tenant routing

2. 02Delivery

   Vercel previews · release workflow

3. 03Data

   Neon Postgres · Upstash Redis

4. 04Operations

   SigNoz · OpenReplay · Vercel Logs

Decisions

Evaluate orchestration by operating cost, not reputation

The first architecture used ECS and ECR. The team later explored EKS, but the additional Kubernetes operating surface was too costly for the size and needs of the team. The application platform then moved to Vercel, where pull requests can create isolated preview environments without the team maintaining its own environment orchestration.

That sequence is not a story about avoiding Kubernetes. I have hands-on EKS experience. It is a story about changing course when the operational evidence says a simpler platform better serves the product and the team.

Keep supporting services where they fit

Vercel is the primary application platform, while AWS remains available for supporting services and networking needs that belong there. Neon provides managed Postgres. Upstash Redis supports domain validation. SigNoz, OpenReplay, and Vercel Logs provide complementary views of platform and application behavior.

Treat migration as a product

The move from the older platform is handled through an AI-assisted migration service that processes customers in controlled batches. Batching limits blast radius, makes verification meaningful, and allows the team to stop or correct the process without turning every migration into a big-bang event.

Implementation

The platform work combines several delivery concerns:

• Tag-based release management controls what reaches each environment.
• Pull-request previews give developers a testable environment before merge.
• Tenant routing and domain validation are explicit platform responsibilities.
• Data migration moves from the older MySQL model toward Postgres on Neon.
• Observability combines backend signals, session-level context, and platform logs.
• AI assists implementation and repetitive migration work, while access, review, validation, rollback, and production approval remain controlled by people.

Results

The architecture and migration program remain in progress. The outcome at this stage is a more operable platform direction: preview environments are native to the application platform, data and caching services are managed, and customer migration is designed as a controlled batch process instead of a single cutover.

Lessons

Architecture decisions are hypotheses. ECS, EKS, and Vercel each solved a real part of the problem, but only one matched the application, delivery workflow, and operating capacity well enough for this stage of the product.

The mature decision is not to defend the most complex option. It is to preserve portability, measure the operational burden, and move toward the simplest platform that meets the reliability and product requirements.