Roadmap

Features and capabilities explicitly considered and deferred. Pairs with Status for what's currently in flight; this page goes deeper into why each item isn't built.

Web product surface

What it would be: authenticated routes on wearenxt.com — Discover rails, college detail, saves, profile — so students could use NXT on desktop.

Why deferred:

• Adds a second auth surface to harden, monitor, and patch.
• Duplicates the design system between mobile and web.
• Increases the deploy blast radius (a marketing site bug ≠ a product bug).
• Mobile is where the user signal lives — the marketing site's job is App Store + Play Store installs, not to compete with the app.

Cost to add: ~3 weeks for a small team. Routes + Convex queries (most exist already) + (authenticated) route group + responsive design pass.

Trigger to add: sustained analytics showing students want desktop, OR an enterprise customer (district / counselor admin) requires browser-based access.

In-app chat with counselors

What it would be: real-time DMs between students and verified counselors or peers.

Why deferred:

• Requires live moderation infrastructure (or a moderation vendor).
• Escalation path for crisis-level content (suicide, abuse) needs a real plan, not an MVP.
• Conversation storage is PHI-adjacent for under-18 users — DPA + parental consent become hard problems.
• The matching engine's job is "show students the right schools." Chat is a different product.

Cost to add: ~6 weeks minimum. Vendor (Stream / Sendbird) + moderation + crisis playbook + legal review.

Trigger to add: unclear. Don't build this without a clear "users are blocked because we don't have it" signal.

Application tracking (Common App integration)

What it would be: students mark applications as submitted, see deadlines, see acceptance / rejection / waitlist.

Why deferred:

• Common App doesn't have a public API for submission status. Would require manual user input or web scraping (fragile, against TOS).
• Deadlines today fire from a static map in lib/deadlines.ts. Adding submission tracking is net-new state to maintain.

What ships today: deadline reminders (14/7/3/1 days out).

Cost to add: ~4 weeks for the manual-input version. Indefinite for the Common App-integrated version.

Trigger to add: real student demand. Today there's nothing in analytics suggesting submission tracking is missing.

District / counselor admin dashboards

What it would be: an admin surface where a school counselor or district administrator could see their students' progress, save lists, and aggregate stats.

Why deferred:

• Consumer-only today. The B2B2C model is aspirational (South University pipeline, Florida district pipeline) but not yet contractually committed.
• The b2b addon pattern exists in create-nextbuild (membership tables, role-based queries) but hasn't been wired in.
• Privacy posture is more complex: a counselor seeing a student's profile is a different consent model than the student themselves seeing it.

Cost to add: ~3–4 weeks for v1. Wire b2b addon → add admin route group → membership-aware Convex queries → admin UI.

Trigger to add: signed enterprise customer. Build for one specific customer, not in the abstract.

Second language

What it would be: Spanish (most likely) added to the i18n catalog. Possibly French.

Why deferred:

• No user signal yet. The current user base is English-speaking.
• Translation quality matters more than translation completeness — machine-translated copy in a college-matching app would feel cheap.

Cost to add: ~2 weeks. Translation pass (paid translator) + i18n locale file + a light pluralization / RTL audit (no RTL languages needed yet).

Trigger to add: any sign of Spanish-speaking demand in PostHog (user locales, search queries, account creation language headers).

Staging Convex deployment

What it would be: a separate Convex deployment for the staging mobile channel.

Why deferred:

• Doubles operator burden: two sets of crons firing, two sets of credentials, two sets of webhook endpoints, two sets of cost.
• The dev deployment already serves QA + integration testing.
• TestFlight builds against production Convex have proven sufficient; signed-in test accounts cover the gap.

Cost to add: ~1 day. Provision deployment, set env vars, point staging EAS profile at it.

Trigger to add: the first time a production Convex bug ships because someone tested on dev and got different state.

CI deploys for backend

What it would be: GitHub Actions runs npx convex deploy on main push.

Why deferred:

• Today's operator-machine deploy is reliable and gives a final human checkpoint.
• The cost of a bad deploy (revert + redeploy) is low because Convex deploys are atomic.

Cost to add: ~1 day. GitHub Action + Convex deploy token + branch protection rule.

Trigger to add: more than one engineer regularly deploying. The serialization point becomes a bottleneck.

Convex outbound backups

What it would be: scheduled npx convex export writes to S3 / R2.

Why deferred:

• Convex's internal point-in-time snapshots are the recovery story.
• Outbound backup is defense-in-depth, not primary recovery.

Cost to add: ~30 minutes. Configurable in the Convex dashboard.

Trigger to add: anytime. Cheap. Just hasn't been a priority.

Diversity slider

What it would be: a UI slider letting students weight rails by demographic mix (MSI presence, gender balance, etc.).

Why deferred:

• Backend signal wiring is done.
• UI / UX design needs a serious pass — a slider for demographic preference is sensitive copy and a sensitive interaction.

Cost to add: ~1 week engineering once design lands.

Trigger to add: design review + a clear hypothesis that the slider improves rail relevance.

Push notification volume tuning

What it would be: A/B-tested cadence on deadline reminders + new-matches alert.

Why deferred:

• Current cadence (deadline reminders 14/7/3/1, weekly new-matches Sunday 11am ET) is the conservative starting point.
• User base too small to A/B test meaningfully.

Cost to add: trivial code change (crons.ts). Real cost is the analytics setup to measure response.

Trigger to add: user base above ~5K MAU.

Technical detail

How to reopen any of these

1. Read the reason here.
2. Confirm the trigger has fired.
3. Update the relevant section in Status when work starts.
4. Move the decision rationale to the implementation's PR description so it doesn't get lost.

What NOT to reopen without a fresh decision

• Re-adding the V1 RAG architecture. Don't. The reasons it didn't work are documented in AI and matching. If a future need for semantic search emerges, build it additive to the deterministic engine, not as a replacement.
• Re-running the V1 CSV ingestion pipeline. The live-Scorecard-with-cache model is strictly better. The V1 scripts under legacy/v1-archive/packages/backend/scripts/ingestion/ exist for historical reference only.
• Per-school admin manual override of Scorecard data. Considered. Would create a divergent source of truth between NXT and Scorecard. If Scorecard is wrong about a school, file with the U.S. Department of Education, not with NXT.