The Composable-vs-Suite Trade-Off Does Not Have to Be a Trade-Off
Best-of-breed composability gives you maximum choice and a permanent integration burden — multiple vendor upgrade cycles, custom glue code, re-testing on every API change. A monolithic suite removes the integration burden and locks you into one roadmap for every capability. Most platforms sit firmly on one side of that line. Stack9’s argument is architectural, not rhetorical.
How Stack9 Claims Both Sides
Pre-integrated by default, composable by architecture
You are not required to source and integrate a separate CMS, CDP, marketing automation tool and email platform just to get MACH-compliant architecture. Those capabilities arrive pre-integrated on one data model from day one — with the standard best-of-breed integration risk already eliminated. Because the architecture is genuinely MACH, any capability can still be selectively replaced or supplemented later through the same API-first model.
Against a legacy monolithic suite
One unified data model rather than a portfolio grown by acquisition. Fixed per-instance licensing rather than a core licence plus separately licensed modules plus certified partner costs. Evolutionary upgrades rather than periodic major-version re-platforming. Enterprise-workflow AI rather than marketing-focused AI. Standards-based portability rather than a proprietary rendering pipeline.
Against a portal-first platform
Stack9 Core models each portal’s specific data — policies, claims, employer relationships — natively as first-class business objects, not as generic portal content or custom code bolted onto a portal framework. User Groups and row-level security let one platform serve external customers, partner organisations and internal staff from one data model, rather than requiring a separate instance per audience.
Against a bespoke custom build
A custom build cannot evolve without bespoke development for every change — and it has to construct and then maintain RBAC, row-level security, audit trail, document management, email, a CDP, autoscaling infrastructure and an upgrade path from scratch. Stack9 ships those, and adds new capability by configuration.
One point of accountability
April9 is both the platform owner and the implementation and support provider. Every major DXP vendor delivers through a partner channel, which means a portal change can need a CMS team, a backend team and a separate QA team across different vendors — and a blame gap when something breaks. Structurally, that gap cannot exist here.
Australian residency, end to end
Production, metadata, logs, backups, disaster recovery, support access and AI processing all stay inside Australian AWS regions — primary in Sydney (ap-southeast-2), backups and DR in Melbourne (ap-southeast-4). A fully onshore team, no offshore support tier. Global DXP vendors rarely match the residency completeness, particularly on AI processing.
The Four Questions Worth Asking Any Vendor
How many products am I actually licensing?
Suite portfolios often grow by acquisition, leaving multiple products with varying degrees of integration — separate licences, separate upgrade cycles, and custom integration to work as one experience.
What happens at the next major version?
Ask for the mechanism, not the promise. Stack9’s is a shared data model, layered Docker images that April9 rebuilds and deploys, LTS versioning, and formal RFC change management. LTS is bounded by dependency support — it is not indefinite, and we say so.
Could I leave?
Everything is exposed via REST and OpenAPI and secured with API keys or OpenID Connect. Every entity you define automatically produces standard REST resources. The answer to lock-in is not “trust us” — it is a standards-based reason you could leave.
Where does the AI run, and on what?
Most DXP AI is content and marketing AI. Stack9 AI Agents runs on Amazon Bedrock AgentCore and reaches CRM, ERP, finance and HR under the same governance, authentication and audit controls as any other enterprise workflow — with processing in the Sydney region.
Where Stack9 Sits
The axis is usually presented as a choice. It does not have to be.
We Do Not Claim More Features Than the Market Leaders
They have more CMS-specific features, and a feature-parity fight is neither winnable nor necessary. Stack9’s case is architectural, commercial, operational and jurisdictional — one platform to operate, licensing that does not scale with adoption, evolutionary upgrades, and a vendor you can meet in your own timezone.