Day 010 - RankWar growth engine and legacy decommission
Day ten of the lmachine monolith: RankWar stopped pretending it was still mid-migration, the growth engine became an explicit operating system, and the old workspace repo was marked for removal instead of lingering as fake optionality.
What changed
- promoted RankWar from
migratingtooperatinginside the monolith registry contract - replaced the local-path legacy pointer with the actual archived repo reference
- installed a repo-owned GTM skill so growth work stops living as loose chat advice
- wrote the RankWar growth engine memo inside the monolith docs
- prepared the workspace to remove the old
apps/waitlist-appsubmodule without pretending the product still lives there
Why this matters
Framework migration is not the same as product migration.
If the public app, the shared database, the mail path, and the live domains already belong to the monolith, leaving the old repo in the workspace as if it were still a product is weak.
That creates fake optionality and real maintenance drag.
The stronger move
The stronger move is:
- keep the frozen legacy snapshot
- keep the archived GitHub repo as historical reference
- move all active product, growth, and distribution thinking into the monolith
That way the workspace reflects the truth instead of legacy nostalgia.
The growth rule
RankWar does not need “marketing ideas.”
It needs a compounding engine:
- creators launch campaigns
- participants compete and invite
- public proof is captured
- proof recruits the next creator
That is the real GTM loop.
Build rule
The deploy system stays on the same host for now.
That is a deliberate simplification, not an accident.
The bar is not extra infrastructure.
The bar is whether the current host keeps shipping safely while product and distribution compound faster than operational complexity.