Track C — Launch Features
The minimum feature set before real users, in build order — and what explicitly waits
The roadmap lists everything the product could do. This page is the cut: what must exist before letting users in (beta blockers), what ships in the weeks right after (fast follow), and what explicitly waits. Specs live in the roadmap/plan pages — this page only fixes scope and order.
Scope discipline
A feature is a beta blocker only if launching without it either breaks trust (users hit dead ends), breaks the law (GDPR, EU consumer rules), or is the reason the product exists (the price-comparison differentiator). Everything else is fast-follow — beta users forgive missing features, not broken ones.
Beta blockers (M3)
Build in this order — the numbers are the dependency chain, not just priority. Start only after quality phases 0–4 are done (why).
| # | Feature | Effort | Spec | Why blocking |
|---|---|---|---|---|
| 1 | Notifications seam — event emitter + one listener module owning all mailer templates | M | Operations §4 | #2–#4 all hang off it; bolting mailer calls into services twice is rework |
| 2 | Email verification for local accounts — verify token flow, gate deal publishing on it | M | Launch checklist | Unverified emails = spam listings + undeliverable notifications |
| 3 | Transactional emails — deal approved/declined (incl. reasonDeclined), new message while offline | S | Notifications spec | A seller whose deal silently disappears doesn't come back |
| 4 | Deal expiry job — cron sets EXPIRED after 60 days | S | Operations §3 | Dead listings kill buyer trust in week one |
| 5 | "New price" comparison on deals — "€89 — sells new for €129 (−31%)" on cards + detail | S | Roadmap #1 | The differentiator; mostly a mapper + UI change, data already exists. Beta must showcase it |
| 6 | Password change + account deletion (soft-delete, anonymize messages/deals) | M | Launch checklist | GDPR — deletion is a legal right, not a feature |
| 7 | Legal pages — ToS, privacy, cookies | S code (content is the work) | Legal & compliance spec | EU requirement; OAuth providers ask for the privacy URL |
| 8 | SEO basics — generateMetadata OG tags on deal/product pages, sitemap.xml, robots.txt, canonicals | S–M | Launch checklist | Organic search is the acquisition channel; indexing takes weeks — ship before beta, not after |
Also due in M3 but tracked as ops, not features: health endpoint, Sentry on all three apps, backups, uptime monitoring (Quality — phase 7b).
Fast follow (M4)
Prioritized by beta feedback, but the expected order:
| Feature | Effort | Spec | Notes |
|---|---|---|---|
| Report listing / report user + moderation queue | M | Roadmap | Reuses the deal-moderation pattern. Promote to beta blocker if beta is >~50 users |
| Favorites / watchlist on deals | M | Roadmap | First retention feature; saved searches come later |
| Fair-price guidance in the deal stepper | M | Roadmap #3 | Needs catalog prices (M2) — suggest a range from current new prices |
| Price-drop alerts on catalog products | M | Roadmap #2 | Needs PriceHistory (scheduled in Catalog §6) + notifications seam |
| Seller profile upgrades — member-since, verified badge, sold count | S | Roadmap | Cheap trust signal |
| Draft autosave + "my listings" management (relist expired, mark reserved) | M | Roadmap | Pairs naturally with the expiry job |
Explicitly waiting (post-launch)
Per the roadmap priorities: in-chat offers, ratings & reviews (needs a transaction concept), geolocation, i18n (FR/EN), PWA/push, payments & escrow, delivery, verification, Discord login, drone-builds display, image-based listing creation, admin analytics.
The one pre-decision worth making now: i18n. Retrofitting is painful — if FR/EN is wanted within 6 months of launch, at minimum keep user-facing strings out of deep component logic starting today (spec). Everything else on this list has no "decide early" tax.
Definition of done (every feature)
- Follows the frontend / backend conventions; verification gates green.
- Ownership checks in the service, with a regression test (post-quality-phase-2 rule).
- Emails have a plain-text fallback and were sent to a real inbox once.
- The feature is reachable from the UI without a URL being typed — if a beta user can't find it, it doesn't exist.