Businext ERP
Enterprise ERP system developed from scratch to support real operations across finance, sales, inventory, and human resources within a unified platform.
Business context
Businext originated inside a real business operation that initially relied on a legacy POS system developed in C# and running on physical servers. That system presented technological limitations, vendor dependency, and difficulties evolving toward new operational requirements. A first web version was later developed using Web2py focused on sales and inventory. Although this version still operates certain processes such as point-of-sale and stock control, its functional evolution stopped. Based on that experience, Businext ERP was created as a new platform designed to progressively replace previous systems and centralize the company's operational infrastructure.
What it solves
Businext ERP consolidates processes that were previously distributed across spreadsheets, disconnected tools, and external systems. The platform integrates financial operations, HR management, purchasing workflows, CRM, accounting, and administrative control within a domain-oriented backend architecture. This approach enables clearer business rules, operational traceability, and long-term platform evolution.
Core technologies: Python · FastAPI · React · MySQL / MariaDB · REST APIs · AWS · Linux · Nginx | Architecture: Domain boundaries · Service layer · Transactional workflows
Architectural approach
- • Domain boundaries defined for finance, inventory, HR, sales, and accounting.
- • API-first architecture that enables explicit workflows and independent module evolution.
- • Modular FastAPI backend with clear service layers for business rules.
- • Production deployment on AWS over Linux and Nginx with controlled change release.
Impact
- • Central platform for the company's administrative and financial operations.
- • Enterprise codebase with more than 125k lines under continuous evolution.
- • System designed to support critical business rules, operational consistency, and financial traceability.
Technical challenges
- • Keeping accounting and inventory rules isolated while still supporting cross-domain workflows.
- • Evolving a 200k+ LOC ERP without turning every new feature into a platform-wide regression.
- • Designing APIs and modules that match the business process instead of mirroring database tables.
Operational results
- • Reduced process fragmentation by consolidating administrative workflows in one operational model.
- • Made finance, sales, inventory, and HR changes easier to reason about through explicit service boundaries.
- • Created a maintainable internal ERP foundation that can absorb new modules without reworking the whole platform.