One ERP core, eleven business types
A modular Laravel and Angular platform that turns POS, inventory, accounting, manufacturing, and HR modules on or off per business type — from a single shared codebase.
Client Type
Product-led ERP platform for retail, wholesale, manufacturing, and factory businesses across eleven configurable business types.
Project Type
Modular, API-first ERP platform (Laravel backend, Angular frontend)
Timeline
Ongoing active development — Core Platform through System Administration are functionally built; queue-driven automation, receipt printing, and a public storefront endpoint remain on the roadmap.
Our Role
Product architecture, full-stack engineering across the Laravel API and Angular frontend, and design of the shared component library reused by every module.
Executive Summary
CxBusiness ERP is a modular enterprise resource planning platform built on Laravel 12 and Angular, designed to run retail, wholesale, and manufacturing businesses from one shared codebase rather than a separate build per business type.
Instead of maintaining a different product for a clothing store, a super shop, a garment factory, and eight other business types, the platform turns entire modules on or off through configuration and role-based permissions — POS and ecommerce for a retail store, manufacturing and quality control for a factory, all backed by the same accounting and inventory core.
The build is organized around a small number of load-bearing architectural decisions applied consistently everywhere: every stock and financial number derives from an append-only ledger rather than an editable field, every access check considers both the user's specific permission and the organization's enabled modules, and a single shared component library — not per-module custom UI — powers every list, form, and table in the system.
Challenge & Solution
The Challenge
Retail, wholesale, and manufacturing businesses each run on genuinely different workflows — a cashier's checkout, a purchasing manager's approval chain, a production supervisor's bill of materials — but building a separate system for each business type multiplies cost and maintenance burden with every new customer type. Off-the-shelf ERPs either force every business through the same generic screens or require expensive per-customer customization, and few tie POS, inventory, and accounting together tightly enough that the books stay accurate without a manual reconciliation pass.
The Solution
CxBusiness ERP is one Laravel API and Angular frontend where business modules — POS, manufacturing, HR, CMS, and more — are enabled or disabled per business type through configuration, not code forks. Every module that touches stock or money posts through the same two central ledgers, so a sale, a purchase, a payroll run, and a production order all update the same source of truth. Role-based access is scoped both to what a specific permission allows and to which modules the organization's business type has enabled, so a Grocery Shop Manager and a Garment Factory Manager log into the same platform and see two genuinely different systems.
Product Goals
Run eleven distinct business types on one platform, configured per business rather than forked per customer.
Make every financial and inventory number provably correct by deriving it from an immutable ledger, never an editable balance field.
Give each business-vertical role exactly the modules and permissions it needs, out of the box, without manual setup per customer.
Build a shared UI component library strong enough that every new module ships faster than the last, not slower.
Discovery, Design & Development
Discovery
The starting point was recognizing that most ERP failures aren't missing features — they're the wrong shape of tool for a given business. A cashier at a super shop, a purchasing manager approving a supplier order, and a production supervisor tracking a bill of materials all need fundamentally different daily workflows. Rather than build one generic admin screen and hope it fits everyone, each module's required, optional, or not-applicable status was mapped against every one of the eleven supported business types up front, so a module's permission set and UI could be built once and reused correctly everywhere it actually applied — never forced onto a business type it wasn't built for.
UX Strategy
Every screen is built around the task a specific role needs to finish, not a one-size-fits-all admin template: a cashier needs a fast, focused checkout terminal; an accountant needs a traceable, balanced ledger; a purchasing manager needs supplier terms and stock levels visible before committing to an order. A single shared component library — table, form, modal, and status primitives — keeps every one of those screens visually consistent without slowing down how quickly a new module's UI can ship.
Development
The accounting and inventory ledgers were built first, since every other module — POS, purchasing, payroll, manufacturing — needed something authoritative to post into. Role and permission scaffolding came next, seeded with real business-vertical roles rather than generic admin/staff placeholders, so access control was correct from each module's first screen rather than retrofitted later. The shared component library was proven end-to-end by building Catalog's CRUD screens first, which is also where a subtle Angular content-projection bug affecting every status badge in the app was caught and fixed once, rather than once per module.
Core Capabilities
Access Control & Role Management
20 seeded roles, each scoped to only the module groups a given business type actually needs, enforced by a specific granted permission rather than a job title.
Catalog & Product Variants
Categories, brands, and products with color/size/material variant combinations, each with its own SKU, barcode, price, and stock.
Multi-Warehouse Inventory
An append-only stock ledger derives current stock per warehouse, with transfers, adjustments, batches, and expiry tracking always current.
Purchasing & Supplier Ledger
Purchase orders route through an approval step before committing to a supplier, with goods receiving, returns, and a running supplier balance.
Point of Sale
A fullscreen checkout terminal with shift and cash-drawer tracking, held orders, and split payments across cash, card, and mobile methods.
CRM — Customers, Loyalty & Wallet
Customer accounts each carry a wallet and a loyalty-points ledger, both derived from an append-only transaction history, never a stored balance.
Marketing
Coupons, flash sales, and campaigns run from the same admin, ready to wire into a storefront checkout.
Accounting & Double-Entry Bookkeeping
A hierarchical chart of accounts and a double-entry journal enforce debit-equals-credit on every entry before it can post.
HR & Payroll
Attendance, leave, and payroll calculate net salary automatically from basic pay, allowances, and deductions.
Manufacturing & Bill of Materials
Production orders consume raw materials by recipe and produce costed finished goods, with scrap tracked separately from output.
Warehouse Operations
Pick lists, packing, and dispatch track fulfillment status without duplicating the stock movement Sales and Purchasing already recorded.
Cross-Module Reports
Nine dedicated report endpoints turn sales, purchasing, inventory, manufacturing, finance, customer, supplier, tax, and HR data into decisions.
CMS
Pages, blog, FAQ, and policies, available as an optional module for business types that need a public-facing site.
System Administration
Users, roles, module toggles, encrypted third-party integrations, audit logs, and one-click database backups.
Multi-Branch Management
Every branch operates independently day to day, while ownership sees consolidated visibility across the whole organization.
Product Highlights
Business-Type Module Toggling
Every module — POS, manufacturing, HR, CMS — turns on or off per business type from one shared codebase, driven by configuration and permissions rather than a fork.
Lets a new business vertical launch by configuring modules, not building a new platform.
Ledger-Derived Core Numbers
Stock levels, account balances, wallet balances, and loyalty points are never stored as an editable number — every one is derived from an append-only ledger of entries.
Keeps financial and inventory numbers trustworthy as more modules and staff post into them.
Vertical-Scoped Role-Based Access
20 seeded roles, each scoped to only the module groups a given business type actually needs, so a Grocery Shop Manager and a Garment Factory Manager see genuinely different systems from the same login screen.
New hires get exactly the access their role requires on day one, without manual permission cleanup.
Double-Entry Accounting Core
Every sale, purchase, payroll run, and production order posts through the same journal, enforcing debit-equals-credit before anything saves.
Financial statements reflect operational activity in real time instead of a month-end reconciliation pass.
Resilient Point-of-Sale Terminal
A fullscreen checkout terminal with shift and cash-drawer tracking, held orders, and split payments, isolated from the rest of the admin shell while active.
Keeps checkout counters fast and focused, without exposing or risking the operational data behind it.
BOM-Driven Manufacturing
Production orders consume raw materials by recipe, check stock sufficiency across every material before committing, and record consumption and output as one atomic transaction.
Turns production into a costed, auditable process instead of an estimate.
One Reusable Component Library
A single Universal Table (server-driven pagination, sorting, search, bulk actions, CSV/Excel export, saved views) and a shared set of primitives power every CRUD screen across a dozen-plus modules.
New modules ship faster and stay visually consistent, instead of every screen reinventing its own table and form.
Cross-Module Reporting
Nine dedicated report endpoints aggregate sales, purchasing, inventory, manufacturing, finance, customer, supplier, tax, and HR data without duplicating any module's underlying tables.
Owners get one place to see how the business is actually doing, without a separate BI tool.
Industry Solutions
Clothing & Fashion Store
Category and variant-driven catalog with ecommerce and CMS available for brands that need a public-facing site.
Super Shop & Grocery
High-SKU, high-transaction-volume checkout with barcode-driven POS and real-time stock across departments.
Electronics, Mobile & Hardware Shop
Warehouse-backed inventory and purchasing for higher-value, lower-turnover stock.
Wholesale Business
Purchase approval workflows and supplier ledgers keep bulk trading organized and collectible.
Warehouse & Distribution
Multi-warehouse transfers, pick lists, packing, and dispatch keep fulfillment visible end to end.
Garment Factory
Bill-of-materials production orders and quality checks turn raw-material purchases into costed finished goods.
Garment Factory + Showroom
The same production core as a standalone factory, with POS and ecommerce layered on for direct-to-customer sales.
Automation Highlights
Stock updates automatically with every sale, purchase, transfer, and production order — no manual counts to reconcile.
Accounting entries post automatically from POS checkout, purchasing, payroll, and manufacturing, not a separate bookkeeping pass.
Purchases route through an approval workflow before a supplier is committed to.
Module availability is checked and cached per organization, rather than re-evaluated on every request.
Customer loyalty points and wallet balances update the moment a transaction is recorded, always derived from the ledger.
Production orders check stock sufficiency across every required material before committing to any of them.
Database backups run on demand and always resolve to a completed or failed state — never left silently pending.
Reporting & Insights
Technology & Engineering Details
Frontend
Backend
Database
Caching & Queues
Authentication
Infrastructure
Security
- Every action is checked against a specific granted permission rather than a job title, with a Super Admin bypass reserved for one explicit gate.
- Self-delete and Super-Admin-role deletion are explicitly guarded, both in the API and in the UI.
- Third-party integration credentials are encrypted at rest, separate from the plain settings they're stored alongside.
- Database backups run through argument-array process execution rather than a shell string, ruling out command injection.
- Optional modules are gated server-side by route middleware, not just hidden client-side.
Performance
- Stock and financial balances are calculated from the latest ledger entry, not summed across full history on every request.
- Concurrent stock writes are protected with row-level locking on the ledger to prevent race conditions during simultaneous sales.
- Every list screen paginates, sorts, and searches server-side through one shared table component, instead of shipping full datasets to the browser.
- Module-enablement checks are cached rather than re-queried on every request.
Responsive Design
The admin shell — sidebar, tables, forms — is fully responsive with a collapsible, mobile-aware sidebar, while the point-of-sale terminal switches to a distraction-free fullscreen layout, sidebar and topbar hidden entirely, suited to a fixed checkout counter rather than a phone screen.
Architecture & Design Decisions
The platform is a single Laravel 12 REST API paired with an Angular admin frontend — not a monolith split by business type, but one codebase where module and permission configuration decides what a given organization and role can see and do.
Every module that touches money or stock — Accounting, Inventory, POS, Manufacturing, HR payroll — posts through one of two central, append-only records: a stock ledger or a financial journal. Current balances are always calculated from those entries, never stored as a number someone edits directly.
Role-based access is enforced at two levels: what a specific permission allows a user to do, and which modules are enabled for the organization's business type and plan — a Grocery Shop Manager role means nothing on a system that doesn't have inventory enabled, so both checks have to agree.
A cached module-gate service, plus route middleware on every optional module, enforces module access server-side, so disabling a module for one business type is a real API-level guarantee, not just a hidden sidebar link.
Business type turns modules on or off — never a forked codebase
A clothing store, a super shop, and a garment factory need different tools, but forking the platform per business type multiplies cost and complexity with every new customer type. Different business types get different modules turned on, on the same underlying platform, instead of a separate build to maintain for each one.
Every core number is derived from a ledger, never stored as an editable field
A number that can be edited by hand eventually stops matching reality. Stock levels, account balances, wallet balances, and loyalty points are all calculated from an append-only history of entries, the same pattern applied consistently across Inventory, Accounting, and CRM rather than reinvented per module.
Access checked against a specific permission and the organization's enabled modules, together
A staff member's role decides what they're allowed to do; their organization's business type decides what's available at all. Checking only one would either expose a grocery cashier to manufacturing tools it never needed, or lock out a legitimate role the moment a business type changes — so access always requires both to agree.
One shared component library before the first module's UI
Building Catalog's CRUD screens first, deliberately, proved the shared table, form, and status-badge primitives end-to-end before every other module reused them — cheaper to find and fix a bug once in a shared component than once per module later.
Encrypted integration config as a text column, not JSON
MySQL's json column type rejects the ciphertext an encrypted array cast produces with a validation error, so encrypted third-party integration settings are stored as text instead — a real gotcha worth remembering for any future encrypted-JSON column.
Inside the Product
Modular admin dashboard
Permission-filtered sidebar and dashboard, showing only the modules a given role and business type have enabled.
Point-of-sale terminal
Fullscreen checkout with shift management, held orders, and split payments.
Double-entry accounting core
Journals and account statements, with every balance derived from posted ledger entries.
Role & permission management
20 seeded roles scoped to only the module groups a business type actually needs.
Platform architecture
One Laravel API and Angular frontend, with modules gated by configuration and permission rather than a forked codebase.
Results & What's Next
Business Impact
- Fourteen business modules — from Catalog through System Administration — built on one shared accounting and inventory core, from a single Laravel/Angular codebase.
- Role-based access proven across 20 seeded roles and 11 demo personas, each genuinely restricted to its own relevant modules.
- A reusable component library — Universal Table, Toast, Modal, Input, Select, and more — built once and proven end-to-end across a dozen-plus CRUD modules.
- Double-entry accounting wired directly into POS checkout, purchasing, payroll, and manufacturing, so financial statements reflect operational activity without a manual bookkeeping pass.
- Nine cross-module report endpoints turn transactional data already in the system into sales, inventory, finance, and HR insight without a separate analytics stack.
Future Roadmap
- Planned: background job processing and a scheduler for automated alerts — low stock, expiring batches, overdue invoices — with Redis already configured as the queue driver.
- Planned: barcode/QR camera scanning in the POS product search, beyond today's keyboard-wedge scanner support.
- Planned: receipt printing from the POS terminal.
- Planned: a customer-facing storefront endpoint for online orders, distinct from today's admin-side order list.
- Under consideration: push notification and email marketing modules, deliberately deferred until the core modules are further proven.
Results
Related Work
Sheba Khoji
Emergency & essential-services finder for Bangladesh
The Problem
In an emergency, finding the nearest hospital, ambulance, or compatible blood donor in Bangladesh is fragmented across phone calls and word of mouth.
Engineering Highlight
Blood SOS requests broadcast via Firebase Cloud Messaging to matching donors within radius and blood-type filters in real time, with a full bilingual Bangla/English UI.
POS + Inventory + Accounting ERP
Unified business management for retail, wholesale, and manufacturing
The Problem
Retailers, wholesalers, and manufacturers run inventory, purchasing, and accounting as disconnected tools, with no single source of truth for stock or cash.
Engineering Highlight
A shared accounting core ties every sale, purchase, and stock movement to the books automatically, so financial reports stay accurate without a manual reconciliation pass.
CommerceFlow
Multi-tenant commerce platform for Facebook-driven, COD sellers in Bangladesh
The Problem
Online sellers running their business through Facebook have no real catalog, order record, or delivery visibility — and cash-on-delivery puts real financial risk on every order.
Engineering Highlight
Two selling surfaces — a full multi-product storefront and a single-product landing-page builder — run on one tenant-isolated core, with courier fraud and delivery-success checks built into fulfillment.
Ready to build your next digital product?
Tell us what you're building — we'll respond with a clear plan.