Standard Base Is Not a Name
Not every shop cares about SKUs, and that is fine. But almost every shop benefits from cabinet names that tell you what you are looking at. “Standard base” does not mean much after the cabinet has been modified twelve times. A name should describe what got built.
A cabinet’s name should describe the cabinet.
That sounds obvious until you look at a cabinet list and see how often it is not true.
“Standard base” does not tell the customer, the shop, or anyone downstream what that cabinet actually is. It only tells you what the drafter probably picked when they first added it to the room.
Then the cabinet changed.
Maybe it got another drawer. Maybe the face changed. Maybe a shelf was added. Maybe it became something completely different.
But the name stayed the same.
Not every shop cares about SKUs.
That is fine.
But almost every shop benefits from a predictable cabinet name that gives you an at-a-glance idea of what you are looking at.
No, the name is not enough to build from by itself. Nobody should be manufacturing a cabinet from the name alone.
But it is still useful information.
It is useful for the customer reviewing a cabinet list.
It is useful for the shop looking over the job.
It is useful for the person checking labels, reports, and schedules.
It is useful for anyone trying to understand what is in the project without opening every cabinet one by one.
That is a lot better than assuming the drafter picked the right cabinet to start with, remembered to rename it, and updated the name every time something changed.
1. “Standard base” stops being true fast
In legacy software, a cabinet often keeps the name it had when it was first placed.
That works fine until someone modifies it.
This is how you end up with a cabinet named “single door” that is actually a ten-spot cubby. The name did not follow the work.
2. The name is usually what people see first
The designer may know what the cabinet is because they just built it.
But other people are often looking at lists, reports, labels, or summaries.
A customer may see the cabinet name in a proposal or review.
A shop lead may scan a cabinet list before the job hits production.
An installer may see a label on a box.
The name is not the whole truth, but it should not be misleading.
3. Manual naming does not keep up with real jobs
In theory, the drafter could rename every cabinet after every change.
In reality, jobs move fast. Cabinets change. People forget. Names get stale.
The problem is not that drafters are careless. The problem is that the software is asking them to remember something the cabinet should already know.
4. A better name comes from what got built
A name like “Base, 1 top drawer, 2 doors, 1 shelf” is not fancy.
But it tells you something.
It gives anyone looking at the cabinet list a quick sense of what that cabinet is, instead of forcing them to trust a generic name that may have been wrong for the last twelve revisions.
5. The shop should decide what matters
Some shops care about door counts.
Some care about drawer counts.
Some care about openings, shelves, finished ends, toe kicks, glass doors, or other features.
Some shops want short names. Some want more detail.
That should be configurable.
The shop should be able to decide which cabinet features become part of the name, and the software should generate the name from the cabinet itself.
6. The name should update when the cabinet changes
This is the whole point.
If the cabinet changes, the name should change with it.
The name should not be a snapshot from the moment the cabinet was added. It should reflect the current cabinet.
Otherwise, every list and label downstream starts with bad information.
A cabinet name does not need to contain everything.
But it should tell the truth.
It should give the customer, the shop, and anyone looking at a cabinet list a predictable at-a-glance description of what that cabinet is.
That is much better than hoping the drafter picked the right starting cabinet and remembered to update the name later.
A name should describe the work that got done.
Anything less is overhead the shop pays for on every job.
Myron Wittmer
Myron Wittmer is the founder of Grainwork and a cabinet software consultant. He’s spent years helping cabinet shops fix broken setups, untangle workflow problems, and get more control over the systems they rely on. Grainwork is his attempt to build the cabinet software he kept wishing he could recommend.



