Software for a line that does not stop.

Production, inventory, procurement, finance and HR on one system, configured to the process the plant already runs and rolled out a module at a time.

EvidenceGuru ERP across production, inventory, procurement, finance and HR on a plastics production floor in Riyadh, single facility.
OutcomeOne set of numbers for the floor and the office at Three Arrow Plastics in Riyadh, and the same build running under a different tax regime in Dubai. No percentage is published, because nobody metered the before state.

What is hard about this sector, before anybody writes software.

If a line below would still be true had we never worked in this sector, it is not specific enough to be on the page.

  • The floor and the office disagree

    Production says one thing, stock says another, finance reports a third, and the reconciliation meeting is the real system.

  • The workaround became the process

    A spreadsheet on a supervisor’s desktop fills the gap between what the software assumes and what the plant does.

  • No window to switch over

    The line does not stop for a migration, so every plan that begins with a cutover weekend is already out.

  • Traceability after the fact

    When something has to be traced back through a batch, the record has to have been built as the work happened, not reconstructed afterwards.

Capabilities, in the order they matter.

Production planning, inventory, procurement, finance and HR on one system, configured to the process the plant already runs.

  1. Production planning

    Work orders, routing and output booked on the floor rather than reconstructed from paper at the end of a shift.

  2. Inventory

    Raw material, work in progress and finished goods on one ledger, moved by the same events that move the physical stock.

  3. Procurement

    Requisition through to receipt, with the receipt closing the loop against the stock record instead of a second entry.

  4. Finance and HR

    A ledger fed by operational events and one employee master shared with attendance, shifts and production booking.

  5. Reversible rollout

    Module by module, each behind a switch that can be thrown back. A plant that cannot stop cannot accept a migration that only works forwards.

  6. Multi-plant

    More than one facility or entity on one system, with reporting that assumes they are related.

What changes about security in this sector.

The realistic risk on a plant system is not exfiltration, it is availability and integrity: a screen that is wrong during a shift costs more than a screen that is slow. Access is modelled against roles that exist on the floor, releases are reversible, and the constraint that a supervisor can never be blocked from booking output is a design input rather than a support ticket.

DevTechGuru holds no security or industry certification, and no page on this site claims one. Where a regime applies it is named as your obligation and as a design constraint we build inside. Ownership, handover and AI governance covers what a procurement reviewer usually asks next.

Technology

Backend
PythonDjangoFastAPINode.js
Frontend
ReactTypeScriptNext.jsDesign systems
Data
PostgreSQLMySQLRedisData modelling
Cloud
AWSDockerCI/CDInfrastructure as code

Questions we get asked.

Questions this sector asks that the others do not.

Can you roll out without stopping production?

That is the only way we do it. Modules go live one at a time behind a switch that can be thrown back, and the rollback is rehearsed rather than assumed.

Will we have to change how the plant works?

Not to suit the software. Discovery happens on the floor, and the exception somebody handles by hand is treated as a requirement rather than as a discipline problem.

You do not need to arrive with a perfect technical specification.

Start with the problem. Tell us what is slowing the business down, what you want to build, or where the current system is failing. We will tell you the shortest path forward, including when that path is not us.

Start your build