A Rapid Application Platform and a DXP, on One Data Model
Most vendors sell you an application platform or an experience platform, and leave the integration between them as your problem. Stack9 Core and Stack9 Experience are two components of one system sharing one backend API layer, one data model and one permission model. This is the single most important architectural fact about Stack9 — nearly every other advantage follows from it.
What Follows From One Data Model
Two layers, one API
Stack9 Core deals in domain entities, workflow, automation, permissions and integrations. Stack9 Experience deals in content, pages, media, forms, email, campaigns and customer profiles. Both connect to the same shared backend API layer — so data is accessed through one common layer, not synced between disconnected systems.
No vendor boundary in the middle
There is no third-party vendor boundary between the application layer and the experience layer, no separate licence or contract, and no client-side integration work to make the two talk. CMS, marketing automation, CDP, email and AI are native capabilities of one system.
One permission model, not two
Role-based access control is enforced consistently across Core and Experience because there is one permission model. A user group, a row-level rule or a delegated administrator behaves the same way whichever layer the request came through.
Activation on transactional data, not just marketing data
In an assembled stack the CDP and the transactional business data live in separate products with their own refresh cadence and integration risk. In Stack9 they share one data model — which is what real-time activation across the whole experience actually requires.
New capability extends the model
Adding capability means extending the data model rather than bolting on another system to integrate — so glue code and sync logic do not accumulate. That accumulation is the most common cause of eventual forced re-platforming.
Genuinely MACH, not MACH in name only
Microservices with their own API surfaces, API-first via 100+ documented REST endpoints described with OpenAPI 3.0, cloud-native containerised AWS services throughout, and a fully decoupled headless front end. Because each capability is a discrete service, you keep the option to run a best-of-breed alternative alongside Stack9 for any given workload — that choice is optional, not mandatory.
The Topology
Your front ends
Web App Templates — portals, websites and intranets in standard HTML, JavaScript and CSS, one per portal or brand, fully decoupled from the back end.
One shared backend API layer
A single data model and a single permission model, exposed as REST described with OpenAPI and secured with API keys or OpenID Connect. No proprietary protocol.
Core and Experience side by side
Core runs as a dedicated Docker image per client at its own hostname — per-client isolation with a common upgrade path. Experience runs as the shared content, marketing, email and CDP layer.
Your systems of record, behind Connectors
Claims, policy, CRM, ERP, finance, identity and document management register as Connectors, consolidated where possible through AWS API Gateway — so your entities interact with one governed interface rather than a sprawl of point-to-point integrations.
One Platform, Drawn Out
Where the application layer ends, the experience layer begins, and why it does not matter.
Configurable Platform, Not a Package and Not a One-Off Build
Entities are defined once and Stack9 generates the structures, APIs and screens. Power users configure on top through Stack9 Console. Where genuinely new front-end functionality is needed, developers build it once — after which it becomes a building block configurators reuse without further code changes.