chapter.guide / swarm / run 022

Deal Page Consolidation

2026-05-11  ·  PASS  · Bookmark this page: /swarm/022-deal-page-consolidation.html

Assignment

Audit every existing deal room/hub page for HR.com and Design Precast, research CRM UI/UX best practices, and design a single consolidated deal page architecture that houses everything an M&A operator needs per deal.

Subset: Full roster (all 11)

Roster

writerarchitecthunterquarterbacklistenerdrapermarket-analyststorytellertech-translatordebrief (audit-quality held to Phase 4)

What we found

420+ files across 7 different storage layers. The richest operational data (call intelligence, target company research, meeting decisions) is trapped in static HTML files that no one can search, filter, or update. Meanwhile, the database tables designed to hold this data are mostly empty.

The deal page that already exists (`/deals/hr-com`, `/deals/design-precast`) has about 70% of the skeleton we need: deal header with financials, activity feed, plays card, meeting timeline, feedback box. What's missing: target company pipeline, contact directory by role, internal vs. external meeting separation, documents vault, fee calculator with per-deal splits, and links to the legacy pages.

All 10 agents agreed: extend the existing deal page with 6 tabs (Overview, People, Meetings, Pipeline, Documents, Financials). Build one system with deal-type variants — buy-side shows a target acquisition funnel, sell-side shows a buyer activity tracker. Don't delete any of the existing static pages; link to them from the consolidated view.

The biggest technical decision: keep the client-facing portal (`/portal/[client]`) separate from the internal deal page. Different audiences, different trust levels, same database underneath.

The consensus had 5 factual errors (columns we said were missing that already exist, an EV discrepancy that was actually an intentional correction). More importantly: a route collision where a hardcoded HR.com meetings page would shadow the new dynamic meetings tab, a column naming conflict with the existing meeting atlas, and a parallel meeting data store (`meeting_notes`) that nobody mentioned during Phase 1.

The build is 4 sessions: (1) database schema + data ingest, (2) API routes + components, (3) page assembly + polish, (4) integration + edge cases. This is a data migration + UI extension, not a rewrite.