Aestra

Why you’re reading this

This memo replaces the prior roadmap assumptions and sets a single goal: ship a credible, stable Aestra v1 Beta by December 2026.

This is not a marketing doc and not a feature wish list. It’s a practical engineering plan that optimizes for:

All claims are based on repo state as of January 2026.

Executive summary (what changes today)

For the near-exhaustive execution backlog, see: docs/technical/v1_beta_task_list.md.

Non-negotiable product philosophy

Aestra will not try to be Ableton, FL Studio, or Reaper. Aestra will do one workflow exceptionally well: pattern-based Hip-Hop music production with rock-solid stability.

Principles:

What changed since the previous roadmap

The old plan implied near-term Beta and broad feature growth. The current reality is:

This memo resets expectations and defines what “v1 Beta” means.

Current State Assessment (based on repo structure)

This is not a feature list. It’s an engineering maturity assessment.

Production-Grade (or close)

These are subsystems that appear architecturally disciplined and already have the right “shape” for shipping:

Experimental / Incomplete

These exist but are not yet “product-complete,” i.e. they will break user trust if shipped without hardening:

Technically impressive but product-invisible

These are valuable, but if you over-invest here you risk shipping nothing:

Missing but critical (for a respected Beta)

These are the Beta blockers that determine whether users can trust the app:

Define “Aestra v1 Beta” (December 2026)

Aestra v1 Beta is not “everything a DAW should do.” It is:

1) a complete core workflow that real musicians can finish tracks in, 2) stable enough that projects don’t get lost, 3) performant enough that it feels professional on commodity hardware.

Platform assumptions

Supported workflows (in)

Aestra’s v1 Beta is a pattern-first production DAW, optimized for electronic music / sample-based production:

Beta stability expectations

Performance targets (concrete)

Intentionally out (post-Beta)

If these land, great — but they are not Beta blockers:

Scope Control Rules (non-negotiable)

1) Every new feature must land with a test plan and a rollback plan. 2) No new subsystems in Q4 2026 (Beta hardening phase). 3) If a feature can’t be made reliable, it’s out. 4) Prefer fewer workflows done well over broad capability.

Roadmap Phases (now → Dec 2026)

Dates are approximate; the key is sequencing and freeze points.

Phase 1 — Foundation lock (Jan–Mar 2026)

Primary goal: stop the product from being “a demo held together by Main.cpp.”

Deliverables:

Freeze:

Phase 2 — Project + undo/redo become real (Apr–Jun 2026) ⏳ In Progress

Primary goal: users can trust edits.

Deliverables:

March 2026 snapshot:

Freeze:

Phase 3 — Recording + export (Jul–Sep 2026)

Primary goal: finishing tracks becomes possible.

Deliverables:

Freeze:

Phase 4 — Plugin scope decision (Sep 2026)

This is a single decision gate, not an open-ended plugin roadmap.

Option A (recommended if bandwidth is tight):

Option B (only if it can be made robust):

Hard rule:

Phase 5 — UX hardening + Beta freeze (Oct–Nov 2026)

Primary goal: stop changing what the app is, and make it reliable.

Deliverables:

Freeze:

Phase 6 — v1 Beta release (Dec 2026)

Deliverables:

Industry Reality Check (how to win without competing everywhere)

Where Aestra can be competitive

Where Aestra should not try to compete (for Beta)

Aestra’s edge is not “more features.” It’s:

Hard Truths (what to stop / double down on)

Stop:

Double down:

Kill (if they threaten the schedule):

Last updated: March 2026

This site is open source. Improve this page.