How a commercial glazing fab shop scaled from 8 to 3 — and cut lead time in half

The starting point

The client is a mid-sized commercial glazing contractor running a fabrication shop and field installation crews. Like most shops in their category, they had grown by stacking purpose-built software: QuickBooks Enterprise for accounting, Partnerpak (with Glazer Studio) for estimating and engineering, and RhinoFAB driving the CNC cutting on the shop floor.

Each system was good at its job. None of them talked to each other.

The result was the operational pattern we see at almost every SMB manufacturer we work with. Estimates were built in one tool. Schedules were managed in spreadsheets. CNC output was tracked by foreman memory and shift notes. Accounting closed jobs from a fourth set of numbers. Nobody had a clear picture of capacity at any given moment, and nobody could tell you reliably what a job had actually cost until weeks after it shipped.

The fabrication schedule was the visible symptom: lead times were long, and shop headcount kept creeping up because it felt like the work demanded more bodies. Leadership suspected the real problem wasn’t workload — it was that they were planning blind.

Phase 1 — Audit and architecture

We started with a focused operational audit. Two weeks of interviews with leadership, the estimating team, and the floor. We followed a half-dozen real jobs from quote through invoice and documented every system handoff, every spreadsheet, and every retype.

The diagnosis was unsurprising in shape but specific in detail:

• Estimates from Partnerpak weren’t being reconciled against actual labor and material usage. Bidding was effectively guessing.
• The CNC machine knew exactly what it had cut and how long it had taken — but that data lived in RhinoFAB and never made it back to the people scheduling the next job.
• QuickBooks held the financial truth, but job-level profitability required someone manually mapping POs and timecards days after the fact.
• The fabrication schedule was a foreman’s whiteboard and a shared Excel — no view of true upstream demand or downstream capacity.

The audit deliverable was a roadmap. Phase one: stand up a unified data platform. Phase two: build a custom manpower estimator that actually consumed that data.

Phase 2 — The unified data platform

We provisioned an Azure data warehouse — sized for SMB workloads, not enterprise. Pipelines pulled data on a daily cadence:

• QuickBooks Enterprise via a scheduled extract pushing financials, POs, and labor into Azure
• Partnerpak / Glazer Studio via direct database reads of the estimating tables
• RhinoFAB by exporting CNC job logs and parsing them into the warehouse

We built a dbt project on top to clean and model the data. Job-level cost actuals. Estimate-vs-actual variance by line item. Shop utilization by hour, day, and station. Machine throughput per shift. The kinds of metrics every operations leader claims to want and almost no SMB actually has.

Power BI sat on top for reporting — operations dashboards, financial dashboards, estimating accuracy reports. The kind of work most consultants would have stopped at.

Phase 3 — The custom manpower estimator

This is where the real value showed up.

The honest problem with dashboards is that they tell you what already happened. The team needed a tool that helped them decide what to do next. Specifically: when a new job came in, how should they staff and schedule it given (a) what the estimate said it should take, (b) what jobs of similar complexity had actually taken historically, and (c) what capacity the shop had over the next 8 weeks.

We built a React front-end backed by an Express API that pulled directly from the warehouse. The estimating team could enter (or import from Partnerpak) the parameters of a new job and see in real time:

• Predicted labor hours by phase, grounded in historical actuals from comparable jobs
• A capacity overlay showing where the job would land in the existing schedule
• A flag if the estimate looked optimistic compared to historical patterns
• A revised completion date based on real shop throughput, not a guess

Foremen and estimators could now have the same conversation, looking at the same numbers. No more “the estimate says 80 hours but I think it’s really 120” — the tool showed exactly what the last six similar jobs had taken.

What changed

The numbers, twelve months in:

• Fabrication schedule lead time cut by 50%. Same shop, same machines, faster throughput — because nobody was waiting on bad information.
• Shop headcount went from 8 to 3 without a corresponding drop in output. The extra bodies had been masking a planning problem, not a capacity problem.
• Estimating accuracy improved measurably as the team trained itself against the variance reports. Bids became tighter and margins became predictable.
• Job-level profitability became visible in days, not weeks. Leadership could course-correct on troubled jobs while there was still time to do something about it.

Why it worked

Three things, in order of importance.

First, we treated this as an operations problem, not a data problem. The platform existed to support a specific workflow change — running the shop on data instead of memory. Any data project that doesn’t have a workflow change attached to it is a science fair.

Second, we built the custom app, not just the dashboards. Dashboards inform; apps enable action. The manpower estimator was the lever that converted infrastructure investment into operational outcomes.

Third, we kept it sized for SMB. Azure spend stays modest. dbt and Power BI are tools the client can hire for. No enterprise lock-in, no per-seat tax, no proprietary platform we’re the only ones who can maintain.

Could this be your shop?

If any of this sounds familiar — multiple systems that don’t talk, planning by gut feel, headcount climbing because “we just need more people,” surprises at month-end — there’s likely a similar engagement here. Get in touch.