The goal
Smarter recommendations, fewer barriers to shipping
Two things we want to be true for marketing at Wanderu. Everything that follows is in service of these.
Recommendations with the full picture
Our scouts give sharper recommendations when they can see everything — every channel, our past experiments, and the knowledge behind them. The more of our marketing context that lives in one place, the better the ideas they surface.
Anyone can go from idea to shipped
Lower the barrier between having an idea and shipping it. Any teammate should be able to make an improvement in any area — without wrangling scattered tools, repos, and handoffs.
The approach
Two goals, one direction
Both goals pull the same way — bring our work together. The only questions are what we're sure of, and how far to go.
The brains should live in the marketing repo. The knowledge base, the scouts, and the docs they draw from belong together — recommendations get better the more marketing context sits in one place.
How far do we consolidate the code? Bringing the brains together is the easy call. Pulling in the code is the open question — three routes, each with different trade-offs.
Three routes
1 · Orchestrator Current
Repos stay where they are. The marketing repo knows where each one lives and how to operate on it.
2 · Vertical clusters Next step
One repo per system, integrated top to bottom — e.g. Nexus owns data, backend and frontend; email owns its Kafka + Snowflake events, external fetches, and HTML.
3 · Monorepo Evaluate
All code in one place. One checkout, one place to look.
Trade-offs
How the routes compare
Split into what serves the goal — guiding Claude — and what each shape costs us. The deciding question: how often does a change stay within one system versus cross several?
| OrchestratorCurrent | Vertical clustersNext step | MonorepoEvaluate | |
|---|---|---|---|
| Primary · can a user guide Claude to ship a change? | |||
| Changes within a systemDB → API → front-end of one system | WeakOne system's stack is split across repos. | StrongThe whole system is one repo — the sweet spot. | StrongThe system's whole stack is present (amid the rest). |
| Changes across systemsone change touching several systems | WeakCoordinated multi-repo PRs. | WeakMulti-repo coordination — a potential challenge for an agent. | StrongOne PR can span every system. |
| Discoverabilitywhere does it live? | WeakScattered repos plus a map to learn. | MixedClear within a system, scattered across them. | StrongOne place to grep; newcomers find anything. |
| Local verificationrun & test the slice | WeakA slice spans repos — hard to run together. | StrongThe whole system runs as one. | MixedAnything can run, but spinning up a slice is heavy. |
| Secondary · cost to adopt & operate | |||
| Migration cost | StrongLeast disruptive; mostly documenting. | MixedReal work, but done one vertical at a time. | WeakLarge up-front lift to pull everything in. |
| Deployment complexity | StrongEach repo keeps its own pipeline. | MixedMiddle ground — a multi-layer stack per system, but isolated. | WeakCoupled by default; path-filtered CI helps but adds setup. |
| Blast radius of auto changesif the dispatcher slips | StrongTightly scoped to one small repo. | MixedContained to a single system. | WeakA bad auto-change can reach anything. |
The read: on the primary metrics — guiding Claude — the monorepo leads, and only the cross-system row truly separates it from clusters. On secondary cost, clusters sit in the middle and stay reversible. So vertical clusters are the next step; whether the monorepo is worth its migration is what we evaluate once we know how often real changes cross a system boundary.
Proposed path
Start small, let the evidence decide
We don't have to pick the end-state today. Take a low-regret first step and learn from it.
- Get the brains into the marketing repo — the knowledge base, the scouts, and the shared docs; the part we're confident about.
- Vertically integrate Landing Page technology (Next.js + API + DBT). Our first vertical-cluster experiment: bring the front-end, the API, and the data / DBT layer into one slice.
- Let the findings guide consolidation. Use what we learn from that first vertical to recommend how far to consolidate everything else.
Bringing the brains into the marketing repo banks the value we're confident about right away. The landing-page integration then turns the open question into something we can measure instead of debate — and keeps every later move reversible.
How it works
Workflow Overview
Roadmap
Phase 1
The first wave of what moves into the marketing repo.
Knowledge base
Content & reporting
- Content calendar as HTML (migrated from Monday)
- Reporting / dashboards
- Presentations — including demos
- Specs & implementation plans
Brand guidelines
- Design
- Animations
- Text
- HTML presentation formatting
Customer research
- Archetypes
- Jobs to be done (JTBD)
Carrier onboarding
- Carrier onboarding checklist
Channels
- Skill: Generate HTML template from a brief
- Skill: Review email journeys and propose improvements
- Scout: Reviews existing transaction email performance and recommends changes
SEO
- Scout: SEO/AI improvements by page
- Skill: Noindex / index a landing page
- Skill: Generate llms.txt
Paid acquisition
- Skill: Download current config from Google Ads & Bing
- Scout: Recommend improvements to Google Ads and Bing
- Skill: Update Google Ads and Bing configurations
Social
- Skill: Generate Instagram post from a GitHub issue
- Skill: Generate TikTok post from a GitHub issue
Google Travel
- Scout: Google Travel opportunities
Roadmap
Phase 2 — the bigger moves Planned
Once the brains are in the marketing repo: migrate the core data, integrate landing pages as our first vertical, and start automating the path from idea to shipped.
Build the data platform
- DBT + connectors to pull & manage all core ACQ datasets (migrated from SDTP)
- Define data models and metrics
- Power reports/MCPs & alerting
Automate the idea → shipped path
- Autonomous scout runs
- Auto-approval of safe ideas
- Automatic dispatcher runs
- A human still hits merge before it ships
Vertically integrate landing pages
- Nexus
- Maverick
- Blog
- LLM-forward prototype
- SDTP/Mammoth-owned pipelines
The data platform owns analytics — the shared ACQ datasets, metrics, and alerting. Each vertical owns the data that backs its product — what powers the pages themselves, not the reporting. Different jobs, kept separate.
Roadmap
Phase 3 & beyond Later
One measured signal decides the fork: how often real changes cross a system boundary. Mostly within a system → keep going vertical. Routinely across → commit to one repo.
Finish vertical integration
If changes mostly stay within a system. Bring the remaining systems in as their own vertical clusters.
- Paid — the Google Ads / Bing parts of SDTP
- Email — Messaging and the Blueshift part of SDTP
- Google Partner
Commit to a complete monorepo
If changes routinely cross systems. Pull all system code into the marketing repo — one repo for everything.
- Strongest for complex, cross-system work
- One checkout, one place to look
- Accept the deployment & migration cost
Scope
What stays out — and what we're still exploring
Dispatcher stays in its own repo.
Research
- Do we need search for knowledge base?
- Any improvements to deployment technology to make this work?