The license was the cheap part. What you actually signed up for was months of work, and most shops never budget for it.
I’ve lost count of how many millwork shops I’ve watched spend tens of thousands of dollars on software, only to leave it sitting unused. Not because the software was bad, and not because they bought the wrong one. Because the implementation never happened. The new system got pushed to “next month,” and next month became never. What they ended up with was a very expensive icon collecting dust on the desktop.
Here’s the reframe that would have saved every one of them: when you buy Microvellum, Cabinet Vision, Mozaik, or an ERP like Innergy, you are not buying software. You are buying a project. The purchase order is the smallest, cheapest part of the whole thing , and it’s the only part most shops actually plan for.
Why shops get this so wrong
We’re trained to think of software like a tool. You buy a saw, you plug it in, it cuts. So we buy a CAD/CAM platform the same way, swipe the card, expect automation, and wait for things to get easier.
Then six months later the team is buried in formulas, nothing feels faster, and everyone quietly wonders if they bought the wrong product. They didn’t. They just never treated the purchase as what it was: the start of a project, not the finish line.
The tell is always the same. Nobody owns the implementation. There’s no plan, no milestones, no champion. The rollout happens in whatever spare minutes people can find between real work, which, in a busy shop, is no minutes at all. So it stalls, and the license renews every year for a system nobody fully uses.
What the project actually includes
If you’re going to buy the software, budget honestly for the project attached to it. Here’s what’s really on the invoice, even though none of it shows up on the invoice:
- Setup. Plan for one to three months just to stand up a working configuration.
- Libraries and standards. Another three to six months to build your libraries and get your standards into the system. This is the real work, and it’s where the value lives.
- Dual-system overlap. You can’t flip a switch. Budget six to nine months of running your old system and the new one in parallel while you transition, finishing existing jobs on the legacy setup while you start new ones on the new platform.
- A champion. One person who owns the process, runs weekly check-ins, and keeps the team pointed at the goal. Not the owner juggling twelve other things, a real, named owner with the time to drive it.
- Training. Not a one-day demo. Ongoing, hands-on, until the team is faster on the new system than they were on the old one.
Notice that almost none of that is about the software itself. It’s about people, time, and process. That’s the part shops don’t price in, and it’s the part that determines whether the purchase pays off or gathers dust.
Do the project right, not just fast
Two things separate the shops that win this project from the ones that abandon it.
First, adapt to the software instead of rebuilding your old workflow inside it. The most common way an implementation dies is a shop trying to force the new platform to behave exactly like the old one, recreating legacy joinery, machine logic, and habits in a new interface. Lean into the structure the software already has, then customize with your standards on top. That one shift removes most of the complexity that bogs implementations down.
Second, start with a win. Trust is the hardest thing to earn when you change how people work. Pick one small, visible pain point, assemblies coming out of square, hole locations not lining up, re-engineering the same cabinet five different ways — solve it, and show the improvement. Early wins create buy-in, and buy-in is what carries a months-long project across the finish line.
The truth underneath all of it
Here’s what I tell owners who call me frustrated that their software isn’t delivering, or convinced the answer is switching to a different platform: the software is almost never the problem, and switching almost never fixes it.
The project you actually bought isn’t a software project. It’s a process project. Standing up the system forces you to document your standards, define your construction defaults, and decide how work should really flow through your shop. That’s the hard part, and it’s the valuable part, and it’s the part that follows you to any platform you pick. Change the software without doing that work and your real bottleneck just moves over to the new tool with you.
So before you sign, ask the only questions that matter: Who owns this project? Do we have the months and the champion to run it? And are we willing to change how we work to get the payoff?
If the answer is yes, the software will transform how your engineering department operates. If the answer is no, save your money, because you’re not buying software. You’re buying shelfware.
We help shops turn a software purchase into an actual system, documenting your standards, building your libraries, and driving the implementation so it doesn’t stall out. If you’ve got a platform that isn’t earning its keep, or you’re about to buy one, let’s talk.
Jacob Edmond
CEO