Flagship system
No-Code Enterprise ERP
Enterprise · Metadata-Driven Architecture
A metadata-driven enterprise operating system where organisations define their own data models, workflows and business logic through configuration rather than code — entities and rules stored as metadata and interpreted at runtime.
- 7
- Technologies
- 1
- Domain
- 7
- Capabilities
- 1
- Public links
Who it's for
Organisations that outgrow spreadsheets but can't afford a development team for every process change — operations, finance and admin teams who want to shape their own tools.
Where it fits
Internal business platforms in the space of Odoo/Salesforce: custom entities, approval chains, SLAs and accounting assembled through configuration, not code.
The hard part
The problem
Every business wants its ERP shaped to its own processes, but bespoke modules mean a code deployment for every change. The platform had to let administrators assemble and change business applications without waiting on a developer.
Key constraints
New modules had to be created through configuration rather than schema migration and redeployment. Tenant data had to be genuinely isolated, and the whole system needed a complete, trustworthy audit trail — including the ability to reconstruct any record as it was at a past point in time.
Architecture overview
Entities, fields, relationships and validation rules are stored as metadata and interpreted at runtime. State changes are captured as an immutable event stream, so current state is a projection that can be replayed to any point in time. A business-rules engine lets administrators author conditional logic, triggers, computed fields and automation without developer involvement.
Command → event → projection
replay events → reconstruct any point in time
How it works
What's actually in it.
- 01Metadata-driven model layer: entities, fields, relationships and rules defined as metadata, interpreted at runtime.
- 02Event-sourced architecture with immutable event stream, full audit history and point-in-time reconstruction.
- 03Business-rules engine: conditional logic, triggers, computed fields and process automation authored by administrators.
- 04Multi-tenant isolation via PostgreSQL Row-Level Security — enforced at the database layer, not in application code.
- 05Approval matrix and SLA engine with configurable multi-stage chains and automated escalation on breach.
- 06Genuine double-entry accounting ledger underpinning the financial modules.
- 07Webhook and API builders, plus an external portal builder with per-tenant white-labelling.
Engineering decisions
Event sourcing as the system of record
Instead of storing only the latest row and overwriting it, every change is recorded as an immutable event; current state is derived by folding those events. That gives complete audit history and point-in-time reconstruction for free — essential for financial and approval workflows where 'what did this look like last quarter?' is a real question.
The trade-off
Event sourcing is more complex than CRUD — you maintain projections and think in events rather than rows. In exchange you get an audit trail that cannot be quietly edited and the ability to reconstruct any record's history exactly.
The obvious approach
Model each ERP module as normal database tables and add an audit-log table alongside.
Why I didn't choose it
A separate audit log can drift from the real data, be bypassed, or fail to capture intent — and it can't reconstruct a record's exact past state.
My approach
Make the event stream the source of truth so audit history and point-in-time reconstruction are inherent, not bolted on, and enforce tenant isolation in the database with Row-Level Security.
Trade-offs
Projections and event versioning to maintain, in exchange for an audit trail and replay you can actually trust.
Technical highlights
- New business modules created through configuration, without a code deployment.
- Row-Level Security removes an entire class of cross-tenant data-leak risk.
- Double-entry ledger keeps balanced books across all transactional activity.
Claims & evidence
Tenant separation is enforced at the database layer via PostgreSQL Row-Level Security rather than in application code.
Qualitative · No-Code ERP architecture
Every statement above carries its evidence class — nothing is invented.
Tech stack
- Python
- Django REST Framework
- Next.js 14
- TypeScript
- PostgreSQL (Row-Level Security)
- Redis
- Celery
Want to go deeper on No-Code Enterprise ERP?
I'm happy to walk through the architecture and the decisions behind it.