Case study

Manufacturing ERP

Custom ERP for a steel manufacturer that had outgrown AutoCount and could not customise it any further.

Production to accountsno reconciliation between

Sector
Steel manufacturer
Year
2024
Role
Team of seven
Stack
C#, .NET, MySQL
Runs on
Self-hosted

The problem

The client ran on AutoCount and had reached the end of what it could be customised to do. Their production process did not fit the package, which leaves two options. Run the real process outside the system, or bend the business to the software. They were paying for both. Procurement, inventory and accounting stayed separate exercises reconciled by hand downstream of it.

What we built

An ERP built to the operation rather than to a package: production planning and execution, procurement, inventory and accounting in one self-hosted system. Production is the part that justified building rather than buying, because it is the part no off-the-shelf package was going to fit; once it was modelled properly, everything downstream of it had a single source of truth instead of a reconciliation.

The long version

Off-the-shelf accounting packages are good software. The reason a business outgrows one is almost never accounting. It is that the package has a fixed idea of how goods come into existence, and a manufacturer whose process does not match that idea ends up describing their real work in the package’s terms and keeping the real version somewhere else. That somewhere else is usually a spreadsheet, and it is usually the thing the business actually runs on.

The build started at production for that reason, not at accounting. Once production is modelled the way the floor actually works, procurement stops being a guess, inventory stops needing a reconciliation, and accounting is downstream of facts rather than of re-entry. The other order is the tempting one, because accounting is the part that already exists. It would have produced a tidier ledger sitting on top of the same disconnect.