How a custom web app turned NR-12 machine inspection reports from a months-long task into a days-long operation

NR Secure performs NR-12 compliance inspections, NR-12 being the Brazilian regulatory standard for safety in machinery and equipment. In practice: the team visits the client's factory, inspects each machine one by one, documents everything with photos and checklists, and delivers a technical report. That report is the product. It's what the company gets paid for.

The problem was that the report was assembled by hand, in Word and Excel.

Picture a factory with 200 or more machines. For each one: photograph it, jot notes on paper or a phone, then - back at the office - transcribe everything, arrange the images, format and proofread. Each machine easily ran 3 to 5 pages. A complete report was a months-long undertaking.

I was hired to build a custom web app that would eliminate this bottleneck. The result cut report production time from an order of magnitude measured in months to one measured in days, and moved the entire operation off a single person's isolated desktop and into the cloud, accessible from anywhere, on any device.

The problem

The old workflow concentrated all the effort in the post-inspection phase. Field collection was just the start; the heavy lifting came afterward, at the office, and it was entirely manual:

• Transcribing paper/phone notes into structured documents
• Inserting and positioning dozens (or hundreds) of photos by hand
• Replicating the same formatting for every machine, without error
• Consolidating individual machines into a single report per company
• Proofreading everything manually, with inconsistency creeping in at every copy/paste

The bigger the client, the worse the scaling: effort grew linearly with the number of machines, and there was no structural reuse between reports. Each document was essentially rebuilt from scratch.

There was also a mobility and continuity problem: the files lived on one local machine. Working from elsewhere, on another device, or splitting the task across people was difficult.

The constraints

The project had clear boundary conditions that shaped the technical decisions:

• A freelancer's budget, not an enterprise product's. The solution had to be direct and efficient, with no expensive infrastructure or unnecessary complexity.
• Shared hosting. No sophisticated job queues, microservices, or dedicated server. The solution had to run well within those limits.
• Reports were downloaded by the team itself, not sent automatically to the end client. This had a direct impact on the PDF generation decision (below).

The solution

I built a web app in Laravel that replaced the entire Word-and-Excel workflow with a structured, cloud-centralized operation.

Machine and inspection records. Each client company, each machine, and each inspection became entities in the system. The structure that previously existed only as an informal convention inside documents became a real data model.

Collection optimized for speed. The data-entry interface was designed to minimize free typing. Wherever possible, I used checkboxes and selects instead of text fields. This did two things at once: it sped up entry in the field and standardized the data — which, in turn, standardized the final report. Less free text means less inconsistency and less proofreading.

Photo upload directly through the system. Each machine's images were uploaded and associated directly with the inspection, eliminating the manual step of inserting and positioning photos in Word.

Automatic report generation. From the structured data, the system assembled the formatted report automatically — both the single-machine report and a consolidated report for a set of machines, grouped by company.

The PDF decision: use the browser instead of a library

One technical detail worth highlighting, because it illustrates a pragmatic decision. Since reports were downloaded by the team itself (and not automatically pushed to the client), I introduced no PDF generation library at all.

The report was rendered as a well-formatted web page, and the team used the browser's own "print > save as PDF." This avoided an entire dependency — with all the maintenance, weight, and rendering bugs that PDF libraries carry, for a problem the browser already solved natively. Under the constraints of shared hosting and a lean budget, it was the right call: the simplest solution that met the real requirement, not the imagined one.

The result

The impact was immediate and visible:

• Report production time dropped from a months scale to a days scale. Work that used to take a month now fit into a week; reports for the largest clients, which took several months, were cut to a fraction of that.
• Fully cloud-based operation. What was locked to a local machine became accessible from anywhere, on any device, on shared hosting.
• Standardized reports. With collection based on structured fields, the final document gained a consistency the manual flow could never guarantee.
• Scale decoupled from effort. Inspecting a factory with hundreds of machines no longer meant hundreds of hand-assembled pages.

The team's reaction to seeing the whole operation organized in the cloud, accessible from anywhere, was genuine surprise, the gain was clear to them from the start.

The project went through two versions over the years: the first about a decade ago, and a second about three years ago, which kept the same premise and refined the solution based on real-world use.

What this project demonstrates

More than the stack, this case shows a pattern I apply across every project: identify the real bottleneck and attack it with the simplest solution that works. The gain here didn't come from sophisticated technology - it came from turning a manual, unstructured process into structured data and letting the system do the repetitive work. The decision not to use a PDF library is the same philosophy in miniature: solve the problem that exists, not the one that looks impressive.