Your source code, vendor specs, configs, customisations and real data are intellectual property. When they live inside another vendor's system, you don't own them — you lease access to them, and the price of leaving goes up every year. This is the case for holding what evolves in Git/GitHub, knowing when Microsoft 365 / SharePoint is still the right home, and how an owned record-and-data layer (ERPNext, Postgres, Apache Superset) becomes the foundation that makes AI agents and MCP servers actually possible.
Most organisations never decide to lock themselves in. It happens by default. A vendor builds your customisations inside their platform, your configs live in their admin console, your specs sit in a SharePoint folder, and your data is exportable only on their terms. Each choice is reasonable on its own. Together they mean the cost of switching — or just auditing what you actually have — quietly becomes prohibitive.
The day you want to change vendors, re-tender a contract, or simply prove to an auditor what your system does, you discover the answer lives inside a platform you don't control — and the only person who can extract it is the vendor you're trying to leave. Ownership isn't a feeling; it's whether you can walk away with everything that matters.
Git is not a backup, and GitHub is not just "where developers put code". Git is a system for owning anything that changes over time and needs to be diffable, reviewable, attributable and portable — source code, yes, but equally your vendor specs, environment configs, customisation scripts, infra definitions and the HTML deliverables you paid to have built.
Six things you get the moment an asset lives in a Git repository you control:
git clone and the entire history moves — to a new host, a new vendor, an offline mirror. Switching becomes a migration with a plan, not a crisis.True — and it doesn't undercut the point. The thing that makes Git different from a vendor silo is that GitHub is a host for a format you fully control, not a proprietary container. Your repository is a complete, self-contained copy that lives on every machine that clones it. If GitHub vanished tomorrow you'd git push to GitLab, Gitea, Bitbucket, or a box in your own server room and lose nothing but a URL. That portability is the ownership. The host is replaceable; the asset is yours.
Once you accept that owning what matters is the goal, the same logic reaches your operational data. ERPNext is a 100% open-source ERP built on the Frappe Framework — accounting, inventory, sales, purchasing, manufacturing, HR and more — that you can self-host, customise without forking, and keep your data inside. No per-user licence, no vendor holding the keys to your own records.
ERPNext was created by Frappe Technologies (Rushabh Mehta) and open-sourced in 2010. It ships 30+ modules, is used by organisations across roughly 150 countries, and is licensed GPLv3 — genuinely free to self-host with no per-seat fee. The current line is ERPNext v16, released January 2026, built on the Frappe "Caffeine" performance release, with a redesigned UI, Phantom BOMs and reworked payroll.
The architectural detail that makes it ownable is the DocType. Every entity in ERPNext — an invoice, a customer, a custom workflow — is a metadata-defined DocType. You customise by adding fields, DocTypes and scripts as metadata, not by editing core. That means you can shape the system to your business and still take clean upgrades, and your customisations are exportable artefacts you can hold in Git.
100% open source. No per-user licensing. Run it on your own infrastructure and the data stays yours.
Metadata-driven. Extend with custom fields and scripts without touching core — upgrades stay clean.
Accounting, inventory, sales, buying, manufacturing, projects, HR & payroll. One system of record.
Self-host for full control, or Frappe Cloud from roughly $50/month if you'd rather not run the box.
SAP, Oracle and NetSuite charge per named user, per module, and often per integration — costs that scale with your headcount and your success. ERPNext removes the licence line entirely; your spend is infrastructure plus the implementation effort. For a growing SA mid-market organisation, that's frequently the difference between an ERP being affordable and being a permanent six-figure tax. Be honest about the trade: you take on hosting and maintenance responsibility. Owned doesn't mean free of effort — it means free of the licence lock and the data hostage.
Business intelligence used to require six-figure licences and a specialist team. That floor has collapsed. PostgreSQL — the most capable open-source database in production — is a perfectly good analytics warehouse for most organisations, and Apache Superset gives you the dashboard, chart and SQL-exploration layer on top, open source, on cheap infrastructure.
Open-source, battle-tested, SQL-standard. Holds your consolidated operational and analytical data on infrastructure you control.
Open-source exploration and dashboarding. Connects straight to Postgres; charts, dashboards and a SQL Lab for analysts.
Capability that once needed Tableau/Power BI seats and a warehouse appliance — now open source, on a modest VM.
The pattern is straightforward: operational data lands in or replicates to Postgres, Superset points at it, and analysts build dashboards without anyone buying a per-seat BI licence. Because both layers are open source and self-hosted, the data never leaves systems you own — which matters for cost, and matters more when AI agents need to read that data later.
Postgres-as-warehouse is right for the small-to-mid analytical volumes most organisations actually have. It is not a petabyte-scale columnar engine — if you genuinely reach that scale, a dedicated warehouse (or a columnar extension) earns its place. And "free software" still costs operational effort: someone runs the database, manages backups, and keeps Superset patched. The win isn't zero cost; it's owned capability at a fraction of the proprietary licence floor. Note: ERPNext's own stack runs on MariaDB/Postgres; the brief here is the dedicated analytical warehouse beside it, not a replacement for the transactional DB.
This is the payoff. Everything above — code in Git, records in ERPNext, data in Postgres — shares one property: it lives in systems you own and can reach programmatically. That is precisely the precondition for useful, safe AI. Agents, agent workflows, internal tools and MCP servers all need to read and act on your systems through clean, governed interfaces. An owned, reachable stack gives them that surface; a vendor silo does not.
An MCP server in front of your own Postgres and ERPNext can enforce exactly which data an agent reads and which actions it may take — with the audit trail living in systems you control. You cannot wrap that governance around a vendor's black-box silo whose only interface is a UI and a throttled export. The open, owned stack is what makes agentic AI both possible and safe. AI coding tools (Copilot, Claude Code) then build and maintain the harness on top — which is itself code, which itself lives in Git. The loop closes.
Honest, not dogmatic. The point was never "everything into Git". It's that IP-bearing source and config belong in version control, and finished office artefacts belong where collaboration is easy. Here's the two-sided rule of thumb.
For SA organisations, owning the stack also eases POPIA and data-residency conversations: when records sit in your own Postgres and ERPNext on infrastructure you choose, "where does our data live and who can reach it?" has a concrete answer instead of a vendor's terms-of-service. Keep it proportionate — this is a benefit of the approach, not the reason for it.
Official project sites and documentation only. Content validated June 2026 — ERPNext v16 (released January 2026), Frappe Framework, PostgreSQL, Apache Superset, and the Model Context Protocol.