Why I Built a Factory ERP on React, Express and MySQL

Once the mill's old data was safe, I had to answer one question: what should the new system run on?

I was building alone, for a factory that works every day. Whatever I chose, I would be the one fixing it at 2 AM. That shaped every decision.

Three options

Option 1: a desktop program

Familiar to the users. But it has to be installed and updated on every machine in the mill. One update means walking from floor to floor. I have seen that become a full-time job.

Option 2: a large framework with everything built in

Powerful, and full of ideas to learn while I was still learning the business itself. When something broke, I would be debugging the framework instead of my own logic.

Option 3: a plain web application made of well-known parts

Less magic and more typing. But every problem I met would already have an answer written by someone else.

I chose option 3.

Why these three parts

React for the screens. The system is dozens of data-entry forms and reports that share the same building blocks. Build the pieces once and use them everywhere.

Node.js and Express for the server. One language across the whole project. When you build alone, not switching between two languages is worth more than any speed test.

MySQL for the data. The data was already relational. Orders connect to lots, lots connect to production, production connects to dispatch. Forcing that into a non-relational store would have been fighting the data instead of using it.

The decision I am happiest about

It was not the stack. It was this: the whole system runs as one server.

The server delivers both the screens and the data. One command starts it. Any authorised machine on the factory network opens it in a browser. No installation, no setup, no update on each machine. I change it once and everyone has the new version.

For a system that must work on a production floor, with tablets beside the machines, that mattered more than any feature.

Where I got it wrong

I began with the whole server in one huge file. It worked, until I spent a minute scrolling to find anything. I later split it into modules, one for each area of the business: greige, printing, dyeing, dispatch, reports and administration. I should have done that on the first day.

The screens had the same problem. The first build sent every screen to the browser in one large file, so a tablet opening one form downloaded all of them. Now each screen is loaded only when it is opened, and the tablet gets only what it needs.

One list of screens

Every screen is registered in one place: its number, its address, the permission it needs and the code that draws it. The menu, the links and the permission checks all read that one list. A screen can be bookmarked, and nothing can fall out of step.

What I would tell another developer

• Good architecture is not impressive technology. It is what you can still maintain six months from now, alone, when something breaks.
• Boring and reliable beats clever and fragile.
• Split by business area early.
• Keep the deployment so simple that you could explain it on the phone.

What it means for a business owner

You do not need to care about the names of the tools. You should care about what they give you:

• nothing to install on each computer
• one place to update
• your data on your own server
• a system one capable person can look after

The full system is described in the textile mill ERP case study. If you are planning a system and want a second opinion on the design, send me a message.