← Back to roadmap

Development Roadmap

Technical plan for builders. Each milestone includes scope, acceptance criteria, risks, and dependencies.

Last updated: February 2026. All dates are targets and may shift based on testing outcomes.

M0Project Foundation

Completed
Jan-Feb 2026

Outcome

Project setup, CI/CD, and basic app scaffolding.

Submilestones

  • M0.1Repository setup and Gradle configuration
  • M0.2CI/CD pipeline (GitHub Actions)
  • M0.3Code signing and release workflow
  • M0.4Base Android project structure
  • M0.5Navigation scaffolding (Jetpack Compose)
  • M0.6Theme and design system tokens
  • M0.7Debug build variants and logging
  • M0.8Unit test scaffolding
  • M0.9Instrumented test scaffolding
  • M0.10Basic settings screen

M0.11VPN Feasibility Spike

Completed
Feb 2026

Outcome

Prove the VPN service can run stably on Android with lifecycle management, conflict handling, and kill switch.

Submilestones

  • M0.11.1VpnService lifecycle (start, stop, crash recovery)
  • M0.11.2Foreground notification for VPN active state
  • M0.11.3Network traffic byte counters (up/down)
  • M0.11.4Conflict detection with other active VPNs
  • M0.11.5Kill switch via always-on VPN lockdown
  • M0.11.6User consent flow for VPN permission

Technical approach

Use Android VpnService API. Implement a foreground service with persistent notification. Handle VPN revocation and conflicts via BroadcastReceiver. Kill switch uses Android native always-on VPN with lockdown mode.

Acceptance criteria

  • VPN starts and stops cleanly 50 consecutive times without crash
  • Kill switch blocks all traffic when VPN service is stopped unexpectedly
  • Conflict with another VPN is detected and surfaced to the user
  • Battery impact under 5% in 24-hour test

Risks

  • OEM-specific VPN behavior (Samsung, Xiaomi battery optimization)
  • Android version differences in VpnService lifecycle
  • Only one VPN can be active at a time (platform limitation)

Dependencies

  • M0.1-M0.10 (project setup, CI, basic UI scaffolding)

M1Storage, Incidents, and Privacy Foundation

In progress
Mar 2026

Outcome

Encrypted local storage, incident logging schema, and privacy controls UI.

Submilestones

  • M1.1Encrypted SQLite database (Android Keystore derived key)
  • M1.2Incident log schema and CRUD operations
  • M1.3Privacy Center UI: retention controls
  • M1.4Data purge functionality
  • M1.5Sanitized export to JSON
  • M1.6Settings persistence (SharedPreferences + encrypted DB)

Technical approach

SQLCipher for encrypted SQLite. Room as the ORM layer. Privacy Center as a dedicated settings screen. Export strips PII (device IDs, account emails, exact timestamps) and outputs a JSON file via Android share intent.

Acceptance criteria

  • Database survives app restart and OS kill
  • Export JSON does not contain device serial, Google account, or exact timestamps
  • Delete All removes all rows and resets baseline state
  • Retention policy automatically removes records older than configured days

Risks

  • SQLCipher adds APK size (approximately 3-5 MB)
  • Room migration complexity if schema changes later
  • Export on older Android versions may require different share intent handling

Dependencies

  • M0.11 (VPN service for traffic counters)

M2Monitor Mode Sensors and Baseline v0

Planned
Apr-May 2026

Outcome

Passive metadata collection and first statistical baselines.

Submilestones

  • M2.1Network flow sensor (destination IP, port, request count, timing)
  • M2.2Permission usage tracker
  • M2.3App install source detector (Play Store vs sideloaded)
  • M2.4Background activity monitor (wake locks, foreground services)
  • M2.5Baseline calculation v0 (rolling window statistics)
  • M2.6Basic drift scoring (z-score based)
  • M2.7Monitor Mode toggle and debug screen

Technical approach

Network sensor reads from VPN tunnel packet headers (IP + port only, no payload). Permission tracker uses PackageManager queries on a schedule. Baselines calculated with 7/14/30-day sliding windows, storing mean, stddev, and percentiles per metric per app.

Acceptance criteria

  • Sensor captures network metadata for all apps routing through VPN
  • Permission changes detected within 60 seconds
  • Baseline established after 7 days of data for a given app
  • Drift score increases when simulated anomalous traffic is injected

Risks

  • High-frequency apps (social media, messaging) may generate noisy baselines
  • Battery impact from continuous sensor polling needs careful tuning
  • Version-aware baseline reset needed when apps update

Dependencies

  • M1 (encrypted storage)
  • M0.11 (VPN for network sensor)

M3Protect Mode (VPN Enforcement MVP)

Planned
Jun-Jul 2026

Outcome

Automatic containment of apps that exceed drift thresholds.

Submilestones

  • M3.1VPN routing engine with per-app allow/block rules
  • M3.2Containment trigger from drift score threshold
  • M3.3Incident notification explaining what changed
  • M3.4Review UI for contained apps (allow, keep blocked, permanently block)
  • M3.5App update grace period (learning window after version change)
  • M3.6Protect Mode toggle in settings

Technical approach

VPN packet filter checks app UID against containment list. Drift threshold is configurable per mode. Notifications use Android notification channels with expand-to-review action. Grace period resets baseline window on detected version change.

Acceptance criteria

  • App exceeding drift threshold is contained within 30 seconds
  • Contained app cannot make outbound network connections
  • User can allow or keep blocked from notification or review screen
  • App update triggers grace period and suppresses enforcement for configured duration

Risks

  • False positives during early tuning may frustrate users
  • Notification fatigue if many apps trigger simultaneously
  • Some apps may not function correctly when contained (need clear UX)

Dependencies

  • M2 (sensors + drift scoring)
  • M0.11 (VPN enforcement)

M4Baseline Scoring v1

Planned
Aug-Sep 2026

Outcome

Improved drift detection accuracy with multi-dimensional scoring and user feedback.

Submilestones

  • M4.1Multi-dimensional scoring (network + permissions + behavior combined)
  • M4.2Context-aware weighting (time-of-day, connection type)
  • M4.3Confidence intervals for anomaly significance
  • M4.4Version-aware baseline transitions
  • M4.5User feedback loop (mark as false positive / legitimate)
  • M4.6Per-app scoring weight persistence

Technical approach

Weighted composite score across all sensor dimensions. Context features (time bucket, wifi vs cellular) added as conditioning variables. User feedback adjusts per-app scoring weights over time.

Acceptance criteria

  • False positive rate below 10% in controlled testing
  • User feedback reduces repeated false positives for the same app
  • Time-of-day patterns correctly suppress expected nighttime backup activity

Risks

  • Scoring model complexity may increase battery and compute cost
  • User feedback data needs careful privacy handling (stays local)

Dependencies

  • M3 (Protect Mode)
  • M2 (baseline data)

M5MVP Hardening and Store-Ready UX

Planned
Oct-Nov 2026

Outcome

Polished app ready for public beta on Google Play.

Submilestones

  • M5.1Onboarding flow explaining modes and permissions
  • M5.2In-app help and documentation
  • M5.3Performance optimization (battery, memory, startup time)
  • M5.4Crash reporting (opt-in only)
  • M5.5Play Store listing, screenshots, and marketing assets
  • M5.6Beta testing program via waitlist invitations

Technical approach

Onboarding as a multi-step wizard. Performance profiling with Android Studio profiler. Crash reporting via opt-in Firebase Crashlytics (no PII collected). Beta distribution via Play Store internal testing track.

Acceptance criteria

  • New user can complete onboarding and reach Monitor Mode in under 2 minutes
  • Battery impact under 5% in 24-hour usage
  • App starts in under 2 seconds on mid-range device
  • Crash-free rate above 99% in internal testing

Risks

  • Play Store review may question VPN usage (need clear privacy policy)
  • Onboarding complexity if user denies permissions

Dependencies

  • M4 (scoring v1)
  • M3 (Protect Mode)