The wrong question is "how do we preserve the current app?"

That question traps the system inside its first implementation.

RankWar was built fast in the right spirit:

• Next.js
• Supabase
• a sharp landing experience
• leaderboard logic
• referrals
• subdomain war rooms

That was good enough to prove the thesis.

It is not the right long-term operating model for a portfolio that wants shared identity, shared access, and many apps on one control plane.

What RankWar actually is

RankWar is not a waitlist app.

It is a distribution and status engine with a strong narrative wrapper:

• scarcity
• ranking
• referrals
• decay
• competition

That engine should live inside the same monolith that owns:

• the shared user account
• the shared email identity
• the shared domain registry
• the shared activation model

If it stays isolated beside the monolith, every future portfolio move gets weaker.

The migration should not preserve MVP naming

The current Supabase model uses generic names:

• waitlists
• entries
• referrals

That naming is fine for a fast launch.

It is weak as a permanent contract inside a monolith that will hold multiple products.

The dominant move is:

• keep shared tables truly shared
• keep RankWar tables explicitly RankWar

That means introducing shared primitives like:

• apps
• app_domains
• user_app_access
• contacts

and then letting RankWar keep its own bounded-context tables:

• rankwar_campaigns
• rankwar_entries
• rankwar_referrals
• later rankwar_events

That is how you preserve clarity without pretending every app is the same thing.

The shared user spine matters more than the current auth stack

The current RankWar app uses Supabase magic links.

That was the right shortcut then.

It is not the right anchor now.

The monolith already has the better long-term direction:

• email-password auth
• Socialite-based social login
• shared canonical users
• a hub domain that can become the activation spine

Google should be the dominant social login because it returns the most useful identity primitive for this portfolio: a real email address with less friction.

The point is not to force every visitor into a full account before they can join a war room.

The point is to make eventual account convergence clean:

• anonymous or low-friction lead capture first
• canonical contact record underneath
• upgrade into shared user access when the product moment demands it

UI does not need another frontend stack

RankWar does not need a separate frontend deployment to keep its edge.

The monolith can cover the whole surface with the tools already aligned to the stack:

• Blade for public pages and domain-aware shells
• Livewire for interaction that benefits from server truth
• Volt for compact interactive surfaces
• later Folio if the package window becomes worth it

That keeps deploys unified and removes the split-brain between product velocity and infrastructure complexity.

What most people will do

They will try one of two weak moves:

Weak move one: keep RankWar separate forever

This feels safe because nothing has to be renamed.

It fails because:

• identity fragments
• domain control fragments
• activation fragments
• analytics and publishing fragment

Eventually the portfolio becomes a museum of disconnected launches.

Weak move two: over-generalize everything into shared tables

This feels elegant.

It usually creates mush.

Now every future app has to inherit vocabulary that was really invented for one product's MVP.

That is how monoliths rot.

The right long-term move

RankWar should become a first-class bounded context inside the monolith.

Not a sidecar.

Not a generic schema template.

Not a forever-standalone app defended by inertia.

That gives the portfolio exactly what it needs:

• one user spine
• one domain-aware runtime
• one deploy system
• one publishing surface
• many products with real internal boundaries

That is the difference between a pile of side projects and an operating system.