Roadmap & Recommendations

Dashify shipped twenty-five phased releases to reach the version this documentation describes. None of those phases were the last, every shipped feature opened a door into something more ambitious. This page is the honest map of what is coming next, organised by area, with rough priorities.

It is also a list of recommendations for any team that wants to fork the platform or use it as a base. If you do, here is where you should aim your first releases.

Phase 7, sharper auth surfaces

The authentication layer is in good shape. A few rough edges remain.

Step up authentication. Today, sensitive actions (changing 2FA settings, adding an SSO provider) require the password and a TOTP. They should also be permitted via a fresh passkey gesture, tapping the fingerprint sensor right now. Conceptually simple, mostly UX work.

Hardware-key-only mode. Some compliance regimes require all admin actions to be authenticated by a hardware key (YubiKey, etc.) rather than software-stored passkeys. Adding a per tenant policy switch that enforces this would unlock those customers.

Passkey recovery codes. Currently a lost device with no synced passkeys requires admin intervention. Issuing recovery codes specifically for passkey reauthentication would close the loop without weakening anything.

Phase 8, multi region

Today Dashify can be deployed in any single region. Multi-region would mean serving different tenants from different data centres for latency or data-residency reasons.

This is a real chunk of work because Mongo and Redis both need careful thought across regions. The recommended approach: per tenant region pinning, when a tenant is provisioned, they are bound to a region; their data only ever lives there; the routing layer sends their requests to the right cluster. This avoids the much harder problem of multi-master writes across regions.

Phase 9, content security tightening

The CSP allows 'unsafe-inline' for styles. The next step is to remove that by adopting hashed CSS (CSS modules already produce hashed class names; the work is to ensure no inline <style> blocks remain). Once gone, the CSP becomes one of the strictest possible.

Subresource Integrity (SRI), verifying every third-party script with a content hash, is also on this list. Currently the few external CDN scripts (CKEditor, Cloudinary widget) are loaded without SRI. Adding it makes a compromised CDN unable to substitute malicious code.

Phase 10, anomaly detection

The audit log is forensic: it records everything so you can reconstruct what happened. Behavioural detection, spotting that this is unusual, is the next layer.

Examples:

• A user logging in from a new country.
• A sudden spike in PAT use from an unusual IP.
• An admin granting an unusually permissive role.
• A SCIM batch that disables far more users than usual.

The implementation would be a stream of events from the audit log into a small classifier (rule-based first, ML later if it earns its keep). Suspicious events fire a heightened audit entry and optionally email the affected user and the org admin.

Phase 11, federated AI

Today the on prem AI is a single Ollama container. Two upgrades:

GPU-backed Ollama. Move the AI tier to a host with a GPU for dramatic speedup on heavier models. The platform already supports BYO models, switching from Qwen 1.5B to Llama 3 8B becomes practical with a GPU.

Federated retrieval. Currently each tenant's vectors are partitioned in Qdrant. A more advanced setup would let an enterprise customer federate vectors across their own tenants (parent/child orgs) for cross-org search, while still preventing cross-customer leakage.

Phase 12, public API & SDKs

Dashify has a private API (used by the browser app) and a SCIM/PAT public surface. A first-party public API with proper docs, versioning, rate limits, and SDKs in TypeScript and Python would unlock integrations.

The OpenAPI/Swagger definition exists internally. Polishing it, versioning it (/api/v1/, /api/v2/), and publishing client SDKs would be a focused, valuable phase.

Phase 13, workflow automation

A "Zapier inside" concept: tenant-defined triggers (when a work item moves to Done, when an invoice is paid, when a user is added to a project) firing webhooks or internal jobs (post to a chat channel, update an external system, send an email).

The plumbing is already there, events are emitted, the queue exists, audit logs are structured. The work is the configuration UI and a small DSL for actions.

Phase 14, mobile

A React Native app sharing the API layer with the web app. The PWA already gets us most of the way; a native app would add push notifications via APNs/FCM, deeper biometric integration, and offline-first work-item editing.

Push notifications are the most-requested feature and the most-impactful single addition to mobile. The infrastructure for in app notifications is in place; wiring up actual platform push is a tractable phase.

Recommendations for adopters

If you fork Dashify or use it as a starting point, a few things to plan for from day one.

Spend the first two weeks on observability. Wire up your log aggregator, your metrics provider, your error reporter. Until you can see what your platform is doing, you are guessing. The platform makes this easy; do not skip it.

Pick your IdP early. If you are running Dashify at any scale, SSO + SCIM should be the default for your team, never use the platform's own password auth on anything but emergency accounts. Configure your IdP first; everything afterwards is smoother.

Set strong CSP and HSTS in production. Both ship enabled, but they are toothless if the deployment is not on HTTPS. Make HTTPS the floor, not the ceiling.

Make the audit log immutable. The platform keeps it append-only by convention, but stream it to an external write-only store to protect against database-level tampering. This is the kind of thing you want to set up once at the start, not under pressure during an incident.

Decide your data-retention policy. Audit logs, deleted documents, chat history, they all grow forever by default. Pick a window (90 days? 365 days? forever?) and configure the cleanup jobs accordingly. The platform supports any window; it has no opinion.

What this roadmap is not

This is not a commitment. Dashify is a solo project alongside professional work. Items on the roadmap are honest priorities, not contracts. If a real-world need pulls a phase forward (or makes it irrelevant), the order changes.

The next page lists known gaps, things that already need fixing, and that list is at least as important.

Key takeaways

• The roadmap continues across auth refinements, multi region, CSP tightening, anomaly detection, federated AI, public APIs, workflow automation, and mobile.
• For adopters, the highest-leverage early investments are observability, IdP setup, HTTPS-only, immutable audit log, and retention policies.
• This roadmap is a set of priorities, not a contract, Dashify evolves with the constraints of one builder.