Aura’s launch direction is now SiteAgent-first.
That is not just a marketing line. It changes the product order, the content strategy, and the way we decide what belongs in the free plugin versus the paid SaaS layer.
The short version: agencies need trustworthy WordPress visibility before they need more automation.
Phase 1: Make SiteAgent useful on its own
SiteAgent is the free WordPress plugin behind Aura.
The first job is not to hide everything behind a SaaS upgrade. The first job is to make the plugin a useful, inspectable bridge between a WordPress site and the broader operations layer.
That means focusing on:
- Site health and environment context.
- Plugin and theme inventory.
- Update visibility.
- Authenticated site connection.
- Maintenance-action foundations.
- Clear documentation and public trust.
If an agency installs SiteAgent and immediately understands why it exists, the rest of Aura has a much stronger foundation.
Phase 2: Validate agency fleet workflows
Once sites are connected, the next question is workflow.
What does an agency actually need to do every week?
- See which sites need attention.
- Decide which updates are safe.
- Confirm backup confidence.
- Avoid risky WordPress core rollout by default.
- Run constrained actions across a small fleet.
- Explain changes to clients.
This is where the private preview matters. The goal is to work with real agency workflows before broad launch, not to ship a generic dashboard and hope the use case appears.
Phase 3: Add SaaS control-plane value
Aura Pro/Agency is where the paid layer belongs.
Not because the plugin is crippled, but because fleet operations need infrastructure outside WordPress:
- Scheduling.
- Team permissions.
- Reports.
- Provider integrations.
- Backup and vulnerability context.
- Action history across sites.
- Support and incident workflows.
- MCP / AI-agent tools for operators.
Those are SaaS problems. They are not things a free WordPress plugin should try to own alone.
Phase 4: Expand provider operations carefully
Aura is not only about WordPress internals.
Client site operations often touch hosting, DNS, CDN, SSL, cache, and deployment workflows. The provider layer should expand from real user demand: which providers agencies already use, which actions are repeated often, and which integrations reduce support time without increasing risk.
That is why we talk about an operations layer rather than a replacement host.
What we are avoiding
There are a few traps we want to avoid during launch:
- Claiming broad provider support before availability is clear.
- Framing WordPress core as casual bulk rollout.
- Treating AI-agent access as a gimmick instead of an operator tool.
- Making SiteAgent feel like a paywall wrapper.
- Publishing thin SEO content that does not match the product.
The launch will be stronger if the content, pricing, plugin positioning, and product behavior all tell the same story.
What comes next
The next content and product work should keep reinforcing the same arc:
- Free SiteAgent visibility.
- Safer WordPress agency operations.
- Paid SaaS workflows for teams and fleets.
- Provider operations where they reduce real agency overhead.
If you are an agency operator and this sounds painfully familiar, join the Aura private preview. We are building the roadmap around exactly those workflows.