What is not in v2.0.0, and whether it is coming. Every row here was decided, not forgotten, and the reason is on the row.
You own the source, so nothing on this page is a wait: anything under "Considering" is a feature you can build yourself, and EXTENDING.md walks one through end to end. This list tells you where we are going, so you can decide what is worth writing twice.
Not in the box
Three features people ask about, deliberately absent. Read this before you buy, not after.
| Feature | Status | Why |
|---|---|---|
| Time tracking | v2.1 | Timers are a client-billing feature, not a project-management one. The budget bought subtasks and labels instead, which every team uses |
| Analytics charts | v2.1 | The dashboard ships counts and an activity heatmap, not velocity or burndown. A chart needs history to say anything, and a new install has none |
| Project documents | v2.2 | A half-feature: too little to be a documents product, too much to maintain. Rich text still ships — task descriptions and comments both use it |
If you are moving from DailyTM v1, time tracking is the one that breaks parity. See UPGRADING.md.
Considering — task modelling
| Feature | Notes |
|---|---|
| Timeline / Gantt view | The view switcher and its URL filter state are already shared, so a fourth tab is cheap |
| Task dependencies | Blocks / blocked-by. Worth little without the timeline view above, so the two move together |
| Recurring tasks | The scheduled-job runner already ships; what remains is a recurrence rule and a materialise decision |
| Saved views | Filters already live in the URL, so a view is shareable today. This persists one per user or per org |
| Bulk edit and multi-select | Needs multi-select on list and board, plus a batch mutation that reports partial failure |
| Group the board by anything | The board groups by status. Assignee, priority, and label are the same query with a different key |
| Subtasks deeper than one level | One level keeps the completed/total rollup a single query. A second level needs a recursive CTE |
| Reordering a subtask by hand | Subtasks carry a rank and are appended in order; nothing in the interface changes it |
| Task templates, milestones | — |
Considering — collaboration
| Feature | Notes |
|---|---|
| Email digests | v2.0.0 sends per-event email. A digest adds a frequency preference and a batching job |
| Threaded comment replies | Needs a self-relation, a depth rule, and a decision about what a deep reply notifies |
| Reactions on comments | — |
@project and @everyone |
Mentions resolve to individual members today, which keeps the visibility check trivial |
| Search across comments and files | The search index covers task title, task description, and project name |
| A full search results page | Search is reachable through ⌘K. A page with facets is the next step, not the first one |
| A per-organization timezone | The due-date reminder job uses UTC for its day boundary. The fix is a column plus a picker |
| Status templates per org | Every project starts from the same six defaults; a shared set would be copied at creation time |
Considering — later
Exports (CSV, PDF) · CSV import · task estimates · capacity and workload · project templates · an onboarding checklist · teams inside an organization · runtime-defined custom roles · PWA and an offline queue · real-time collaboration.
The last two would change the tRPC transport, which makes them an architectural change rather than a feature.
Not planned
Recorded so you know they were considered and rejected, not overlooked.
| Item | Why not |
|---|---|
| An automated v1 → v2 data migration | A Kinde identity cannot become a Better Auth user without every person resetting their password anyway. UPGRADING.md explains it properly, and gives you the manual path |
| Row-level security for tenancy | It needs a per-connection tenant setting, which fights connection pooling and Prisma's client model. Tenancy is enforced in the service layer instead, backed by lint rules and a per-service authorization test |
| Server Actions alongside tRPC | Two places authorization could be bypassed, and two patterns for you to learn |
| A storage provider abstraction | There is one implementation. Your S3 endpoint is a configuration value, not a plugin point |
| Redis for auth rate limiting | It would add a hosted-service account to a product whose promise is that it installs from three environment variables. Better Auth's secondary-storage hook is where you swap it if you outgrow the default |
| Google Calendar two-way sync | A second OAuth grant, token refresh, expiring watch channels, conflict resolution, and Google's review for sensitive scopes — plus a Google Cloud project on every install's critical path. The signed .ics feed does the useful 90% with no account at all |
| A calendar component library | The month grid is around 100 lines of date-fns and inherits the design tokens. A library would ship its own stylesheet, which would not |
Operational work
Not features — real work a busy deployment eventually wants. None of it matters on day one; all of it is listed so that none of it is a surprise.
| Item | When it starts to matter |
|---|---|
CREATE INDEX CONCURRENTLY in migrations |
The first index added to a table that already holds real rows. Prisma wraps migrations in a transaction, and this cannot run inside one |
| Tuning the orphaned-file sweep | The job runs daily over 500 rows. Both numbers are guesses that have never met a real bucket |
Pruning webhook_event and rate_limit |
Both grow slowly and nothing prunes them yet. One DELETE each, on the cron route that already exists |
| Connection pooling | Your first real deployment — see DEPLOYMENT.md |
| A backup and restore runbook | Before your first paying tenant |