cesnimda
286579ceeb
User decision (2026-07-05): evolve from single-user to public multi-tenant SaaS. Adds PRODUCT_DIRECTION.md: email linking generalises beyond Gmail (Microsoft Graph + IMAP + always-available free-text fallback), SaaS platform wave (onboarding, billing, quotas, per-tenant AI budget, rate limiting, outbox), and resolves the .gsd "use next.js" override in favour of executing it (public SEO). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.4 KiB
Product Direction — decision addendum (2026-07-05)
Supersedes the open question in REMASTER_PROPOSAL.md §1 and .gsd D003
("individual job seeker").
Decision
Job Tracker becomes a multi-tenant SaaS (public sign-up), evolved incrementally from the current
single-user-origin codebase. The existing OwnerUserId + global-query-filter tenancy is the right
foundation and already enforced; SaaS work builds on it rather than replacing it.
New requirement: multi-provider email linking
Email↔job linking must not be Gmail-only.
- Gmail — existing OAuth path (
GmailOAuthService,GmailController) — keep as provider #1. - Microsoft / Outlook — add via Microsoft Graph OAuth (large share of users).
- Generic IMAP — cover "any other provider" (Fastmail, Proton Bridge, corporate, etc.).
- Unsupported / no-connect → free-text fallback — the user can paste an email or log correspondence
manually against a job (this already exists as manual
Correspondence; make it a first-class, always- available path so a missing provider never blocks the workflow).
Design implication: introduce an IEmailProvider abstraction (connect, search, fetch-thread,
refresh-linked-thread) with GmailProvider, MicrosoftGraphProvider, ImapProvider, and a ManualEntry
non-provider. Correspondence already stores ExternalThreadId + from/to metadata — generalise it with a
Provider discriminator instead of Gmail-specific assumptions. Keep the no-auto-send boundary (D002).
What SaaS adds to the roadmap (new wave, after the refactor foundation)
These were flagged [SaaS] in the proposal and are now in scope:
- Onboarding & account lifecycle — sign-up, email verification, password reset (parts exist), per-user workspace bootstrap, delete/export (GDPR).
- Plans, billing & quotas — free vs paid; meter AI usage; Stripe (or similar).
- Per-tenant AI cost control — the provider router (Wave 1) plus per-tenant budgets and optional BYO-API-key (a real differentiator, see RESEARCH_COMPETITORS.md §4).
- Abuse resistance & rate limiting — public sign-up widens the SSRF/import/AI attack surface; add per-tenant rate limits and re-check tenant isolation on every endpoint.
- Background processing at scale — move the polling hosted services toward an outbox + worker so reminders/enrichment scale beyond a single busy node.
Frontend consequence — the "use next.js" override is now justified
A public SaaS needs SEO/SSR marketing pages + fast first paint. This resolves the .gsd OVERRIDES
"use next.js" conflict in favour of executing it: migrate the frontend to Next.js (was previously a
toss-up with Vite for a private tool). Still its own milestone, not coupled to backend work.
Re-sequenced roadmap
- Wave 1 — Performance + AI provider router (in progress; provider-agnostic, unaffected by SaaS)
- Wave 2 — Safe refactors (extract services/DTOs from god controllers)
- Wave 3 — Data-model evolution (versioned CV/cover letter, split import content, drop drift-prone flags)
- Wave 4 — Email provider abstraction (Gmail + Microsoft Graph + IMAP + free-text) & AI hardening
- Wave 5 — SaaS platform (onboarding, billing, quotas, per-tenant AI budget, rate limiting, outbox)
- Wave 6 — Next.js frontend migration (public SEO/SSR)
Wave 1–3 harden the core for any identity; Waves 4–6 deliver the public-SaaS pivot.