What this is for#
Knowing what's coming next in AcelleMail helps you plan: whether to wait for a feature vs build a custom extension; when to upgrade vs hold; how to align your stack roadmap with the product's direction.
This article is intentionally evergreen — rather than promise specific Q1/Q2/Q3 features (which would drift out of date the moment a release ships differently than expected), it explains:
- Where AcelleMail's roadmap actually lives (it's not a single public document)
- The observed direction based on recent release patterns
- How to influence priorities as an operator
- How to plan your own work around the roadmap's uncertainty
For "what's already in my install", see What's New in AcelleMail. For announcement-style updates, this is the right article.
Where the roadmap lives#
AcelleMail doesn't publish a single "roadmap.md" file. The signals come from multiple places:
1. CodeCanyon changelog (the strongest signal — historical)#
- Your CodeCanyon Item page → Changelog tab
- Reading the last 6 months of patch notes shows what the team has been investing in
- Trends in titles ("Improved SES bounce handling", "New automation merge tag types", "Refactored admin UI") reveal direction
- This is HISTORICAL — not "what's coming" — but it's the most reliable predictor
2. CodeCanyon Item description#
- Listed features get added when shipped
- "Upcoming" features sometimes appear in the description as previews
- Re-read every few months for changes
3. AcelleMail newsletter / blog (if subscribed)#
- Periodic emails to license holders highlighting upcoming work
- Less reliable than CodeCanyon (sometimes promises shift)
- Still useful for early signals
4. Direct contact with the dev team#
- The strongest signal — but requires you to build a relationship
- Engaged operators (those who file thoughtful bug reports, suggest features that get shipped) get more roadmap visibility over time
- See Contributing to AcelleMail Development
5. The codebase itself#
- For technical operators: looking at
app/Console/Commands/ and recent migrations sometimes hints at not-yet-exposed features
- E.g. a new
ads_* table without a corresponding admin UI = there's an Ads feature in development
- Take with a grain of salt — not every WIP feature ships
Observed direction (as of mid-2026)#
Based on 12-18 months of release-note patterns + community discussion, the platform has been investing in:
Deliverability tooling#
- Better SES integration — refined sending-server config, automatic SNS topic setup, FBL handling
- Reputation monitoring — built-in dashboards for Gmail Postmaster + Microsoft SNDS metrics
- Multi-server rotation — patterns for spreading sends across multiple sending IPs/servers automatically
- Bounce / complaint workflows — finer-grained classification + auto-suppress rules
If you're a high-volume sender, expect ongoing improvements in this area.
Automation depth#
- More conditional logic — multi-branch evaluation, complex tag/field conditions
- API trigger refinements — better security + payload flexibility
- Webhook actions inside flows — fire arbitrary HTTP requests at any point in an automation
- A/B testing within automations — branch on send-time experiments
SaaS operator features#
- Cashier consolidation — Stripe-only as first-class (already happened); deeper Stripe integration coming
- Per-customer custom tracking domain — auto-TLS via Let's Encrypt (in progress / stable depending on version)
- Sub-account hierarchies — Agency tier with sub-customer management (in progress)
- Per-plan rate-limit primitives (already shipped — see the
plan_rate_limits table)
Admin UI polish#
- The
Refactor/Admin/* controller namespace contains rebuilds of older admin screens
- Each minor release moves more screens into the new style
- Eventually the old
Admin/* controllers get retired
Integrations + extensibility#
- Plugin system — formalising the extension API so third parties can ship modules
- Email-verification service integration — built-in pre-send verification
- Multi-channel — speculation about SMS additions, but not yet committed
What's not on the public roadmap (don't expect)#
- Self-hosted SaaS marketplace ("Mailchimp App Marketplace clone") — not in scope
- Built-in CRM / contact management beyond what AcelleMail already has (list segmentation + tags) — Acelle is staying focused on email
- Real-time chat / live messaging — not the platform's focus
- A free open-source community fork — AcelleMail's business model is the CodeCanyon licence
How to influence the roadmap#
The dev team listens to engaged operators. The pattern that works:
- File specific feature requests via CodeCanyon support, not vague "would be nice"
- Frame as a customer problem, not a feature: "When my customer X needs to do Y, the only way today is Z, which causes problem W"
- Quantify impact: "This blocks ~$N of customer-deal MRR for us"
- Offer to be a beta tester for the eventual feature
- Don't repeat-request the same thing every month — once is heard; ten times is noise
Patterns that get prioritised:
- Bug fixes with clean reproductions
- Compliance-blocking features (e.g. specific GDPR requirements)
- Features that unlock a new market segment for AcelleMail (cited by multiple operators)
Patterns that don't:
- "I want this for me personally" (single-operator asks rarely move the needle)
- Theoretical asks not tied to actual customer problems
- Speculative architecture changes ("you should rewrite in Rust")
Planning your work around the roadmap#
The 4 strategies for an operator-facing roadmap:
| Strategy |
When to use |
| Wait |
The feature is on the roadmap + you can predict ETA + your alternative is "do nothing" |
| Build a custom extension |
You need it now + the feature might never ship as you need it + it's worth the maintenance burden |
| Integrate a third-party tool |
The feature is outside AcelleMail's scope (CRM, analytics, etc.) + a mature alternative exists |
| Switch platforms |
The feature is critical to your business + AcelleMail's direction doesn't align long-term |
The right answer for most features is "wait + workaround in the meantime". Most features ship within 6-12 months of being seriously requested.
For features you build as extensions: see Extending AcelleMail Source Code for the upgrade-safe pattern. The faster a feature ships natively, the more your custom work becomes maintenance debt — be ready to deprecate your extension once the native version arrives.
FAQ#
Why no public roadmap document? Different products take different approaches. Acelle's team prioritises shipping over publishing roadmaps (which often promise things that change). The CodeCanyon changelog is the closest proxy + is regularly updated.
Can I see what other operators are requesting? Not publicly. CodeCanyon support tickets are private. Community channels (Discord/Slack if available) sometimes surface common requests.
How honest is the team about not-shipping things? Mixed historical record. Some announced features arrive on time; others shift quarters. The CodeCanyon changelog is the source of truth for what's actually shipped — speculative promises elsewhere may slip.
Should I plan my year around a specific roadmap item? Only if you've gotten a direct confirmation from the dev team that it's committed for a specific release. Speculation from blog posts / forum threads isn't enough to bet on.
Is there an LTS (long-term support) version? Not formally announced. AcelleMail supports patches across multiple major versions, but no "5.x LTS" branch.
What about end-of-life for old major versions? Generally, AcelleMail patches the most recent 2 major versions. If you're on 4.x and 5.x + 6.x are out, you should plan to upgrade.
Related articles#
