Case study · Manufacturing operations
From sales to the production line, in eight modules.
From June to October 2026, we built eight modules for a Brazilian food manufacturer, one per area, all reached from the same portal. The company's ERP stays in place, and the finance module reads the payables from it.
- Client
- A Brazilian food manufacturerFood processing · Name withheld
- Period
- Since June 2026
- Status
- LiveHosted and run by us
- Result
- 8modules live, from sales to financial BIMeasuredClient portal · October 31, 2026
Every area needs its own records.
Sales, accounting, production, maintenance, the fleet and HR each have day-to-day records to keep, and each area needs its own screens and its own users. The company already uses an ERP, which holds the payables, so the new modules had to work next to it, not replace it.
The plant needs daily output, losses and line stoppages next to the production plan, product by product. Management needs revenue, cash, inventory and targets side by side.
One module per area, each with its own database.
We built a module for each area, all reached from one portal: sales (orders, customers, sales reps and targets), accounting (journal entries, cash flow and reports), finance, production, maintenance requests, fleet maintenance, HR and financial BI. Each module has its own users, with administrator and read-only roles.
The production module records each day's output, losses by reason and line stoppages, works out kg per hour and the planned output, and compares plan and actual day by day. Finance reads the payables from the ERP the company already uses, and HR imports the monthly payroll events from spreadsheets.
Each module is a separate web app with its own API and its own PostgreSQL database. Modules exchange data only through internal routes closed to the internet, which is how accounting and production feed the financial BI module.
From each module to the BI dashboard.
The modules were built from June to October 2026. Each area works in its own module, and data moves between modules only through routes we defined.
- 01
Open the module
The portal lists the eight modules, and each person opens the one for their area.
- 02
Save in the module's database
Each module saves to its own PostgreSQL database: daily output, journal entries, payroll events.
- 03
Share through internal routes
When one area needs another's data, it goes through an internal route closed to the internet, never through a shared table.
- 04
Show it on the BI dashboard
Accounting and production feed the financial BI module, whose dashboard shows revenue, cash, inventory, purchasing and targets side by side.
Stack
- React + Vite
- Node.js + Express
- PostgreSQL
- ERP integration
- Spreadsheet import (.xlsx)
- nginx
- systemd
- Linux VPS
Counted in the portal and on the server.
We counted these on October 31, 2026, in the suite's portal and the server configuration.
From the portal and the server
8
modules live in the portal: sales, accounting, finance, production, maintenance, fleet, HR and financial BI
MeasuredClient portal · October 31, 2026
8
separate databases, one per module; modules exchange data only through internal routes
MeasuredServer configuration · October 31, 2026
10 MB
maximum size of each payroll spreadsheet (.xlsx) imported into HR
MeasuredServer configuration · October 31, 2026
No usage figures here: orders, output and payroll are the company's numbers, not ours to publish.
Eight separate modules, and an ERP we do not replace.
Limits
The suite does not replace the company's ERP. The payables stay in the ERP and the finance module reads them from there, so what that module shows depends on the ERP.
Eight separate modules are eight services and eight databases to maintain and update, and data one area needs from another has to cross an internal route instead of sitting in a shared table. We have no before-and-after timing for this work, so this page claims no time saved.
What we learned
What already exists does not need retyping. The payables live in the ERP the company already uses, so the finance module reads them there instead of asking anyone to type them in again.
Separate modules keep each change small: one module can be updated without stopping the others. A database per module keeps each area's data apart, and every exchange between areas goes through an internal route we defined, closed to the internet.
Other projects we built.
2 h 42 min
for 300 invoices, about 32 seconds each
MeasuredExecution logs · May 8, 2026Read the case studyMay to June 2026 · Invoice automation
300 invoices posted into the ERP in 2 h 42 min
A system migration left a backlog of outgoing invoices. Robots attached to the team's logged-in browser posted each one and checked it against its total.
21 of 22
weeks with the report delivered, June to October 2026
MeasuredExecution logs · June to October 2026Read the case studySince May 29, 2026 · Scheduled reports
A weekly report of contracts about to expire
Every Monday, a robot runs on its own: it signs in to the ERP, finds the supplier contracts ending within 15 days and emails the report.
156-274 s
per contract with 2 to 6 items, in validation
MeasuredValidation logs · July 9 to 14, 2026Read the case studyJuly 2026 onward · ERP integration
A contract robot, and an orchestrator so robots can share one login
A robot posts each new contract from the client's internal platform into the ERP. An orchestrator gives the shared ERP login to one robot at a time.
35
redirect rules that send each old sports-portal address to its new page
MeasuredServer configuration · October 31, 2026Read the case studySince May 2026 · Club management
One platform for a club's members, sports and management
A club website with a member area on the club system's API, a chat, sports competitions, dashboards and a tournament site, built from May to October 2026. The old sports portal moved into the new website with page-by-page redirects, and its links kept working.
30 days
of nightly backups kept, each one verified automatically after it runs
MeasuredServer configuration · October 31, 2026Read the case studySince October 4, 2026 · Financial control
Financial control for a notary office, where nothing is deleted
Every payable and receivable goes in as a provision, an entry made before it is due, and is then settled in full or in part. Corrections and cancellations are logged with a reason, every change records who made it and when, and the database is backed up and verified every night.
Free 30-minute assessment
Tell us what the systemhas to do.
In 30 minutes we map what the software has to do and tell you what it would cost to build.