A worked example, our own deployment.
Pure Creative runs on Pure Stack. These are the slots we kept and the ones we replaced, using the same mechanism a client deployment uses.
| Abstract base · in the licensed core | Concrete model · in your project | State | ||
|---|---|---|---|---|
| Contact | pure_crm · abstract | Your Contact | adds ABN / ACN / TFN and local address fields | Custom |
| Sale stage | pure_crm · abstract | Your sale stages | pipeline stages named for this business | Custom |
| Staff | pure_crm · abstract | Your Staff | roles and attributes for this team | Custom |
| Policies | pure_crm · abstract | Your Policies | this business's compliance rules | Custom |
| Opportunity · Organisation · Invoice · Case | pure_crm · abstract | Library defaults | standard here; kept as-is, so upgrades arrive automatically | Default |
Where the line sits
- The abstract models, their behaviour and their relationships
- The CMS, permissions, payments and deployment machinery
- The extension points and settings that make swapping safe
- Maintained and upgraded centrally, for every client at once
- Your concrete models: the slots you chose to customise
- Your custom apps and your theme
- Your settings: which capabilities are on, named your way
- Your data, your content, your infrastructure
Customisation happens through model swaps and settings, never by editing library source. That's what lets one maintained core serve very different businesses, and what lets you accept upgrades without losing your changes.
What this approach costs.
A swapped model is a real commitment. Your data lives in your table, and when the abstract base beneath it changes, that change has to be migrated in your deployment. It's a coordinated step, it's the part of this architecture that takes the most care, and we'd rather you heard it from us than discovered it at upgrade time.
What you get for it is a data model that matches your business while still sitting on a maintained core, rather than a fork that stops receiving improvements the day it's created.
The alternative most agencies offer is that fork: a copy of the platform made yours by editing it. It works until the first upgrade. This is the mechanism that avoids it.
What this means if you ever want to move.
No fork means upgrades keep arriving
Your customisations sit in your own project, in slots the core knows about. The core beneath them can move forward without stepping on them.
Configuration is legible
Which capabilities are on, and which models you replaced, is a short readable list rather than tribal knowledge held by whoever built it.
Handover is available, on a licence
Your project is generated and documented the way every Pure Stack deployment is, so another competent Django team can take it on. Because the core is licensed rather than sold, that team takes a Pure Stack licence of its own, or you buy the platform outright first. The engineering is straightforward. The licensing is a conversation, and we'd rather have it early.
Being exact about the licence
Pure Creative owns Pure Stack, Pure CMS, Pure CRM, the AI suite and the generator. Your deployment licenses them. Your own concrete models, custom apps, theme, settings, content and data belong to you, and we hand all of it over on request.
Three routes keep an application maintainable after you leave the managed service. Continue a subscription, pay annual maintenance, or buy the platform out, which makes your licence perpetual. Any of them can be quoted before you commit to the build, and we'd encourage you to ask at that point instead of at the end.
Moving off Pure Stack altogether is a different and much larger project, because it means replacing the libraries the application is built on. Your data comes out cleanly from one database. The application does not come apart cheaply, and no architecture would make it do so.
Bring us your data model.
The most useful discovery conversations start with the way your business shapes its records. We'll show you which slots that touches, and what the licence looks like alongside it.