You’ve outgrown the software.
Now what?

We had seen “the thing” before. Add a new job, or too many people looking at different data at the same time, and the whole system would start to choke. Sometimes it recovered in a few minutes. Sometimes the wheel of death spun for an hour. On the worst days it felt longer.

Support didn’t open for another two hours, if they answered at all. When they did, the conversation went the same way every time: restart, clear the cache, try a different browser, submit a ticket. The problems our shop actually had never made it onto anyone’s priority list.

During the sale we were told support would come to the shop if we needed it: training, diagnosis, hands-on help. That support never showed up. What we got was remote tickets, and the slow realization that an off-the-shelf system is built for the average customer, not for a fab floor with fitters waiting on cut sheets.

When the software stops, tens of thousands of dollars of labor and material sit still. Welders on the clock, material staged, nothing moving. That cost never shows up on a report, but every shop manager knows it’s there.

That was the morning I stopped pretending the system was “almost there.” The workarounds had become the real process. The software wasn’t a tool anymore. It was a bottleneck we were paying to use.

So the next conversation started the way it always does:

Option 1: Stay with the off-the-shelf platform and keep requesting changes. Every request goes into a queue. Priorities shift. Timelines slip. You’re still running parallel spreadsheets while paying annual licenses for a system that only partially fits.

Option 2: Hire your own developers. Desk space, computers, benefits, and a salary that starts well into six figures before overhead. Now you’re running a fabrication company and a software company at the same time, and the people writing the code still don’t know what you do or why you do it.

A strong developer can write clean code. They cannot instantly understand heat numbers, hold points, traveler logic, revision stamps, or why one shop sequences work completely differently from the next. That knowledge lives in the heads of your fab managers. Teaching it takes months. Your system will only ever be as good as the people who can clearly explain the real process — and the developers’ ability to translate it without breaking something else.

Two years is a long time to stay stuck between “we need something better” and “we finally have something that works.”