Container view — for technical buyers

Inside one Pure Stack deployment.

Every box below is a Django app or a service, running as a single application on a single PostgreSQL database you own. This is drawn from the apps actually installed in our own production deployment — not from an intended design.

Custom apps
AI & integrations
Payments & accounting
Pure CRM
Pure CMS
Server

Six layers, one application

Each platform is built from real components. Hover or tap a layer to see what's inside — all on one database you own.

ServerCMSCRMPaymentsAICustom apps

Status is marked honestly throughout. Live means running in our production deployment. Built means the code exists with test coverage but isn't wired to a live broker or transport yet. Planned means designed and not built.

Your application Django + Wagtail · one codebase · generated from the shared core, owned by you

Content — Pure CMS

Wagtail
Pages & content Live

Typed structured blocks — content as data, not HTML

pages · block_utils
Blog & calendar Live

Posts, events, scheduling

blog · cms_calendar
Mailing lists Live

Site sign-up audiences

cms_mailing_list
Themes Live

Swappable look, no core edits

theme apps
Context Store Live

Your brand voice and business facts, for grounding AI

context_store
AI-aware blocks Built

In-editor drafting with business context

streamfield_ai · wagtail_ai
wagtail_ai is live in the editor; the context-injecting block layer is in active development

Business — Pure CRM

swappable abstract models
Contacts & pipeline Live

Contact, Opportunity, Organisation, sale stages

models · pipelines
Payments Live

Take card payments

crm_payments · pinpayments
Billing & subscriptions Live

Agreements, plans, seats, licences

crm_billing
Accounting Live

Invoices and ledger, synced to Xero

crm_accounting · xero
Marketing Live

Campaigns from the same contacts

crm_marketing · mailchimp
Registrations & access Live

Invitations, member areas, cases

context_invitations · crm_legal
Reporting Live

Business reporting and policy rules

crm_reporting · crm_policies
Interactive UI Live

Server-rendered components, no separate front-end app to maintain

htmx · crm_components

AI — Pure Creative AI

the pure_ai suite
Agent runtime Live

Runner loop, tool registry, approval gating, run log

pure_ai
CMS & CRM tools Live

Governed actions over content and records

pure_cms_ai · pure_crm_ai
Model providers Live

Swap the AI model, keep everything else

pure_ai_anthropic · pure_ai_openai
Access boundary Live

Deny-by-default, tokenised, audited egress to agents

agent_access · token_vault
Async & external transports Built

Background tasks, MCP server, external orchestration client

tasks · mcp_server · n8n
built with test coverage; not yet wired to a live broker/transport
Content Editor agent Built

Drafts pages and sections into review, never publishing itself

content-editor · cms tools
agent definition, persona and block-level content tools exist; the headless trigger that lets it run on a schedule doesn't yet

Identity & foundation

one user, beneath every layer
One identity Live

A single Django user — the website visitor is the CRM contact

users · Contact.user
Object permissions Live

Access down to the individual record

guardian
Contextual roles Live

Role depends on context, not fixed group membership

django_proximity_roles
Shared utilities Live

Status models, the agent-access contract

pure_django
One PostgreSQL database

Content, business data and identity in one owned store — no SaaS silos, no cross-system sync to reconcile.

This single shared database is what lets an AI assistant see the whole business at once — and what lets you walk away with all of it.

The three rules underneath

Why it stays maintainable across many clients.

Content is structured, never HTML

Every page is typed, addressable blocks. That's what makes content reusable across channels, queryable alongside business data, and legible to an AI assistant.

Business models are abstract with working defaults

Every CRM model ships as an abstract base with a concrete default you can swap. One core serves very different businesses without a fork per client.

Client projects never edit library source

Customisation happens through model swaps and settings. If something can't be expressed that way, the library needs a new extension point — not a fork.

Want to see it running?

We'll walk you through the real admin, the real data model and the audit log — including the parts still in progress.