Make or Buy: Build or Purchase Software for Work Instructions and Checklists?

Vibe coding is everywhere right now. AI tools, low-code platforms, and a growing wave of tutorials have made building your own software application feel more accessible than ever. The message is tempting, and it is not wrong. But it is reviving an old question with new urgency: should we build or buy our software for work instructions and checklists?  

As Head of Product at Operations1, I keep encountering this question: in initial conversations, in ongoing projects, sometimes just before a contract is signed. I take it seriously, because it is more legitimate today than it was just a few years ago. A working niche tool for a clearly defined use case can be built faster today than ever before. 

But the same conversations reveal a consistent pattern: once the solution needs to scale beyond that initial use case, to other areas, plants, or processes, in-house development runs into a wall. That is why I want to look at this question carefully. 

When is in-house development the right answer? 

The honest answer is: it depends. There are scenarios where building in-house is the right call. A company with a strong internal IT department, a clearly defined use case, for example a single inspection line in one plant with no plans to scale, and requirements that no standard solution covers: in that case, it is legitimate to consider in-house development.  

Three criteria where “Make” is the better choice: 

• The requirements are so specific that no available standard solution covers them. 

• IT capacity is permanently available — not just for the initial build, but for operation, maintenance, and further development over years. 

• The use case remains narrowly defined and is not intended to scale to other areas, plants, or processes. 

 Anyone who can answer yes to all three points does not need to read on. For everyone else, it is worth taking a closer look at what is almost always missing from the "Make" calculation. 

What does the IT department not build instead?

That is the most expensive question in the make-or-buy decision. And yet it is almost never asked. 

IT capacity that flows into rebuilding standard software is missing from projects that create real competitive advantages. While in-house development matures over months, a standard solution delivers measurable value from the very first productive use case. What is at stake is illustrated by an example from my own project experience: Quantum Systems, a German drone manufacturer, increased its output by 300 % within twelve months after introducing Operations1, without tripling its workforce. The lever was the standardization of shopfloor processes, not capacity. At the same time, the error rate dropped from over 50 % to under 2 %. That result would not have been achieved if the IT capacity had gone into in-house development instead. 

The missed value-add is invisible: the in-house solution is measured against its original goal and is therefore considered a success. The upside that a standard solution would have unlocked is invisible: it never shows up in any report. 

What does running an in-house development really cost?

There is a moment in every in-house development project where the first digital checklist goes live and the room feels like a success. That feeling is premature. Operation, maintenance, further development, error handling, scaling to other areas: none of that was in the original brief, and all of it is coming. 

What is almost always missing from the full-cost calculation for in-house development: 

• ongoing support and troubleshooting, 

• further development for new requirements, 

• failover and hosting, and 

• opportunity costs of tied-up IT capacity. 

 A standard solution includes all of this from day one. In-house development, by contrast, is never finished – it is a permanent project. 

Why is maintaining shopfloor software harder than building it?

Work instructions and checklists are not static content. They must be updated whenever a product, a standard, or a process changes. That sounds simple, but it is not: every change must be manageable by the responsible specialist departments themselves, without an IT ticket, without developer capacity. Anyone who does not build this into the architecture from the start creates a bottleneck that becomes more expensive with every change. 

In-house developments also face a structural problem: they are niche solutions. What was built for assembly rarely fits quality inspection, maintenance, or audits. Every new area brings its own requirements. In practice, these are simply stacked on top rather than clarifying upfront what the solution needs to deliver overall. The result is a grown custom solution with increasing complexity and decreasing maintainability. 

Operations1, for example, is fundamentally different in this regard: the platform was designed from the outset for different processes, from assembly through quality inspection to maintenance. Adding a new area there is a configuration task on a shared data model, not a new development project. 

There are two additional points that are almost always underestimated in in-house development: 

• Reusable building blocks, where a single change takes effect everywhere, must be designed, built, and maintained from scratch. Without this modularity, the same information is maintained multiple times over. 

• Displaying only the relevant steps per product variant instead of maximum lists is precisely the part that relieves the worker most. 

What a standard solution brings that cannot be built in-house

An in-house development solves the problem that the requesting department has just articulated. A standard solution, by contrast, brings the knowledge of how that problem is best solved, based on use across hundreds of companies. That knowledge is already embedded in the product. It does not need to be earned through trial and error. 

Anyone who quickly builds something out of an acute requirement from a single department covers exactly that requirement, nothing more. Adjacent potential, such as analytics, reuse of modules, qualification logic, or write-back to the ERP, is often not seen. 

There is also an aspect that rarely comes up in the make-or-buy discussion: access to a user community. The clearest illustration I know comes from our Future Manufacturing Summit, where this plays out every year: customers who use the same solution exchange experiences there, learn from each other, and jointly develop approaches to problems they all know. Anyone who builds in-house stands alone. 

Support is not a minor point either. Anyone who builds in-house also takes on the support in-house. I can quantify what that means from our own organization: Operations1 offers its customers personal support with a customer satisfaction rate of 97.1 % (as of August 2026). An internal IT department does not achieve that level as a side task, and that is not a criticism: it is simply not their core responsibility. 

Audit compliance: why in-house development becomes an audit risk

If a system cannot demonstrate in an audit who approved which version and when, that is a risk, regardless of whether the software was purchased or built in-house. 

For in-house development, this means: cleanly mapping multi-stage approval workflows (such as review by the specialist department, quality, and plant management) is complex. It takes more than an approval checkbox: unique record IDs, linking each record to the document version used, and re-opening completed records only with a mandatory reason and revision flag. In in-house development, this part is almost always deferred because it does not seem urgent in the first version. In an audit, it is mandatory. 

The pattern that follows is predictable: where the in-house solution does not track approvals cleanly, changes revert to email and Excel. The exact situation that was meant to be eliminated returns through the back door. 

In a mature standard solution, this logic is included from the start, because hundreds of customers have needed it in audits and have long since demanded it. This argument clearly favors the standard solution. 

Building in-house does not result in more independence

In-house development shifts the dependency inward. While an in-house solution can be set up so that specialist departments manage their own content, functional development, architecture decisions, and bug fixes remain the responsibility of internal IT, which must handle this work alongside its other projects. 

There is also a key-person risk: in-house solutions frequently depend on the knowledge of individual developers, whose departure puts maintainability at risk. For a solution to remain maintainable over years, it needs a solid architecture, tests, and documentation. That effort is missing from many initial calculations. 

New requirements such as AI features or ERP integrations would need to be built by internal IT each time, and each of those features becomes its own project with its own budget. A long-term coherent development roadmap, where each new version contributes to a clear vision, is barely achievable under these conditions. 

With a standard solution, this is the norm: features already built for other customers become available via update. From my own work, I know how much effort goes into this: in the Operations1 product team, we maintain a roadmap that every new version is aligned to. That continuous, planned evolution is exactly what you buy into. 

What comes after the first version: integration, security, compliance

Keeping ERP and MES connections production-ready and stably maintained is a project in its own right. And new regulatory requirements around documentation and audit trails must be continuously incorporated. That ties up capacity with no end date. 

The difference is especially clear when it comes to information security and data protection. The requirement is the same for both sides: secure hosting, protection of manufacturing and quality data, demonstrable security standards for customers and auditors. The difference lies in who runs this work as their core business. 

For a manufacturing company, information security for self-developed software is a permanent task alongside the actual business: certifications such as ISO 27001 must be earned and defended in annual audits, security vulnerabilities must be continuously monitored and closed, and every new customer requirement for audit trail documentation lands back with internal IT. For a software vendor, that is exactly the core business. At Operations1, we have built this competence in-house: the platform is certified to DIN EN ISO 27001 and operated in the Microsoft Cloud with EU hosting. That security standard goes beyond what a manufacturing company can economically achieve for an internally developed standalone solution. 

Shopfloor software fails not only on features, but also on poor adoption

A solution that workers do not accept gets bypassed. The result: the entire business case evaporates. 

Shopfloor-level usability does not happen as a side effect; it is a discipline in its own right. An interface that every worker operates without prior knowledge is the result of UX expertise, research, and testing: observation directly at the workstation, analysis of where workers get stuck in the process, which interactions cost too many clicks, and which wording is misunderstood. Systematically eliminating these friction points is the work of designers and UX researchers, not developers. 

Here, a standard solution has an advantage that no internal IT, however capable, can match: scale. From my work in the product team, I know how much of our UX quality comes from testing improvements across many customer projects in parallel. Every friction point noticed in one plant is eliminated for all customers. An in-house development has exactly one test customer: its own plant. 

There is also the question of competence. A software vendor employs UX expertise in-house because it is their core business. In a manufacturing company, that role is typically not part of the setup at all, and that is perfectly fine, because different know-how is needed there. 

Image and video support, with which work preparation can create multimedia instructions independently, is also a prerequisite for comprehensibility and is often not considered in in-house development. 

Knowledge retention: where in-house development hits structural limits

Knowledge retention is often underestimated in the make-or-buy discussion, even though it is one of the biggest levers against the skilled labor shortage. When experienced specialists retire, decades of assembly and process knowledge leave the company. Declining applicant numbers and shorter tenures make the problem worse. Anyone who does not externalize tacit knowledge in time loses it permanently. 

Making tacit knowledge reusable only works if the barrier to documentation is low. With Operations1, for example, existing instructions from PDF, Word, Excel, or PowerPoint can be automatically converted into structured digital documents via AI. Photos and videos are captured directly at the workstation and embedded in the work steps: an experienced assembly technician demonstrates a hand movement once on camera instead of describing it laboriously. And knowledge that arises from solving concrete problems on the shopfloor is documented, professionally validated, and made available via AI retrieval the next time a comparable case occurs. 

In an in-house development, each of these tools would need to be individually designed, built, and maintained. 

An example from my project experience: Liebherr-Verzahntechnik secured the experience of 83 employees retiring due to age and documented it for the workforce using Operations1. Combined, that amounts to approximately 1,200 years of professional experience.

A fair comparison: Operations1 vs. in-house development 

How can the decision be calculated rigorously?

Anyone who needs to justify the make-or-buy decision internally needs numbers on both sides. 

For in-house development, the calculation is harder than it initially appears. Development costs are tangible, but follow-on costs are not: how much IT capacity does ongoing operation permanently tie up? What does continuous further development cost as new requirements come in from specialist departments? And what could have been done with that capacity alternatively? Anyone who does not factor in these opportunity costs systematically underestimates in-house development. 

For a standard solution, the calculation is more transparent. License costs are clearly defined. The expected benefit can be quantified in a structured way: hours tied up in documentation maintenance, onboarding effort per new employee, error costs from outdated instructions. If you choose Operations1, the time-to-value is also calculable: with a guided onboarding project, the first use case is live within 8 weeks. 

For those who want to work through the numbers: the interactive ROI calculator from Operations1 makes the relevant levers for your own operation explorable. For those who prefer to see the solution before calculating: the self-guided product tour provides a complete overview, entirely without a sales conversation.

FAQ: Build or buy software for work instructions and checklists?

What does it cost to build a tool for digital work instructions in-house?

The costs for a first functional version are low today. Low-code tools and AI-assisted development enable first versions within a matter of days. The real costs come after: ongoing operation, maintenance when processes change, further development for new requirements, hosting, security, and support. These follow-on costs typically far exceed the initial development and are difficult to predict. 

How long does it take to build a tool for work instructions or checklists in-house?

A first functional version for a single use case can be built via vibe coding in a matter of hours. A production-ready solution with approval workflows, audit trail, and stable ERP interfaces typically requires several months of development work. In addition, the solution is never truly finished: new requirements, process changes, and regulatory requirements demand continuous further development. 

Which requirements are typically underestimated when building a work instruction tool in-house?

Audit-compliant versioning with a complete audit trail, multi-stage approval workflows, and stable ERP or MES connections. These requirements do not seem urgent in the first version but are mandatory in production use. 

Can I build a checklist tool with low-code or AI?

Yes, a first functional version. Low-code tools and AI enable fast first versions, but they are generic. A specialized tool for the shopfloor is designed from the outset for the specific requirements of manufacturing: variant logic, qualification management, audit-compliant documentation, and integration into existing manufacturing systems. Mapping this domain logic in a low-code tool amounts to a full in-house development, with all the follow-on costs that entails. 

How does audit compliance work for digital work instructions?

Audit compliance requires more than a timestamp. What is needed: unique document versions, linking every completed record to the document version valid at the time, a complete approval workflow with traceable approver information, and regulated processes for re-opening completed records. Mature solutions cover these requirements out of the box. In in-house developments, this part is frequently omitted and only becomes visible as a gap during an audit. 

When does it make sense to build your own work instruction tool in-house?

In-house development is worthwhile when all three of the following conditions are met: 1) The requirements are so specific that no available solution covers them. 2) IT capacity is permanently available for operation and further development, not just for the initial build. 3) The use case remains narrowly defined with no intention to scale to additional areas or locations. If even one of these conditions is not met, the follow-on costs and risks of in-house development generally outweigh the benefits. 

What happens to existing Word and PDF documents when switching to a digital tool?

Existing work instructions from Word, Excel, PDF, or PowerPoint do not need to be recreated. Mature solutions offer import functions that read existing documents, recognize work steps, text, and images, and generate editable digital instructions from them. In in-house developments, migrating existing documentation is a separate sub-project that is rarely planned for in the initial phase.