Building a Lightweight ERP Core with Clean Architecture (Lessons Learned)
Most ERP systems fail SMEs not because they lack features,
but because they are too heavy, too coupled, and too expensive to maintain.
When we started building LiteERP, the goal was simple:
Can we design an ERP core that stays small, predictable, and extensible — even as the system grows?
This article shares some architectural decisions and trade-offs we made while building a lightweight ERP core using Clean Architecture.
The core problem with most ERP systems
From our experience, traditional ERP systems usually suffer from:
Business logic tightly coupled to frameworks
Plugins that directly modify core behavior
Growing dependency graphs that are hard to reason about
High infrastructure requirements for small teams
The result:
👉 SMEs pay enterprise-level complexity for simple workflows.
We wanted a different outcome.
Clean Architecture as a constraint, not a buzzword
Clean Architecture is often misunderstood as “just more layers”.
In LiteERP, it is treated as a hard constraint:
Domain does not know Infrastructure
Core business rules do not depend on frameworks
Modules communicate through explicit contracts
Side effects are pushed to the edge
This constraint forces discipline, but it gives us something very valuable:
The ability to change implementation details without breaking business logic.
Designing an ERP core that loads only what it needs
One key rule we adopted early:
The ERP core must not load modules it does not need.
Instead of auto-loading everything, LiteERP:
Resolves modules based on explicit support declarations
Loads only the hooks required for the current request
Avoids global service registration for unused modules
This drastically reduces:
Memory usage
Boot time
Cognitive overhead when debugging
For SMEs, this means:
Lower server costs
Predictable performance
Easier scaling decisions
Extension system: hooks, not plugins
Most ERP plugins work like this:
Override core classes
Inject logic everywhere
Break silently after updates
We avoided that entirely.
LiteERP uses a hook-based extension system:
Extensions declare what they support
Hooks are executed at specific lifecycle phases
Core rules remain non-negotiable
This gives extension developers freedom without compromising system integrity.
In practice:
Core stays stable
Extensions remain optional
Updates don’t become a nightmare
Why we avoided “feature-first” development
One temptation in ERP development is adding features early to appear “complete”.
We resisted that.
Instead, we focused on:
Correct boundaries
Clear ownership of data
Strong domain events
Full business activity logs
Why?
Because:
Features can be added later.
Broken architecture compounds forever.
Trade-offs we accepted
This approach is not free.
We knowingly accepted:
Slower early feature delivery
More upfront design work
Stricter rules for contributors
But in return, we gained:
Long-term maintainability
Easier onboarding for developers
A system that scales in complexity, not chaos
Final thoughts
LiteERP is not trying to compete with enterprise ERP systems.
It is designed for:
Small and medium businesses
Teams that value clarity over complexity
Developers who care about architecture
If you believe ERP systems can be lighter, cleaner, and more honest,
you might find this project interesting.
The project is open-source and currently preparing for Beta:
👉 https://github.com/liteerp-oss/liteerp
Top comments (0)