I spend my days helping residential contractors sort out their construction management systems, which means I read a lot of tech material. We are well into the computer era. There is a sea of software sold to us as the way to make our lives easier, more organized, generally better. The reality is that the software often creates more work than it saves. I have been in this business a long time, through the rewards of a job that runs clean and the stress of one that goes sideways, and I care a great deal about finding better ways to do the work.

Which is why a line from a software CEO stuck with me. Loosely transcribed: “if you hardcode something that should be a primitive, the system works against you.”

That is software jargon. But I set up construction management systems for a living, and it named something I see in nearly every company I walk into.

A primitive is a 2x4. A hardcoded system is a panelized wall assembly.

Stick framing works. Nothing wrong with it, which is why it is still the dominant method in residential. That does not mean it is always the better way. The panel salesman wants you to see the efficiency and the labor savings, and sometimes he is right. The professional builder knows immediately which method fits the job and what the tradeoffs are.

You make that same decision every time you buy software for your company. Most builders make it the way a rookie super orders panels: off the sticker price, with no plans to check the fit against.

When you price a panelized package against stick framing, you never stop at the shop’s number. You run the whole bid.

Total installed cost. The shop quotes the panel. You price the freight, the crane, the access, and the ground crew. Software has the same hidden line items: migration, training, integration, and every workflow your team has to bend to fit the tool.

Tolerance stack. Panels demand a tighter foundation than sticks forgive. A packaged tool demands that your process conform to its shape. How much conformance does it impose, and can your operation actually hold that tolerance?

Equipment the assembly requires. A panel needs a crane. Does the tool need infrastructure, roles, or discipline you do not have yet? If you have to build capability just to receive the thing, that cost goes in the bid.

Lead time and single-source risk. One panel shop is one schedule and one point of failure. One vendor is one roadmap, one outage, and one pricing change away from a problem.

Rework cost if you are wrong. A panel is visible, and at a price it comes back out. Some software fuses itself into your records so deeply there is no rework path at all. Errors compound fast in an efficient system, and reversal is where the pain lives.

Coverage versus distortion. This is the one that disqualifies at any price. Does the assembly build what your plans call for, or does it quietly pressure you to redraw the plans around it? The moment the panel starts editing the drawings, the hierarchy has inverted, and no discount fixes that.

Run those six and the panel-versus-stud question mostly answers itself. Which raises the obvious question. Why does nobody run this on software?

Without one you get the panelized wall that was ordered and installed before anyone checked whether it fit.

You solved this problem on the jobsite a long time ago, and it is a large part of why you are still in business. It works out there for one reason: you have plans, and you have people who know how to read them. Your office has no such thing. The people running your contracts, your billing, and your client communication are working without drawings or specs, and that is where the expensive errors live. Work you performed and never got paid for. Scope nobody caught until it was built. The client who heard something different than what you meant.

Watch what happens without them.

A scheduling tool decides that “who is accountable for this contract activity” and “who is swinging a hammer Tuesday” are the same fact, and welds them into a single field. They are not the same fact, and they do not move at the same speed. The contract side wants to be locked and write-protected. The crew side gets reshuffled every Monday morning.

You cannot pull them apart without wrecking the record, so your office does the only sensible thing left. It builds a spreadsheet on the side. Now the truth about your labor lives in two places, both maintained by hand, and neither one is trustworthy.

Go read the user forums for any of the big platforms. You will find a dozen builders who independently invented the same workaround spreadsheet. That is not a feature request. That is a missing stud. Somebody shipped an assembly where your business needed a piece of lumber.

And here is the tell you can use on your next demo call. When a vendor answers your concern with “you can add custom fields,” look hard at what those fields are bolted to. Custom fields on a fixed object are flexibility in the paint. What you need is flexibility in the frame, and a plan that says where the walls go before anybody starts fabricating. No panel package covers the whole house. You have to be able to frame the gaps yourself, in a workmanlike manner, without fighting the assembly.

None of this means packaged tools are bad. You stick-frame the parts that need it and buy panels where panels are faster and cheaper. The rule is the one you already live by in the field. Hardcoding is not the error. Ungoverned hardcoding is.

On a job you would never set a panel without three things in place.

Those three conditions are how you should approach every software purchase and setup decision you make. And notice the roles that make them work. The plans, which settle every alignment argument. The inspector, who verifies and flags but never swings the hammer. And the GC, who weighs every decision against the plans and sequences the work.

Your business operation has vendors. It has materials. It has tools stacked on tools. What it almost certainly does not have is a set of construction documents that lay the operation out end-to-end, an inspector to verify the work against them, or a GC governing the daily activity. That is the whole problem, and it is why the software feels like it works against you.

Before your next software decision, run the bid you would run on any assembly.

The evaluation, before you buy. Total installed cost. The tolerance it imposes. The equipment it requires. Single-source risk. Rework cost if you are wrong. And whether it builds to your plan or pressures you to redraw it.

The five questions, for the vendor. Which of your objects are the permanent record, and which are the working layer? Can my team reconfigure the working layer without touching the record? Is your flexibility real composition, or custom fields on fixed objects? What happens when two things I need to track separately live in one of your fields? And if this does not work out, what is my rework path?

A vendor with good answers is a panel shop you can count on to make the job run better. A vendor without them is selling you a wall that might work and might not.

You already run this discipline on every job you build. The next step is running it on the systems those jobs depend on. That is plan review, and it is exactly where we start.