Author's note (May 2026): I wrote this in December 2023, on my one-year anniversary in Viseu. It's the summary of a year of learning in a real industrial context. The most important lesson I learned wasn't technical.

My First Year in Portugal: How I Built an Industrial Production System From Scratch

Week 1: the reality of the factory floor

I arrived at SYSteel Group's plant in Viseu with the same instinct any developer brings to a new project: understand the system, map the components, identify the improvement points.

But before understanding the system, I had to understand the plant.

What I saw in the first week was extraordinary precision engineering in steel cutting: plasma cutters working to millimeter tolerances, press brakes shaping metal structures with exact repeatability, shot blasting and surface treatment processes requiring real technical control.

And alongside that technical precision: paper production orders. Handwritten notes traveling from the office to the shop floor. Excel spreadsheets with manually updated job statuses. Operators who had to walk to the office to ask what the next priority was.

The gap between the precision of the metal and the management of information was the problem I came to solve.

Listen before you build

The most costly mistake in digital transformation is building before listening. I've seen it in other people's projects and lived it firsthand in my early attempts with TALS — when I built features that nobody in the deaf community had asked for.

At SYSteel, I decided to do the opposite.

I put on the hard hat and safety shoes. I stayed on the shop floor. I asked the plasma machine operators the same question in different forms: "What takes up the most time in your day?", "When do you feel most blocked in your work?", "What information do you need that isn't easy to get right now?"

The answer was consistent across everyone: "I don't know which piece comes next or where the rest of the order is."

They weren't telling me the system was slow or the interface was complicated. They were telling me that the information they needed to do their job well simply didn't reach where they were. The problem wasn't technical — it was information flow.

That understanding completely redefined the design of SYSControl: not as a management control tool, but as an assistant for the person standing in front of the machine. The difference is subtle but fundamental for adoption.

The technical decisions and why they were made that way

Node.js for the backend. Familiar to me, performant enough for the project's needs, and with a mature library ecosystem for the type of operations we needed.

The critical decision was Socket.io for real-time updates. In an industrial plant, a five-second delay on the operator's screen isn't an inconvenience — it's a machine operation executing on stale information. If the office changes an order's priority, the shop floor screen has to reflect it instantly, not on the next page refresh.

I designed SYSControl as a digital nervous system for the factory: every status change in the office propagates instantly to all the points in the plant that need to know about it.

SQLite for the database in the first version, deliberately. PostgreSQL would have been more scalable, but the priority was deployment speed and maintenance simplicity in an environment with no DBA. Building the simplest version that solves the problem is always better than building the most elegant version that arrives late.

The first prototype and the first real reaction

I installed the first tablet next to a plasma machine. The interface was clean: the name of the current piece, the status of the complete order, the button to mark the piece as finished.

The operator's first comment was immediate and completely unexpected: "The buttons are too small for my fingers with gloves on."

I had spent weeks designing the interface thinking about standard software usability. I hadn't thought about the fact that users would interact with it wearing thick leather work gloves, in an environment with metal dust, with fingers less sensitive from the cold of the Portuguese winter.

It was the most direct industrial UX lesson I could have received.

I redesigned the entire interface with a new premise: every touchable element must be operable with gloves, contrasts must be visible under mixed industrial lighting (bay lights + machine floodlights), and there can be no small text or elements requiring precise touch.

The technical problems that aren't on Stack Overflow

SYSteel's environment has characteristics that no web development tutorial accounts for.

Industrial WiFi. Electromagnetic interference from plasma cutting machines and the metal structures of the factory bays degrades the WiFi signal unpredictably. I implemented automatic reconnection and local storage logic (offline-first) so that if a tablet loses connection, it continues working with local data and syncs when the network returns. The operator never sees a blank screen.

Legacy hardware. Some office computers ran outdated, unpatched versions of Windows. The system had to be compatible from the start with outdated browsers, without assuming ES6 or modern APIs on all clients.

The first production crash. It came at three months, on a Monday morning. An edge case in the sync logic that hadn't appeared in testing. I resolved it in fifteen minutes, before the afternoon shift started, without affecting critical operations. Managing that incident — fast diagnosis, calm fix, transparent communication with the management team — was as important as the code itself.

Adoption: the hardest problem

The operators' initial resistance wasn't indifference — it was active mistrust.

"You're here to monitor us." "This is so the boss can know exactly how long each piece takes." "Now they'll know if we take a five-minute break."

Those concerns were legitimate. Monitoring technology in industry has a long history of being used as a tool of labor control, not a tool of assistance. If you don't address that head-on, adoption never comes.

I changed the framing entirely. Instead of presenting SYSControl as a production management system, I presented it as: "I'm here to stop you from walking to the office ten times a day to ask what to do next."

That framing worked because it was true. The biggest frustration operators expressed wasn't the work itself — it was the constant interruption of having to find information that should be available where they were.

When they saw that the app saved them physical steps and gave them the autonomy to know exactly what came next without asking, the attitude shifted. The operators who had resisted most became the most active in reporting bugs and suggesting improvements. Digital transformation isn't imposed — it's sold as an improvement to daily work life.

The numbers at year 1

At the close of SYSControl's first year in production, the results were concrete:

• 90% reduction in paper in the cutting area: production orders are managed entirely in the system
• Real-time office-to-floor communication: what previously took hours (a person walking or calling) became instantaneous
• Estimated 15% reduction in machine idle time, from having next-piece information ready before the current one finishes
• Zero shift interruptions from missing information in the afternoon shift, which previously depended on morning shift handover notes

But the number that mattered most to me wasn't any of those.

It was seeing a veteran operator — someone who had been in the plant for 20 years and had never touched a tablet — swipe his finger to mark a piece as complete and smile because "now everything is clearer." That operator became SYSControl's biggest advocate on the shop floor.

That's my real KPI.

What I learned that isn't in any web development course

Web development courses teach JavaScript, frameworks, architecture patterns, code best practices. What they don't teach:

Process before code. 50% of the time in a successful digital transformation project is spent understanding the process you're going to digitize. If you don't understand the human and physical process, code only digitizes the chaos.

Internal politics of an industrial company. Who actually has authority over what, what tensions exist between departments, why certain decisions are made in certain ways even when they seem irrational from outside. Understanding that before proposing changes prevents technically perfect implementations that die from organizational resistance.

How to sell change to someone who would prefer things to stay the same. The most underestimated skill in digital transformation isn't technical — it's empathic persuasion. Understanding the genuine fear behind the resistance and responding to that specific fear, not to a generic fear "of change".

I'm a developer who writes JavaScript. But before writing the first line of code, I'm a field engineer who puts on a hard hat and learns the process I'm going to digitize.

That order matters.