Wholisphere
Roadmap

What we're building.

Four columns, no surprises. Now = in flight. Next = committed for the next release. Later = on the table. Won't do = deliberately off the table, with reasons. Want to push something up? Email roadmap@wholisphere.ai.

Now

In active development. Targeting the next release.

  • Native mobile app scanning

    Automated WCAG 2.2 A+AA checks for native Android apps, driven through the platform’s own accessibility tree, pixels, gestures and sensors — the same in-house, no-third-party-engine philosophy as the web scanner. Every A+AA criterion now returns a verdict; nothing is punted to a manual checklist. In developer preview (CLI against your build); hosted scanning and iOS are next. See Native Mobile Scanning.

Next

Committed for v0.x. Not started yet but the design is settled.

  • SOC 2 Type I attestation

    Drata audit underway. Targeting a completed Type I report in Q3 2026 so enterprise procurement can stop blocking on it. Type II window starts immediately after.

  • Self-hosted (on-prem) Docker bundle

    Postgres + Hono backend + the widget assets in a Docker Compose stack. For regulated sectors (healthcare, banking, gov) that can’t ship visitor text to a vendor cloud. BYO LLM endpoint (Anthropic/OpenAI/Bedrock/local).

Later

Under consideration. Real customer demand will move things up.

  • iOS + Android SDKs

    Same agent capabilities surfaced inside native apps. Only worth doing once the web-side product is sticky enough that customers ask for parity. We’re listening; tell us if you’d use it.

  • FedRAMP Moderate authorization

    Federal customers have asked. The path is clear (FedRAMP-Ready → JAB or sponsor agency → Moderate ATO) but it’s a 12–18 month commitment we’ll only start once a sponsor agency is committed.

  • Whole-site link spidering

    Today, page discovery is sitemap- or URL-list-driven (plus the opt-in multi-step flow crawler, which is a different, safety-contracted thing). A general link spider — crawl every reachable page automatically — needs its own politeness, scoping, and cost guardrails, so it stays here until we can ship it responsibly.

Won't do

Things people sometimes ask for that we will deliberately not build, with reasons.

  • "Overlay" mode that auto-fixes ARIA + claims WCAG conformance

    This is exactly what AccessiBe / UserWay / EqualWeb do, and it’s the pattern that’s been the subject of 200+ ADA lawsuits. It hurts users (breaks real screen readers), hurts customers (vendor liability), and damages the accessibility profession’s credibility. We will not ship this even if it’s profitable.

  • Cross-site visitor analytics

    We could profitably aggregate “which capabilities does which user enable on which sites” across our entire embed footprint. We won’t. That data belongs to your visitors, not to us. The only telemetry we collect is per-org, opt-in, and exportable.