A worked example — our own deployment.
Pure Creative runs on Pure Stack. These are the slots we kept and the ones we replaced, and it's the same mechanism a client deployment uses.
| Abstract base — in the shared core | Concrete model — in your app | 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, upgrades arrive for free | Default |
What's fixed, and what's yours
- 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 settings — which capabilities are on, named your way
- Your data, your content, your infrastructure
- Yours to change, and yours to keep if you ever leave
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, and it's the part of this architecture that takes the most care — we'd rather you hear that from us than discover it at upgrade time.
What you get for it is the thing no template and no SaaS platform can offer: your data model actually matches your business, and you're still on a maintained core rather than a fork that stops receiving improvements the day it's created.
The alternative most agencies offer is a fork — a copy of the platform made yours by editing it. That works until the first upgrade, and then it doesn't. This is the mechanism that avoids it.
Why it matters for lock-in
No fork means upgrades keep arriving
Your customisations sit in your own app, 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 — not tribal knowledge held by whoever built it.
Handover is a real option
Because your app is generated and documented the same way every deployment is, another competent Django team can pick it up. That's the test of "no lock-in" that matters.
Bring us your data model.
The most useful discovery conversations start with the way your business actually shapes its records. We'll show you which slots that touches.