PropFlow dashboard — scope & redesign plan

How the dashboard is built (so the plan makes sense)

The dashboard isn't a static column — it's a 12-column drag/resize canvas (ADR-0097/0103). Every card is a "widget" defined in a catalog, ordered by a layout manifest, and composed in one big file. Ten widgets ship by default; each user's layout persists.

• Composition: DashboardHome.tsx (lines 1085–1295) — the widget map.
• Order + default grid rects: catalog/surfaces.ts.
• Data: DashboardDataProvider polls /api/dashboard/stats + /api/leasing/stats every 30s. Numbers come from computeDashboardStats and friends.
• Charts are one shared hand-rolled SVG engine (ObservabilityChart.tsx) — Recharts is banned by an in-code comment. Collapsed cards get a sparkline; expanding a card opens the big trend chart.

The upshot: most of what you asked for is a component swap or a default change, not new data plumbing — the data is almost always already computed.

Meeting context — 2026-08-19 standup (what the team expects)

Cross-checked the plan against the standup recap. It confirms the direction — dashboard rebuilt as a quick summary of each section, each clickable into its detail (leasing snapshot, maintenance, collections summary → 30/60/90) — and adds three things my first pass missed:

• A whole leasing-funnel rework the team wants — see new §7 below. This is the biggest gap.
• "Go all the way back" is a real bug, not just a default — the team watched a 12M view render only ~7 months, and "all time" wouldn't pull. Sharpened in §1.
• NOI trailing-12 lost its month label — a specific regression to fix (Sean: "before we had what month it was picking up, and for some reason that dropped").

Portfolio Metrics removal was decided live ("looks like the old March UI… removing that"). Collections-as-a-summary-KPI and the weekly "reports" email as the tile reference were both named explicitly.

Two things stacked on top of each other. First, a default-window choice — expanded charts open short (NOI 6 months, Occupancy/Rents 30 days). But the meeting surfaced a second, deeper problem: even on a 12-month view, only ~7 months actually rendered, and "all time" wouldn't pull the full history. Fede noted AppFolio holds ~8 years. So a default bump alone won't fix it.

• NOI / financials can truly go all the way back. They ride monthly FinancialPeriod rows built from AppFolio's twelve_month_income_statement (true per-month columns) — uncapped, ~98 stored months for Camellia. The known YTD bug on the other endpoint (income_statement) does not touch this path.
• Occupancy / Rents are bounded to ~13 months. They ride the daily metric-snapshot source, hard-capped at 400 days and only existing since the snapshot writer went live. So "12 months" is the honest ceiling there; multi-year would need a separate occupancy-history backfill.

• Verify first: query Camellia's stored FinancialPeriod months and run the chart's own query at all — settle whether the ~7-month ceiling is storage, query, or render. This decides whether the rest is a one-liner or a backfill.
• Bump the card defaults: NOI 6M → 12M (or all), Occupancy/Rents 1M → 12M. The window vocabulary already has 12M and all tokens, with persistence.
• Fix the NOI month label — the trailing-12 caption lost the "as of <month>" it used to show. Regression, in scope here.
• Ship the chart restyle (#2) alongside so the longer series actually looks good.
• medium Occupancy/Rents caveat: those ride the daily-snapshot source (~13-month ceiling). Multi-year there needs a monthly-occupancy backfill (mirrors how NOI works) — a separate decision.

• Weak, low-contrast styling — 2px lines, a 0.08-opacity gradient wash that barely registers, dashed #ebebeb gridlines, 10px muted-gray labels. Faint and unfinished on a marquee surface.
• The curve is geometrically distorted. The SVG uses preserveAspectRatio="none" and stretches a fixed 900-wide viewBox to fill the container — a code comment even admits it looked "pixelated/uneven." Classic hand-rolled-chart tell.
• Axis labels are fragile HTML overlays layered over the SVG with manual edge math and @container hacks to dodge collisions.
• Two palettes collide in one component — a --v-* "Vercel Observability" family for the plot, brand --color-*/purple for the brush. It doesn't read as one system.

• Move the whole chart onto brand tokens; delete the --v-* family.
• Confident line weight + a gradient fill you can actually see; cleaner baseline and gridlines.
• Fix the aspect-ratio distortion (responsive viewBox / real measured width instead of a stretched fixed one).
• Anchor axis labels properly (SVG-native or measured), tighten the crowded overlay header.
• Keep the no-Recharts constraint — this is a restyle, not a rewrite.

The bare tile is WeeklySnapshotCard.tsx — five flat counters (Move-ins, Move-outs, Signed, Applications, Tours), a plain number over an uppercase label, showing — when empty, so a quiet week reads as a dead tile. The email you love (owner-report-email.ts) uses a rounded pill per row: navy label, bold indigo value, a "no change vs last week" delta line, and an 11-row occupancy box score under an "Occupancy · as of Jul 20" header.

OccupancyCard already owns "where we stand now." So I'd make the weekly tile the complementary "what changed this week" panel — the flow deltas (move-ins/outs/transfers/signed/apps/tours) in the email's pill style — rather than duplicating the full box score. Alternative: fold weekly counters into OccupancyCard's expanded view and retire the strip. My rec is the former.

That's the big table at the bottom (MetricSummaryTable, widget id metricTable). Removal is mechanical but touches several registries, and a catalog-drift test pins the wiring — so it's all-or-nothing or CI fails.

• Counts, no worklist. Four scalar tiles + a category bar. A PM can't see or click through to a single work order.
• The one number that matters — open WOs — has zero decomposition. No open-by-status, by-priority, overdue, unassigned, or emergency. pendingApproval is already computed and never shown.
• The category breakdown is misleading. It counts all work orders regardless of status, sitting under an "open work orders" headline — two different populations stacked as if they agree.
• "Self-serve %" is the wrong metric here — it's a conversation resolution rate, not a WO metric.
• Three different time windows across four tiles (weekly / instant / all-time), and no urgency signal at all.

• Open WOs decomposed by status and priority.
• A "needs attention now" band: emergency, overdue, unassigned, pending approval — with counts that click through.
• Oldest-open aging, and a short worklist of top-priority open WOs linking to the WO detail page.
• Filter the category breakdown to open; drop or relabel self-serve; unify the time base.

Almost everything exists already — this is assembly, not construction.

• Component: collections/_components/CollectionsAgingCards.tsx — a "Total past due" hero + a 4-up aging row (1–30 / 31–60 / 61–90 / 91+) with dollars, share-of-total bars, and status composition. Exactly a dashboard-lane shape.
• Data: GET /api/collections returns the summary + per-band aging; and stats.totalPastDueBalance + stats.delinquencyRate are already on the dashboard payload (same rollupAging the /collections page uses, so numbers are guaranteed to match).

• Add a Collections widget reusing CollectionsAgingCards (or a compact variant), driven by the collections summary. It absorbs the Total Past Due + Delinquency orphaned by #4 and matches the /collections page styling.
• Scope v1 to the total + aging bands; leave room for the extra context you're going to share.

Meeting shape: delinquency rate + total outstanding as the summary KPIs, clickable into a 30/60/90 breakdown — exactly what the aging component already renders. The /collections page itself has separate bugs the team flagged ("ended" date, "paid"→"last paid", "certified funds only" as a status) — noted, but those are page-level, not this dashboard widget.

The team wants the leasing section turned into a true funnel, not a flat KPI row. This is the biggest thing my first pass missed.

• A real funnel shape: Inquiries → Tours → Applications → Signed leases, biggest number on the left shrinking rightward, with conversion % between each stage (Fede: "52 to 20 is 50%… you see how it converts"). Window is the trailing 60 days.
• Drop "vacant units" from the funnel row — it's not part of the prospect flow, and everyone agreed it doesn't belong there ("this doesn't make sense").
• Fix the Applications count — show TOTAL received with an awaiting-review subtext: "10, 1 awaiting review" (9 signed + 1 in review = 10), not just the one in review. When it approves, awaiting → 0 and signed → 10.
• Color the stages to the funnel (shades of brand purple — Sean's red/green/purple mix was rejected as too loud; Gera: "different shades of purple").

1. Verify the time-range data (#1) — resolve the "12M shows 7 months" bug before anything else; it decides scope for the chart work.
2. Chart restyle + NOI month label (#2, #1) — lifts every card at once and makes the longer series look right.
3. Collections section (#6) — reuse-heavy, and it's the prerequisite for the next step.
4. Remove Portfolio Metrics (#4) — only after Collections absorbs Past Due + Delinquency.
5. Weekly tile → email feel (#3) — self-contained, lift the existing pattern.
6. Leasing funnel (#7) — needs its own scoping pass first; medium lift.
7. Maintenance rebuild (#5) — biggest content lift; can run in parallel (but see the adoption caveat).

Almost everything is a component swap, a default change, or a reuse of existing code — the numbers are already computed. The two items that need a scoping pass before they're one-PR-ready are the time-range verification (#1) and the leasing funnel (#7). Waiting on your extra collections context before locking #6's shape.