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>
51 lines
3.4 KiB
Markdown
51 lines
3.4 KiB
Markdown
# Product Direction — decision addendum (2026-07-05)
|
||
|
||
Supersedes the open question in [REMASTER_PROPOSAL.md](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](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
|
||
1. **Wave 1 — Performance + AI provider router** *(in progress; provider-agnostic, unaffected by SaaS)*
|
||
2. **Wave 2 — Safe refactors** (extract services/DTOs from god controllers)
|
||
3. **Wave 3 — Data-model evolution** (versioned CV/cover letter, split import content, drop drift-prone flags)
|
||
4. **Wave 4 — Email provider abstraction** (Gmail + Microsoft Graph + IMAP + free-text) & AI hardening
|
||
5. **Wave 5 — SaaS platform** (onboarding, billing, quotas, per-tenant AI budget, rate limiting, outbox)
|
||
6. **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.
|