SM Dev Handoff And Supabase Question¶
Summary¶
Ace is sizing up giving a developer SM-only data access. Mid-conversation he pivoted to asking whether SM should move to Supabase for scalability. Session ended after I wrote ~/stickymetrics/FORECASTING.md (forecasting architecture + 10 resolved nuances) for the eventual dev handoff. Decision on Supabase is paused pending Ace's answer to the framing question.
Verified (cite the source before reusing any of this)¶
~/stickymetrics/FORECASTING.mdcreated this session (Write tool confirmation, file path returned 2026-05-25)- StickyMetrics Postgres lives at
~/stickymetrics/, db namestickymetrics, schemasraw/agg/forecasts(source: memoryproject_stickymetrics_architecture.md, dated 2026-05-04) - launchd job
com.stickymetrics.dailyat 6am, logs at~/.stickymetrics/logs/(same source) - DB connection string
postgresql://hemaniserver@localhost:5432/stickymetrics(same source) - Multi-SKU schema bug (2026-05-01): 236 multi-SKU ASINs were affected by
raw.fba_restockPK missingmerchant_sku(source: memorylesson_user_correction_act_dont_verify.md) - MRP_BACKFILL ad spend was ~30% of true; 24-month backfill found $271K of previously-uncounted ad spend; SM blended margin dropped from 23.9% to 15.9% to match MRP/SB (source: memory
reference_sticky_profit_recon_architecture.md, migration 0031, 2026-05-04) - MCF contamination: 398 of 730 days affected; worst day 2024-08-14 had 1,755 phantom units flipping margin from -57% to +33% (same source, migration 0030)
- Ads API limits: 31-day max range per report request;
pull_ad_spend.py:poll_ads_reportcaps polling at 900s (source: memoryfeedback_sticky_ads_backfill_chunking.md) - Validation snapshot: mini median MAPE 63.5%, weighted 32.6%, in-band 92.7%, runtime 7.7s (source:
forecasts/eval_model_sizes.pyoutput 2026-04-30, per memory) - An
architecture/forecasting.mdalready exists in the vault at~/Documents/Vault/businesses/StickyMetrics/architecture/forecasting.md(verified by Read this session)
Assumptions - DO NOT cite as fact¶
- "Supabase migration is multi-week" is a gut estimate, no scoping done
- "Scoped Postgres role + Tailscale invite solves dev access in an hour" is an estimate
- Recommendation to not share the Obsidian vault with the developer is a preference / taste call, not measured against any concrete dev need
- "The forecast pipeline + orders_detail backfill currently in flight would need a freeze window or dual-write" if migrating is reasonable but not architected
- Existing vault doc and the new
~/stickymetrics/FORECASTING.mdmay overlap but were not diffed
Open verifications (next session must close these)¶
- [ ] Re-run
forecasts/eval_model_sizes.pybefore quoting the April 2026 holdout numbers; the snapshot is ~25 days old and may have shifted after May calibration - [ ] Confirm migrations 0021, 0026-0028, 0030, 0031 still match current schema before citing them to the dev (memory is ~21 days old, point-in-time observation)
- [ ] Get Ace's answer to the framing question: is the Supabase move motivated by the dev handoff, or because SM is becoming a multi-tenant product?
- [ ] Diff the new
~/stickymetrics/FORECASTING.mdagainst the existingarchitecture/forecasting.mdin the vault; consolidate to one canonical doc to avoid drift
Decisions¶
- Wrote
~/stickymetrics/FORECASTING.md(project location alongsideMRP_ACCESS.mdandSB_ACCESS.md) rather than the vault, because a developer would naturally find project docs in the repo - Punted the Supabase migration call back to Ace to settle the framing first (dev handoff vs multi-tenant product), since the right answer differs by an order of magnitude in scope
Remaining work¶
- Ace decides: dev handoff trigger, or multi-tenant product trigger? Everything downstream depends on this answer
- If staying local-first: scope a read-only Postgres role + Tailscale invite for the dev, plus separate SP-API/Ads dev creds (not Vault sharing)
- If migrating to Supabase: scope a phased plan. Data layer first; forecast worker (Chronos-Bolt-mini on MPS) stays on a Mac mini or Fly worker; freeze the May 2024 to Apr 2026 orders_detail backfill or set up dual-write
- Reconcile
~/stickymetrics/FORECASTING.mdwith the existing vaultarchitecture/forecasting.md
Source artifacts¶
~/stickymetrics/FORECASTING.md(created this session)~/.claude/projects/-Users-hemaniserver-revpar-pro/memory/project_stickymetrics_architecture.md~/.claude/projects/-Users-hemaniserver-revpar-pro/memory/reference_sticky_ad_spend_architecture.md~/.claude/projects/-Users-hemaniserver-revpar-pro/memory/reference_sticky_profit_recon_architecture.md~/.claude/projects/-Users-hemaniserver-revpar-pro/memory/lesson_user_correction_act_dont_verify.md~/.claude/projects/-Users-hemaniserver-revpar-pro/memory/feedback_sticky_ads_backfill_chunking.md~/Documents/Vault/businesses/StickyMetrics/architecture/forecasting.md(existing)~/Documents/Vault/businesses/StickyMetrics/architecture/data-warehouse.md(existing, not read this session)
Related¶
- [[overview]]
- [[architecture/forecasting]]
- [[architecture/data-warehouse]]
- [[product/roadmap]]