Standard Base Is Not a Name
← Blog
Myron WittmerMyron Wittmer

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

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.

← Blog

Stay informed

Get updates as we build — no hype, just the work.

More posts
We’re Not Building an AI That Designs Your Kitchen

We’re Not Building an AI That Designs Your Kitchen

Every cabinet software company wants to talk about AI right now. But cabinet design is not a creative writing task. A cabinet has to go together in the real world. Grainwork’s AI direction is not about replacing designers. It is about helping them navigate rules, configuration, and troubleshooting faster, without asking them to trust a black box.

Myron Wittmer
The Catalog Is the Wrong Place to Start

The Catalog Is the Wrong Place to Start

Legacy cabinet software often starts with a catalog, then piles on folders and subfolders to keep it organized. That may have made sense once. But for real shops, it usually turns into a mess nobody trusts. Grainwork is being built to start with types and presets instead, because shops build cabinets. They do not manage libraries.

Myron Wittmer
Collaboration In Software Should Feel Normal

Collaboration In Software Should Feel Normal

Legacy software made collaboration feel like a workaround. Grainwork is meant to change that by letting the whole job live in one place, so your team, your customer, and even outside drafters can all work from the same source of truth instead of chasing “final_final_v18.pdf.”

Myron Wittmer
View all posts →