Two Stacks, One Recommendation: Patterns Over Frameworks.

You're producing a defensible recommendation — and a transfer guide for one data analyst — for an eight-person marine conservation NGO in Tonga whose research platform now has to exchange data with a New Zealand university running a completely different web stack.

The discipline skills: separating the underlying pattern from the tool-specific surface across frontend, backend, database, and CI; building a small comparison sandbox in the second stack as analytic apparatus; designing a data-exchange contract that protects sensitive location data across the boundary; defending the smaller architectural answer against AI's preference for the larger one; writing two analytic artifacts for non-technical-but-precise readers.

The AI-direction lesson: when the work is comparative judgment, AI's defaults are dangerous in particular ways. It picks the trendier framework, recommends the bigger rebuild over the smaller bridge, and contaminates one stack's idioms into the other when you switch sessions. You hold both contexts in parallel, refuse the training-data bias, and write the recommendation yourself because the reasoning is the value.

Your Role

You're the comparative analyst and integration architect. You read both stacks, build only enough of the second one to make the transfer claims real, and produce two written deliverables: a recommendation the executive director takes to her board, and a transfer guide that lets a single data analyst work across both environments for the partnership's multi-year duration.

No scaffold remains. The platform supplies the email, a sparse domain context, two sparse stack references, a framing reference, and a set of templates. The evaluation framework, the comparison rubric, the integration architecture, the data-exchange contract, and both deliverables are your design.

AI does the legwork on every layer that is not the analytic judgment. You hold the analytic work, partition the contexts so the two stacks do not contaminate each other, and refuse AI's defaults where they would compromise the recommendation.

What's New

Last time you carried a full-lifecycle engagement for a Cuban film company — discovery through handover, every column at its top expression in one running system. This project takes the same altitude and turns it inward.

The deliverable is judgment, not a running system. You do not rebuild the existing platform. You do not deploy an integration. You build a small sandbox in the second stack as evidence, then write two documents — that is the engagement.

Two parallel contexts are the central directing test. You maintain a strict partition: one session for the existing-stack reference, one for the second-stack sandbox, and a synthesis session where comparisons happen with both contexts loaded as labelled inputs. The partition's failures are invisible until the wrong code ships.

The smaller answer is usually right. AI's first answer to "should we migrate or integrate" is almost always "migrate, here's the architecture." For a small NGO with one data analyst, the right answer is almost always smaller — a narrow data-exchange contract, with the access-control filter doing the load-bearing work. You will defend the smaller answer in writing because AI will not.

Tools

• Claude Code with three explicitly partitioned project sessions: existing-stack reference (read-only), second-stack sandbox (where new code lives), and synthesis (where comparisons happen with both contexts loaded as labelled inputs).
• Two web stacks held in parallel. The existing stack you read but do not modify: React 18, Express 4, PostgreSQL 15 with PostGIS, Jest, GitHub Actions. The second stack you build a small sandbox in: Vue 3, Django 5, MySQL 8, pytest, GitLab CI.
• Docker Compose for the local MySQL container under the sandbox.
• Git and GitHub. A new vega-uni-integration repo holds the sandbox and every written artifact. The existing platform's repo is read-only.
• VS Code + Claude Code extension.

Materials

• The client's email (mele-email.md) — the first-contact artifact. The executive director names the partnership, both stacks, two questions, and one explicit constraint. Three hidden constraints and two blind spots surface only when you ask.
• A marine-conservation context reference (references/marine-conservation-context.md) — operating environment, humpback population, ministry reporting, team scale. Sparse enough that the discovery still does work.
• Two stack references (references/vega-existing-platform.md, references/university-stack.md) — what each platform is, how it is shaped, what data it holds. Patterns and structures, not code.
• Four more references under references/ — the patterns-vs-tools framing with worked examples, the three integration families with trade-off characteristics, the comparison-sandbox spec, the parallel-context discipline.
• Eight templates under templates/ — engagement framing, trade-off log, parallel-context log, patterns-vs-tools analysis, integration architecture, data-exchange contract, recommendation document, transfer guide. Headers and prompts; the content is yours.
• A minimal sandbox scaffold (sandbox-scaffold/) — Docker Compose for MySQL, bare Vue 3 and Django 5 projects, a seed script. Enough to run; not enough to satisfy the unit's spec. You direct AI to add the models, routes, components, and tests.
• The engagement governance file (CLAUDE.md) — constraints, served audiences, critical claims, verification targets, the parallel-context discipline rule, commit conventions.

No recommended stack. No prescribed integration approach. No outline of the recommendation. The brief is the email and the question the client asks.