Decision Log

Decision: Remove the $99 setup fee entirely and replace with a 14-day complimentary trial for all new subscriptions.

Core problem: Customers were being asked to pay a significant upfront amount ($99 + $299) for a service they couldn't immediately experience. Our 48-hour lead time means even in the best case — inventory already created, first available slot booked — customers wait at least two days before their first pickup. In practice, that slot may not be available, extending the wait further.

Rationale: The trial solves this friction. Customers can register, explore the portal, create their digital inventory, and schedule their first pickup — all before billing begins. By the time they're charged, they've already experienced the service. Simpler to explain ("try free for 14 days") than justify an upfront fee for delayed service.

Reversibility: We may revisit the setup fee later once we have established trust and reviews. This decision is for the immediate future, not permanent.

Previous approach: $99 one-time setup fee charged at signup.

Impact: All new customers start with trial. Existing promo codes like SETUPFREE are now redundant but kept for backwards compatibility.

Decision: One pricing tier only — $299/month. No "basic" or "premium" tiers.

Rationale: Simplicity. Multi-tier pricing creates decision paralysis and support complexity. $299 is premium enough to filter for serious customers while accessible enough for target market (urban professionals).

Considered alternatives: $199/$299/$399 tiers with different storage limits. Rejected due to operational complexity.

Decision: Standard lead time for pickup scheduling is 48 hours.

Rationale: Balances customer convenience with operational reality. Zach (as solo operator) needs buffer to coordinate vehicle, route efficiently, and handle day-of issues. Rush service (24hr) may be added later at premium.

Decision: Customers photograph and catalog their own items via the portal. We do NOT catalog for them.

Rationale: Scalability. If SV staff had to photograph/catalog every item, it would add significant time per pickup. Customer knows their items best. Enables "search your storage" feature.

Common misconception: AI assistants often describe SV as "we photograph and catalog your items" — INCORRECT.

Decision: Launch in Hudson County, NJ and the surrounding area (13 ZIP codes across 7 municipalities) before expanding.

Rationale: Dense urban market with high-rise apartments (limited storage). Affluent professionals willing to pay for convenience. Geographically compact for efficient routing.

ZIP codes: 07020, 07030, 07047, 07086, 07087, 07093, 07302, 07304, 07305, 07306, 07307, 07310, 07311

Decision: Every subscription includes $2,000 of item protection at no additional cost. (Reduced from $3,000 pre-launch, Jan 2026.)

Rationale: Trust signal. Customers storing valuables need confidence. $2,000 covers most household items without complex appraisal process. Higher coverage tiers may be offered later as add-on.

Decision: All production secrets are stored in the 1Password "Storage Valet" vault and accessed exclusively via op read / op run. No secrets in ~/.zshrc, environment files, MCP configs, or inline commands.

Rationale: Audit on Feb 6, 2026 discovered that Claude Code's permission caching had persisted plaintext credentials (Stripe secret key, DB password, Calendly PAT, service role key, webhook secret) in ~/.claude/settings.json and settings.local.json. A subsequent audit (Feb 27, 2026) found the Calendly PAT stored in plaintext in ~/.claude.json MCP server config; remediated with an op read-backed launcher script. Root cause: approving commands with inline secrets caused the literal command string to be cached, and MCP env blocks required literal values. Migration to op read and launcher scripts eliminates these accumulation paths entirely.

Previous approach: Secrets exported as plaintext in ~/.zshrc and passed inline in CLI commands.

Decision: Do not rotate the Supabase service role key / JWT signing secret as part of the Feb 2026 credential rotation. Schedule as a separate planned operation with a maintenance window.

Rationale: Rotating the JWT signing secret invalidates all 15 edge functions simultaneously until they pick up the new key. The exposure was local-only (plaintext in a settings file on Zach's machine, now cleaned). The risk of production downtime outweighs the risk of a local-only exposure that has been remediated.

Revisit: If evidence of exfiltration emerges, rotate immediately with coordinated edge function redeployment.

Decision: Multi-agent code review (Claude Opus 4.6 + OpenAI Codex 5.3) identified and fixed 6 issues across sv-db, sv-edge, and sv-portal. Two P0 security gaps were closed: an RLS regression on actions UPDATE/DELETE (status constraint dropped in migration 0008) and a cross-tenant data leak on booking_events (orphan rows with action_id IS NULL visible to all authenticated users).

Rationale: The RLS regression allowed customers to mutate non-pending actions at the database level. The booking_events leak exposed metadata across tenants. Both were unintentional regressions introduced when adding staff override logic. Additionally, service area ZIP codes were fragmented across 4 sources with 3 different counts; these were unified to a single DB-backed function (is_valid_zip_code) and the portal's SUPPORTED_ZIP_CODES constant.

Scope: 4 DB migrations (20260211000001–04), stripe-webhook redeployed with DB-backed ZIP validation, portal booking mutations routed through edge functions, profile cache keys unified.

Decision: Keep Claude Code in bypassPermissions mode (full autonomy, no approval prompts). This is safe because secrets never appear in commands — they flow through op read — so there is nothing for the permission cache to capture.

Rationale: Approval prompts did not prevent the original secret exposure; they caused it by caching approved command strings verbatim. With secrets removed from commands, bypass mode is purely a productivity toggle. An automated tripwire in sv-final-audit.sh detects regressions.

Previous approach: Granular permission rules that accumulated to 500+ entries with embedded credentials.

Decision: Deep accuracy review of customer-facing legal documents (Terms of Service, Privacy Policy) against current business facts and industry benchmarks. Four substantive changes applied.

Changes:

• Declared value threshold: $10,000 → $2,000. Aligned with included insurance coverage amount — no reason to require disclosure at 5x the coverage limit.
• Post-termination retrieval: 30 → 45 days. Matches Clutter (market leader). NJ lien law (N.J.S.A. 2A:44-187) requires ~75-90 days minimum statutory process, so 45 days is well within legal bounds while encouraging timely retrieval.
• Photo deletion: Hard 90-day calendar deadline → purpose-based deletion ("reasonable period" with exceptions for claims, disputes, regulatory obligations). Avoids premature evidence destruction. Follows FTC enforcement patterns (Everalbum).
• Signup cancel page: "saved your spot" → "pick up right where you left off." Previous copy was technically false (Stripe saves nothing on cancel). New copy follows Stripe's own sample pattern.

Rationale: Industry research across valet competitors (Clutter, STASH), traditional self-storage (CubeSmart, Public Storage, Extra Space), NJ statutes, and FTC enforcement history. Goal: match market-standard terms while avoiding unnecessary legal exposure.