Labor and inventory reporting platform for a bespoke automotive manufacturer
The weekly station hour report took 2 to 3 hours to rebuild in Excel. Now it opens in a browser and refreshes every 10 minutes.
- Industry
- Bespoke automotive manufacturing
- Completed
- March 2026
- In use
- Every day, by about 15 people
- Data
- SQL Server production database, Fishbowl inventory, month-end close
- Stack
- React, Node.js, SQL Server, SQLite
- Role
- Built by our founder, Hunter Warner, while working in-house
The problem
Every vehicle moves through stations on a production line, and each station carries a target number of labor hours. Supervisors needed to know, build by build, which stations were over target and which were still open.
That answer lived in a weekly spreadsheet. A finance analyst ran the SQL in SQL Server Management Studio, exported the results to Excel, waited for the XLOOKUP formulas to recalculate, and read the report. One run took 2 to 3 hours, and the numbers were out of date within days.
The company had already been through a costly ERP evaluation. Replacing the core system was off the table, so the fix had to run on the database the shop already had.
What we built
A web app that runs on the company's network and reads the production database directly, through a read-only account. Twelve queries run at once and join inside the app, the same joins the spreadsheet made with XLOOKUP, without the spreadsheet.
Results stay cached for 10 minutes and rebuild on their own. A Refresh button pulls live clock status when a supervisor needs it now.
Line Board
Every active build as a card, grouped by production line. Each card shows who is clocked in right now, percent complete, target and actual hours, and a colored strip with one square per station. Click a build to open the station-by-station drill-down.
Table
One row per station per build, more than 900 rows, with filters for line, department, labor code, pass or fail status and sign-off date. Export the filtered table to CSV.
Supervisor view
Supervisors log in and see this week's hours for each employee in their departments, with the builds each person worked.
Pass, fail, tracking
Each station gets a flag from its target hours, actual hours and sign-off state, so an overrun shows up while the build is still on the line.
Later the app grew. Inventory values from Fishbowl joined the labor data, and month-end close data followed: the profit and loss figures and the progress-tracking journal entries recognized for each vehicle in the current month. Labor, inventory and the month-end numbers now sit in one place.
What a build card shows
- Target hours
- 412
- Actual hours
- 388
- Remaining
- 24
- Complete
- 83%
- 9 pass
- 1 fail
- 1 tracking
- 1 in progress
- Pass rate 90%
How the data moves
The production database on SQL Server, inventory values from Fishbowl, month-end close data
Twelve read-only queries run at once and join inside the app, the way the spreadsheet did with XLOOKUP
Line Board, Table and the Supervisor view, in any browser on the shop's network
Rebuilt every 10 minutes, with a Refresh button for live clock status
The result
- The weekly 2 to 3 hour rebuild is gone.
- About 7 to 8 hours a week saved, counting the fixes and verification chasing that followed each manual run.
- Supervisors see hours against target while a build is on the line, not at the end of the week.
- In use since March 2026 by about 15 people, with labor, inventory and month-end numbers on one screen.
Stack
React on the front end. Node.js for the API, reading SQL Server for production data and Fishbowl for inventory. SQLite holds the supervisor accounts. Everything runs on one machine inside the company's own network, since the database is not reachable from the internet.
Next project: Inventory and purchasing system for a residential home builder group