Aspirational

These features are part of the product vision. They represent committed direction, not a wishlist, but they do not have scheduled timelines. Each item is something we intend to build; the question is when, not whether.

For the complete status overview, see Current Status.

Product Vision

Feature	Description
Multi-Tenant SaaS Hosting	Managed Moodle instances as a service line (Campus EAD / MIDDAG Pro)
Billing Reports and Analytics	Revenue dashboards, entitlement analytics, financial reconciliation
Admin Dashboard Analytics	Extended metrics beyond the planned dashboard: cohort analysis, churn

Multi-Tenant SaaS Hosting

The plugin already manages environments with parent-child hierarchy. The aspirational step is turning this into a fully managed SaaS offering where customers purchase a hosting entitlement and receive a provisioned Moodle instance automatically, with monitoring, backups, and lifecycle management handled by the plugin.

Billing and Analytics

Today the plugin tracks financial records (orders, invoices, credit balances). The aspirational step adds reporting views: monthly recurring revenue, entitlement growth trends, renewal rates, and revenue reconciliation across the BR and US entities.

Developer Experience

Feature	Description
TypeScript Types Package	Published npm package with API response types for portal developers
OpenAPI Specification	Machine-readable spec for REST API v1, auto-generated from code
CI/CD Automated Testing Gate	Continuous integration with coverage thresholds and quality gates
Hooks Documentation	Public developer documentation for all action and filter hooks

TypeScript Types

Portal developers building custom frontends against the REST API currently have no type safety. A published @middag-io/account-types package would provide TypeScript interfaces for every API response, generated from the PHP entity definitions.

OpenAPI Auto-Generation

The REST API v1 follows consistent patterns (envelope, error codes, pagination). An auto-generated OpenAPI 3.1 spec would enable client SDK generation, Postman collections, and automated contract testing.

CI/CD Gates

The project already runs composer check locally (PHPStan, PHP-CS-Fixer, Rector, PHPUnit). The aspirational step automates this in CI for every pull request, with minimum coverage thresholds (Domain 90%, API 70%, Integration 60%, WordPress 50%).

Operations and Infrastructure

Feature	Description
Cron Health Monitoring	Admin notices for cron job health and scheduled task status
Theme-Overridable Email Templates	Customizable email notifications with a template override system
Marketplace Listing	Distribution via WordPress.org plugin directory
Database Migration to CCT	Full transition from wp_posts/wp_postmeta to custom tables

Email Templates

The plugin currently has email notifications implemented inline. The aspirational approach is a template system where themes can override email templates (similar to WooCommerce email templates), with default templates using the MIDDAG design system.

Marketplace

Publishing to WordPress.org requires meeting their review guidelines, which aligns with the existing best practices checklist. This also implies removing the WooCommerce dependency for the core plugin and making it a recommended companion.

Portal and White-Label

Feature	Description
White-Label Portal Support	Branding customization for agencies building portals for their clients
Mobile-Responsive Portal	Optimized customer portal experience for mobile devices
Portal Theme API	Hooks and filters for deep portal customization without forking

White-label support enables agencies to deploy MIDDAG Account for their own clients with custom branding, domain, and color scheme, while keeping the underlying infrastructure managed centrally.

How Aspirational Differs from Planned

Aspect	Planned	Aspirational
Timeline	Next development cycle	No scheduled timeline
Spec	Written or in progress	Direction defined, spec not started
Resources	Committed	Not yet allocated
Dependency	May block other planned work	Independent of current cycle
Promotion	Moves to Available Now when shipped	Moves to Planned when spec work begins

When an aspirational feature gets a specification and committed resources, it moves to Planned.