Skip to content
Appvecta

Release plan

Seven phases to a private alpha.

Phase 0 closed on 18 September 2026. Private alpha invitations: the week of 11 January 2027.

  1. Phase 0ClosedClosed 18 Sep 2026

    Spike

    Monorepo, protocol, detection, ADB discovery, QA driver spike, graph prototype, branded shell builds.

  2. Phase 1In progress18 Sep – 11 Oct 2026

    Foundation and Run

    Sidebar, settings, prerequisite scanner, run-target discovery, Device Hub, the Run state machine, command policy and audit.

  3. Phase 2Planned12 Oct – 1 Nov 2026

    Appvecta Brain v1

    Parsers, graph store, Android and Flutter role detectors, incremental refresh, architecture classifier, Brain explorer.

  4. Phase 3Planned2 – 15 Nov 2026

    Agent runtime

    Provider interface, Claude Code / Codex / API / Ollama adapters, MCP server, context packs, plan-approve-apply, checkpoints, redaction.

  5. Phase 4Planned16 – 29 Nov 2026

    Tests and QA foundation

    Native tests in the Testing UI, QA plan schema, the driver, evidence collection, reports.

  6. Phase 5Planned30 Nov – 13 Dec 2026

    Guided QA and replay

    Natural language → plan, preconditions, replay, the repair loop.

  7. Phase 6Planned14 Dec 2026 – 10 Jan 2027

    Hardening and alpha

    Packaging, large-repo profiling, redaction tests, onboarding, and 5–10 external testers.

Definition of done

What “MVP complete” means.

The alpha is complete when all of the following are true — not when a date arrives.

  • Android Kotlin, Java and mixed projects detected, indexed, built and run.
  • Flutter projects detected, indexed, built and run on Android.
  • The Brain explains representative UI → state → domain/data paths with source evidence.
  • The graph updates incrementally after a file change.
  • At least the Claude Code and Codex CLI adapters work through supported authentication.
  • Multi-file changes are approved and the resulting diff inspected.
  • Existing native and Flutter tests appear in the editor's testing experience.
  • A deterministic QA plan runs on both an Android-native and a Flutter-on-Android project.
  • A failed flow produces a complete evidence report.
  • Replay reproduces a controlled failure from a declared initial state.
  • The agent can take report plus graph context, propose a fix, rebuild and replay after approval.
  • Secrets, unsafe commands, untrusted repository content and dirty working trees have documented protections.
  • Installation, prerequisites, supported platforms and known limitations are documented honestly.

Quality targets

The thresholds the alpha is being built against.

These are engineering targets verified against six reference projects plus two real projects — not promises for every public repository.

90%

Project detection

Correctly identify at least 90% of selected test repositories.

Engineering target

<60s

Initial index

For a representative medium project.

Engineering target

<3s

Incremental refresh

For a normal single-file change — no full rebuild.

Engineering target

80%

Graph usefulness

At least 80% of manually verified major feature relationships discoverable.

Engineering target

25%

Context efficiency

A task's context pack at most 25% of the naive whole-file baseline.

Engineering target

90%

Deterministic QA

At least a 90% pass rate across 20 repeated runs of stable flows.

Engineering target

50k

Graph view at scale

A 50,000-node graph: overview under 1 s, module expand under 300 ms, 60 fps at 2,000 visible nodes.

Engineering target

6/6

Build and run

Successful on all six reference projects.

Engineering target

After the MVP

What follows the alpha.

Release 0.2

Recorded flows; stronger Compose and Flutter semantics; network controls and mock responses; visual checkpoints; CI export; richer impact analysis; performance and startup smoke tests.

Release 0.3

Exploratory QA within approved boundaries; shared team QA plans; pull-request risk summaries; remote Android device execution; a plugin and provider SDK.

Release 1.0 candidate

A polished branded distribution; iOS support for Flutter; enterprise policy controls; encrypted team graph sync; production crash and analytics integrations.

Post-alpha · free edition

Planned local differentiators.

Ideas that stay on your machine and stay in the free edition.

  • Impact radius before an edit

    Screens, QA flows and tests affected by a symbol, offered to the agent as a tool and to you as "run affected checks".

  • Architecture guard

    Layer rules evaluated on the graph, shown as red edges, runnable in CI.

  • Live trace on the map

    Edges that actually executed during a run light up.

  • Tap on the device, jump to the code

    A UI element maps to its composable or widget, view model and API.

  • Crash to path to repro

    A stack trace maps onto a graph path and drafts a QA flow that reproduces it.

  • "What the AI will see" preview

    The exact context pack, with redaction applied, before anything is sent.

  • Generated onboarding tours

    "How does login work?" becomes a guided walk along the traced path.

  • Screen-level visual regression

    Baseline screenshots per screen node, with diffs.

  • Release readiness check

    Hard-coded keys, unused permissions, missing R8 keep rules, Play policy risks.

  • Multi-device QA matrix

    The same flow on several connected devices, side by side.

Post-alpha · paid

Planned platform phases.

Pricing for any of these is not finalised.

Team server and admin console

Shared org and project graphs, base graph per commit, live developer overlays, conflict detection, team knowledge, a web console for managers, token-saving reports, accounts and roles.

Knowledge Hub

A per-project document store — specs, API docs, designs, notes — answered with citations through MCP and in the IDE.

Appvecta hosted chat

Appvecta-hosted models directly in the IDE, with no MCP setup and no API key.

Enterprise

Cross-project impact ("this backend change breaks 3 app screens"), SSO and SCIM, audit export, data residency, a self-hosted server, air-gapped mode.