Roadmap

Current Status Reference

See Status for the current state, completed work, known gaps, beta checklist, and recommended next sprint. As of the Beta Polish + Launch Prep Sprint, QQueue is a self-hosted beta ready for early technical users undergoing launch preparation — see the Beta Readiness Assessment in STATUS.md.

Phase 0: Project Scaffold

• Monorepo setup
• API scaffold
• Web scaffold
• Worker scaffold
• Shared packages
• Docker Compose
• Prisma schema

Phase 1: Core Sending

• Auth
• Organizations
• SMTP connections
• Test SMTP connection
• Templates
• Contacts
• Send single email

Phase 2: Deployment and Self-Hosting

• Dockerfile for the API (build -> node dist/index.js)
• Dockerfile for the worker
• Dockerfile for the web (build static assets into the Caddy image)
• Caddyfile (committed): static web + reverse_proxy for /api/* and /health, auto-TLS via {$DOMAIN}
• docker-compose.prod.yml: caddy, api, worker, postgres, redis, wired via .env
• One-shot migrate step running prisma migrate deploy on deploy
• Commit Prisma migrations (currently gitignored - see .gitignore)
• Updated .env.example with DOMAIN + secret-generation instructions
• Restrict CORS to the configured web origin (currently open in app.ts)
• Fix the hardcoded localhost in the API startup log (apps/api/src/index.ts)
• docs/DEPLOY.md: the 3-step VPS walkthrough (fill .env -> DNS record -> docker compose up)

Phase 3: Campaigns

• Contact lists
• Campaign drafts
• Send now
• Schedule campaign
• Queue campaign recipients
• Worker sends campaign emails

Phase 4: Scheduling and Recurring

• Send later
• Recurring campaigns
• Cron expressions
• Pause/resume campaigns

Phase 5: Analytics

• Email events
• Open tracking
• Click tracking
• Bounce tracking (synchronous SMTP rejections + generic ESP webhook)
• Campaign dashboard

Phase 6: Transactional API

• API keys
• Send email endpoint
• Template variables
• SDK
• Webhooks

Phase 6 follow-up notes

These are polish/hardening items to pick up after the main Phase 6 surface:

• Transactional API docs: API key setup, SDK install/use, curl examples, self-hosted baseUrl, template variables, webhook signing, and retry semantics.
• Stabilize the public send response shape: prefer a compact { id, status } response over exposing nested internal { emailJob, providerResult } details.
• Add stable API error codes: machine-readable codes for invalid API key, missing SMTP connection, invalid template, SMTP failure, invalid schedule, and validation errors.
• Improve SMTP/secret UX: clearer error when encrypted SMTP credentials cannot be decrypted, plus docs explaining that changing ENCRYPTION_KEY invalidates stored SMTP secrets.
• Add webhook delivery detail UI: recent attempts per endpoint, response status, error message, delivered time, retry state, and a manual retry action.
• Add webhook verification docs/examples: sample HMAC verification code for Node/Express and notes about timestamp tolerance/replay protection.
• Add SDK release hygiene: changelog, package publishing checklist, install smoke test, and version bump flow for qqueue-sdk.

Licensing & Open-Core Model

QQueue is open core, all in this one repository:

• The core platform (everything in Phases 0–6) is licensed under AGPL-3.0 (LICENSE). Anyone can self-host, modify, and redistribute it; running a modified version as a network service triggers the AGPL's source-disclosure obligation.
• The managed-cloud features (Phase 7) will live in a fenced directory (e.g. apps/cloud/ or packages/ee/) under a separate commercial license, with its own LICENSE file. The license boundary — not a repo boundary — is what protects the cloud business.
• All contributions are covered by a Contributor License Agreement (CLA.md), so the project can use contributed code in both the AGPL core and the commercial offering. See CONTRIBUTING.md.

Before starting Phase 7

These should be in place before any cloud-only code lands:

• Create the fenced proprietary directory (apps/cloud/ or packages/ee/) with its own commercial LICENSE and a README note marking the boundary.
• Decide the initial commercial feature boundary (what stays in the AGPL core vs. what is cloud-only).
• Replace the placeholder commercial license with a commercial license draft.
• Have the commercial license draft reviewed by qualified legal counsel, including pricing-tier feature rights and restrictions.
• Keep all multi-tenant/billing/usage-metering code on the proprietary side; keep reusable primitives (auth, queue, sending) in the AGPL core.
• Add repeatable dependency license audit (pnpm license:audit) and CI enforcement.
• Have final dependency license output reviewed before release.
• Wire up CLA enforcement (CLA-assistant bot or Signed-off-by checks in CI).

See docs/CLOUD_BOUNDARY.md for the current Phase 7 boundary rules.

Public legal docs

• Add public QQueue Cloud Terms of Service and Privacy Policy drafts under docs/legal/.
• Have the SaaS Terms of Service and Privacy Policy reviewed by qualified legal counsel before serious commercial launch.
• Add a data processing agreement, subprocessor list, cookie policy, SLA, and enterprise terms before larger customer or enterprise sales.

Phase 7 design notes (planning)

• Billing: integrate a payment provider (e.g. Stripe); model plans, seats, and metered usage; handle webhooks for subscription lifecycle events.
• Workspaces: multi-tenant boundary on top of existing organizations; per-workspace isolation of contacts, templates, campaigns, and SMTP configs.
• Usage limits: enforce per-plan quotas (emails/month, contacts, API calls) at the queue/worker layer; surface usage in the dashboard.
• Hosted onboarding: guided signup, managed shared/pooled sending infra, domain + DKIM/SPF verification flows.
• Multi-tenant hardening: row-level tenant scoping audit, rate limiting, noisy-neighbor isolation, per-tenant secrets handling, abuse/deliverability controls.

Phase 7: Managed Cloud

• Billing
• Workspaces
• Usage limits
• Hosted onboarding
• Multi-tenant hardening