Make-or-buy in manufacturing IT: Why supposedly cheaper in-house development often results in high follow-up costs

In many manufacturing companies, Excel is considered a particularly flexible and cost-effective solution for evaluations and simple process support. Licenses are available, the tools are familiar, and BI tools can be used to create meaningful visualizations. This quickly gives the impression that a homemade solution could completely replace an MES.

However, this often reduces the decision to the initial effort involved. In fact, it is a strategic choice between short-term adaptability and long-term process reliability, especially when solutions transition into regular operation and grow beyond individual use cases.

Image: Sample illustration

The risks of shadow IT growth

Homegrown solutions often arise from a understandable impulse. A specific problem arises, a quick solution is needed, and a capable person implements a tool that initially appears to work reliably. Over time, however, this often develops into shadow IT that is difficult to control because the solution is gradually expanded without considering maintainability, governance, and scalability from the outset.

A typical weak point is dependence on individuals. Homegrown systems are often closely linked to the knowledge and availability of individual employees, for example when complex VBA logic or special data processing methods grow organically over many years. If this person is absent or leaves the company, a supposedly inexpensive solution becomes an operational risk because changes, troubleshooting, and further development are not reliably secured.

Added to this is the integration gap. Excel and BI tools are very good at preparing and visualizing data, but they are only of limited use when it comes to consistently recording data, managing processes, and mapping traceability in an audit-proof manner. In practice, machine data and manual entries must converge, and a reliable data basis is needed for control and verification. If this integration is not handled properly, data silos and media breaks arise, which cost time in everyday work and undermine data quality.

What an integrated platform typically does

One common objection to choosing a platform is that standard software cannot adequately map specific processes. This argument falls short when modern platform approaches are understood not as rigid products, but as adaptable foundations.

A platform approach usually provides stable basic components, including data storage, interfaces, user and rights management, and security mechanisms. Building on this foundation, applications for worker guidance, quality control, or feedback can be configured and developed in line with processes without having to rebuild the basic infrastructure each time.

Decision criteria for practice

Criteria directly related to everyday production help to classify products objectively.

Audit security and traceability

When there are documentation requirements, such as who recorded which measurements at which station, spreadsheet solutions quickly reach their limits. What is crucial is a traceable, tamper-proof history of transactions that can also be reliably explained under audit conditions.

Scalability in rollout

A solution for an isolated area may work in the short term. However, as soon as multiple lines, shifts, or locations need to be consistently served, the effort and susceptibility to errors increase significantly, especially when it comes to versioning, permissions, interface maintenance, and uniform processes. Platforms are typically designed to support such rollouts in a structured manner.

Real-time capability in control systems

Many evaluations are delayed and are primarily suitable for analysis. If operational interventions are necessary during the current shift, data streams, status logic, and alarms become more important than downstream reports. Here, the architecture determines whether control is actually possible in real time or whether deviations only become visible once they have already taken effect.

Conclusion

In-house development remains a sensible option for prototypes, one-off analyses, or clearly defined, non-business-critical sub-processes. However, as soon as solutions are operated on a permanent basis, need to be scaled, or have to meet compliance requirements, the cost and risk structure shifts. Maintenance, troubleshooting, dependencies, and a lack of future security then often outweigh the license costs saved.

Are you interested in an MES?

When weighing up the pros and cons of in-house development and a platform, it is worth taking a structured look at process criticality, rollout prospects, and verification requirements. Selfbits helps you evaluate these criteria in line with real manufacturing processes and derive a robust implementation strategy.