Browse, enquire, buy, register, log in to their own area
Publish content, manage the pipeline, raise invoices
Decide who can see and do what, per record
Generates, deploys, upgrades and supports the app, or hands it over
Usage reporting behind the managed hosting tiers
Drafts and answers using the business's own content
Scheduled or chat-driven, through the governed tool registry
Card processing
Accounting
Email delivery
AI models, provider-swappable
Swappable action backend for 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, so nothing important ends up in a workflow tool someone has to reverse-engineer later.
The website and the business run on the same records.
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. There's no integration layer between them and no nightly sync to monitor.
One identity
A single Django user model. The website visitor is the CRM contact: the same row, in the same table.
Permissions that mean something
Object-level permissions plus contextual roles, so access is decided per record and per context rather than by static group membership.
Swappable edges
Payments, accounting, email and AI providers sit behind seams. Changing one is a configuration decision rather than 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, carrying the minimum a task needs.
Content, contacts, pipeline, documents and audit history stay in your database. There's no vendor-side copy of your business that we or anyone else queries on your behalf.
Where we sit in this picture
We're the managed provider, and that's a service relationship rather than a dependency baked into the software. We hold deploy access while we operate your deployment, and we hand that over when you want it handed over. Your application runs no licence check at startup, and there is no inbound channel through which we could reach into it.
There is one outbound path, and it's worth knowing about. A deployment can report which licensed components it has installed, for your billing records and ours. It's off unless configured, it never fires on a request or at startup, and it carries component names and versions, never business data. You schedule it, or you leave it switched off.
The libraries your app imports are licensed rather than sold, which is the one edge on this diagram that is commercial instead of technical. Keeping the application patchable and rebuildable depends on that licence staying current, or on buying it out. Page 07 sets out what that means over the life of a deployment.
Bring us your integration list.
If it's a service with an API and a business reason, the answer is usually "yes, and here's where it sits". Let's go through yours.