From Metal Company Using Software → To Software Company Doing Metal

Metalworking companies must shift their identity from "metal company using software" to "software company doing metal." This means owning your software assets like you own your machines, investing in technical skills, treating code as infrastructure, building modular architectures, and accepting that software complexity is now a core competency—not an IT problem to outsource.

Most metalworking companies I speak do describe themselves the same way:

"We're a metal company. We use some software here and there."

But if you look closely at how they run today, the reality is already very different.

Production planning depends on ERP. CAM and nesting are fully digital. Quoting is done from spreadsheets, CAD, or custom scripts. The whole operation stops if "the system" is down.

In other words: They already behave like software companies – they just don't manage themselves like one.

The Real Shift: Identity, Not Tools

The next decade will separate two types of players in metal:

• Companies that use more and more software on an ad-hoc basis.
• Companies that become software-first organizations that happen to bend and cut metal.

That’s not a marketing slogan. It’s a practical shift in how you think about your factory.

Most teams think the problem is:

• "Our ERP is outdated."
• "We need a better MES."
• "We should integrate CAD/CAM with ERP."
• "We need more automation."

Those are all valid projects. But they’re not the root problem.

The real issue is this:

You’re not in control of the software you already depend on.

As long as that’s true, every new integration, every new automation, every new tool… just adds another layer of fragility on top of an unstable foundation.

How Most Metal Companies Work Today (And Why It Breaks)

Let me describe what I see in most shops – including the one I once worked in as IT manager.

You might recognize parts of this.

1. No complete picture of the software landscape

• No up-to-date list of systems and tools.
• No visual map of how they’re connected.
• No clarity on which data flows where.
• Nobody really knows where all the critical databases are.

When something breaks, people start asking around:

“Do you know where that script lives?” “Who set this up originally?” “Can we change this without breaking something else?”

2. Consultants change things, but nobody owns the result

• External consultants adjust scripts on some shared drive.
• If it “works”, everyone is happy… and nobody documents what changed.
• There’s no version control, no changelog, no rollback strategy.

You’re effectively betting your factory on the memory of one or two individuals.

3. Changes are made directly in production

• There is no test environment.
• New versions of scripts or integrations are deployed directly on the live system.
• Everyone hopes it will work and that downtime will be minimal.

Hope is not a strategy, especially when your machines and people depend on digital workflows.

4. Backups exist… but nobody knows if they are usable

• “Yes, we do backups.”
• But:

You only find out what your backup is worth when it’s too late.

5. Logging exists, but nobody looks at it

• Every tool has its own logging method.
• Integrations fail silently.
• When something stops working, people start digging through 5–10 different log files, each in a different format.

No one has a single place to see the health of the whole digital chain.

If You Want To Be Software-First, Start With These 4 Basics

If you want to become a software company that does metalworking, you don’t start with AI, fancy dashboards, or the next big platform.

You start with four very boring, very powerful foundations.

Think of them as the minimum operating system for a software-first metal company.

1. Software Asset Management: Know What You Have

At minimum, create an inventory of:

• All tools and systems you use
• All integrations between those systems
• Versions, licenses, and suppliers
• The underlying databases

Then go one step further:

• Draw an architecture or process diagram:

This isn’t IT decoration. It’s the only way to have an honest conversation about risk, improvement, and automation.

2. Version Control + OTAP: Stop Hacking Production

Any custom code that connects systems or automates workflows should:

• Live in a version control system (e.g. Git).
• Be stored centrally (e.g. GitHub, Azure DevOps, etc.).
• Have clearly documented ownership and purpose.

Ideally, this includes:

• Scripts and customizations around ERP, CAD, CAM.
• Any glue code between tools.

Then, separate your environments:

• Development – where changes are created.
• Test – where you validate technically with realistic data.
• Acceptance – where key users test if it works in practice.
• Production – where the factory runs.

If a vendor charges extra licenses for a test environment, that’s a red flag in 2025.

Without OTAP, you’re effectively experimenting on your live factory.

3. Observability: See Problems Before the Factory Feels Them

You don’t want to learn about system problems from the shop floor.

“The nesting didn’t arrive.” “The work preparation is stuck.” “We can’t send quotes.”

Most tools have some kind of logging. But if each system and integration logs in its own way, to its own place, nobody will proactively watch it.

Instead, move towards:

• A standardized way of logging (for example, using a common format or framework like OpenTelemetry).
• A central place where:

This lets you act before production is impacted.

4. Automated Deployment (CI/CD): Change Without Fear

Finally, make sure all your custom software can be:

• Automatically deployed.
• Automatically rolled back to a previous, working version.

This usually means:

• A pipeline that builds, tests, and deploys your code.
• One button (or automated rule) to:

Tools like Azure DevOps, Octopus, or others are built for this. The names don’t matter—that this discipline exists does.

The goal is simple:

You should never have to wake up a specialist at night to manually fix a deployment.

If your factory depends on software, then the way you deploy that software is a critical process – just like machine maintenance.

Why This Matters: From Hope-Driven to Control-Driven Operations

Put these four basics together and a pattern emerges:

• You know what you have → you can manage it.
• You control changes → you can improve safely.
• You can see what happens → you can prevent failure instead of just fixing it.
• You can deploy reliably → you can innovate without fear.

Only then does it make sense to talk about:

• Automated quoting,
• Self-service portals for customers,
• Fully integrated inquiry → calculation → order → production flows,
• Truly scalable digital operations.

Without this foundation, every new integration is a gamble. With it, you’re operating like a real software company that happens to run a metal factory.

Average vs. Leading Teams

Here is the most important contrast I see: Average teams

• Add new tools when problems appear.
• Let consultants “handle the tech”.
• Tweak live systems until something breaks.
• Rely on hope and heroics.

Leading teams

• Treat software as a core asset of the business.
• Demand structure, version control, and test environments.
• Invest in observability and automated deployment.
• Build their automation on top of a strong foundation.

Quotation Factory works with companies in that second group – or those who consciously want to move there.

Because only in that world does automating your inquiry-to-order and quoting process really scale.

Where to Start

If this feels overwhelming, start small:

• Make a simple list of all systems and tools in your factory.
• Add the integrations between them.
• Highlight what is business-critical if it fails.

That alone will already change conversations internally.

If you’d like a sparring partner on how to take the next steps towards a software-first metal company, feel free to send me a message here on LinkedIn.

I’m always happy to look at your landscape and think along.