System context — for technical buyers

Who and what touches your deployment.

One deployment sits at the centre: the people who use it, the AI agents that act on it through a governed boundary, the outside services it calls, and us as the managed provider. Your data stays in your database — only what a task needs crosses a line.

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
Your Pure Stack app Website + CRM + billing as one application you own
ContentCustomersBillingAI agents
one owned PostgreSQL database
People
Visitors & customers Live

Browse, enquire, buy, register, log in to their own area

→ read the site · become a contact · pay
Staff & editors Live

Publish content, manage the pipeline, raise invoices

→ edit content · work records
Administrators Live

Decide who can see and do what, per record

→ set permissions & roles
Managed provider
Pure Creative Live

Generates, deploys, upgrades and supports the app — or hands over the keys

→ deploy · upgrade
Licence & SLA reporting Planned

Usage reporting behind the managed hosting tiers

→ planned — not built
AI agents — through a governed boundary
In-editor assistant Live

Drafts and answers using the business's own content

→ reads context · proposes drafts
Headless & external agents Built

Scheduled or chat-driven, through the governed tool registry

→ act only within the boundary
Runtime and tool registry are built; the Celery/MCP/n8n transports aren't wired to a live broker yet.
External services
Pin Payments Live

Card processing

→ charge cards
Xero Live

Accounting

→ sync invoices
Mailchimp Live

Email delivery

→ send campaigns
Anthropic · OpenAI Live

AI models — provider-swappable

→ generate, on request
n8n Built

Swappable action backend for external orchestration

→ external orchestration

One rule governs every edge — Django owns state, permissions and anything generated into your app; outside services handle third-party I/O only. Nothing important lives in a workflow tool you'd have to reverse-engineer later.

What this buys you

No integration layer between "the website side" and "the business side".

There is no side. Because CMS and CRM are one Django application on one database, the join between a page visit and a customer record is a foreign key, not a nightly sync you have to monitor.

One identity

Live

A single Django user model. The website visitor is the CRM contact — the same row, not two systems agreeing to disagree.

Permissions that mean something

Live

Object-level permissions plus contextual roles, so access is decided per record and per context rather than by static group membership.

Swappable edges

Live

Payments, accounting, email and AI providers sit behind seams. Changing one is a configuration decision, not a re-platform.

What actually leaves the boundary

Card details go to the payment processor, invoices go to accounting, campaigns go to the email provider, and prompts go to whichever AI model provider is configured. Each is a deliberate call, made by your application, with the minimum a task needs.

Everything else — content, contacts, pipeline, documents, audit history — stays in your database. There is no vendor-side copy of your business that we or anyone else queries on your behalf.

Bring us your integration list.

If it's a service with an API and a business reason, the honest answer is usually "yes, and here's where it sits". Let's go through yours.