Cabinet and Millwork Software Problems: The 7 That Eat Your Margin, and How to Avoid Them

Why does estimating scope get underestimated in almost every shop build?

Because the estimating workbook looks small. It is a few hundred rows of rates and formulas, and it converts to a database table in an afternoon. What it actually contains is your estimator's judgement encoded as fudge factors: a linear foot rate that quietly absorbs the fact that your machine takes longer on five piece doors than any published figure suggests, and an adjustment for the curved thing that exists because he has been wrong about curved things before.

Decomposing that into parts, operations, materials, hardware items, edgebanding and machine minutes is three to five weeks of work and it is the hardest conversation of the project, because it requires a person to explain a number he has never had to justify. Skip it and you have rebuilt the same guess with a better interface.

This is specific to custom millwork because your accuracy is not uniform. Estimators are usually close on paint grade shaker boxes and wide of the mark on mitred doors, radius work and integrated panels, and nobody learns which because actuals are never compared back at the operation level.

The fix is to model the estimate at the part level from the start, then close the loop with shop floor capture so the rate table rebuilds itself from your own completed jobs. Name the decomposition as a funded phase, run the workbook and the new estimate in parallel for six to eight weeks, and compare quote by quote before switching. A proposal that prices this as a data import has moved the cost into your change orders.

What goes wrong when the estimating workbook and job history move into a system?

Two things, and the second is the one nobody expects. The first is unit and identity chaos: hardware bought by the box and consumed by the piece, sheet goods tracked by count and costed by square footage, and supplier item numbers that changed when your rep moved you to a different line. Import that as it stands and every material cost the new system produces is confidently wrong.

The second is that most shops have no actuals to migrate. Job history in QuickBooks or Sage tells you what a job invoiced and what materials were purchased against it. It does not tell you how many minutes that job spent in the drill line or the finish room, because nobody ever recorded it. Any analysis that depends on estimate versus actual therefore cannot be built from history, only from the day you start capturing.

The fix is to accept that and sequence around it. Start shop floor scanning early, before the reporting is finished, so data accumulates while the rest is built. Expect four to six months before predictive labour estimates from your own history are worth anything, and treat anyone promising useful predictions on day one with suspicion. Import purchasing history for material pricing, import customers and jobs for continuity, and leave the fantasy of backfilled labour actuals alone.

Why do Cabinet Vision, Microvellum and accounting integrations break after launch?

Reading a Cabinet Vision or Microvellum database is straightforward. Reading it correctly for your library and your naming conventions is three to five weeks by itself, because every shop's library is different and the part names in it are yours. That is also why these integrations break: someone extends the library, adds a new construction method or renames a category, and the extraction starts producing parts the system cannot classify.

On the accounting side, QuickBooks Online and Sage 100 are different problems with different costs, and a quote that says accounting integration without naming which one has not been priced. The recurring break is item mapping: a new hardware item or a seasonal material appears on one side and not the other, and the sync either drops the line or halts the batch.

The fix is a cross reference table your own people own and edit, plus a quarantine queue so an unrecognised part or item is held for review rather than silently discarded. Alert when the queue grows. Then agree a rule with your engineering team that library changes get flagged to whoever owns the integration, because a library edit made on a Tuesday afternoon should not be discovered as a broken cut list on Thursday morning.

What happens when post release change orders are not covered?

A builder emails a revision late on a Thursday. The island grew, three drawer banks became two, and the species changed. Your engineer updates the model and regenerates the parts, which is the easy half. The hard half is that two sheets are already cut, the doors are already in the finish queue, the new veneer has a lead time that moves the install date, and the original quote had no clause for a species swap.

Without a part level release state, none of that is computable. The job ships, the invoice goes out at the original number, and the scrap is absorbed into an overhead figure that gets called shop error at the end of the year. The other version is the return trip: a change nobody caught turns up on install day and costs you a crew, a remake and a relationship.

The fix is a release state machine per part rather than per job, with each part carrying a status from engineered through nested, cut, edged, drilled, assembled, finished, staged and installed. When a change lands, the system compares the new part list against the released one and produces three lists: unaffected, not yet cut so simply re-released, and already in production and therefore scrap with a dollar figure attached. That figure goes onto the change order as a line item, which is the mechanism that stops you absorbing material silently.

Should you build custom or configure what you already own?

Do not build if you are under roughly six million dollars, single location, and running mostly repeatable box work. Cabinet Vision or Mozaik plus a disciplined estimating workbook plus QuickBooks will carry that shop, and the money belongs in process and people. Shops at that size that want custom software are usually trying to buy their way out of a process problem, and software makes those more expensive rather than less.

Do not replace your design software at any size. Cabinet Vision, Microvellum and Mozaik turn a design into nested parts and a cut list, and rebuilding that capability is a multi year mistake. What they do not do is tell you whether the job made money, track what changed after release, or schedule across two shops. The build is the system of record around them.

Configure before you commission. A great deal of the pain we are asked to fix is an unmaintained library, a rate table nobody has touched in three years, and a purchasing process that never had a forward view. Fix those and re-measure.

Build when you are quoting across two or more locations and cannot answer which shop a job should run in without a meeting, when you cannot state gross margin by job type without a week of work, when a full time person moves data between design software, Excel and accounting, when remakes exceed roughly three percent of revenue and nobody can say why, or when a production builder is making a portal and data access a condition of a rollout contract.

How do hidden costs get into the quote?

These are the lines that move numbers in a millwork build, and they are usually bundled.

• Reading your specific library. Three to five weeks on its own, and it is different for every shop, so a portfolio reference does not shorten it.
• Machine integration beyond nest files. Live status and real cycle times off a controller depend entirely on the machine, and an older controller is a different project from a current one.
• The second location. Inter shop transfers, per shop rate tables and consolidated capacity are a dimension rather than a duplicate.
• Which accounting system. Sage 100 or Sage Intacct integration costs meaningfully more than QuickBooks Online, and quotes rarely say which was assumed.
• Offline first scanning. A dusty metal building with poor coverage at the far end means the scanning app cannot require a live connection, and retrofitting that later is expensive.
• Prevailing wage and lien waivers. If you do institutional or government work, certified payroll changes how shop floor capture is built, so it has to be designed in rather than bolted on.

What separates a millwork build that works from one that fails?

Ask a prospective developer to model one real completed job before you sign. You want job, elevation, cabinet, part, operation, material and hardware item, with the cabinet as a parent of parts carrying routings. If a cabinet comes back as a line item, they will rebuild it in month five on your money, and this single question filters out most candidates.

Ask what they have read out of a Cabinet Vision or Microvellum database, specifically. Not whether they can integrate, which everyone answers yes to, but what the schema looks like and how they handled a shop's custom library.

Ask what happens when the network drops or a tablet dies on the floor. If scanning requires a live connection, your production manager is back to the clipboard in week two and the whole system collapses with it.

Then settle ownership in writing before kickoff, covering the repository, the database and hosting. Your job history and rate tables are the most valuable thing the system creates. Successful builds are also phased: part level quoting, the design data pull, change order differences and barcode status first, with capacity scheduling, the builder portal and material planning afterwards. Nobody should buy all of it on one purchase order.