From prototype to operation: What really makes industrial software hold up

The proof of concept is running. Data from one machine lands in a dashboard, the model detects the first anomalies, the presentation is convincing. Six months later, the project has gone quiet. Nobody knows who runs it, the architecture can’t handle a hundred machines and the code sits on a laptop.

This happens often. It is rarely the algorithm’s fault. Usually, what is missing is the path from prototype to operation. This article shows which decisions shape this path and when you should make them.

Architecture based on requirements

Not every project needs a platform for a thousand devices from day one. That is why we design the architecture to fit the requirements.

Lean, when a PoC or MVP should bring clarity quickly. Then what counts is the question the prototype has to answer. Few components, short paths, deliberate shortcuts. It is important to document these shortcuts. Otherwise, they turn into legacy problems later.

Scalable from the start, when a large rollout is planned. Then multi-tenancy, roles and permissions, a clean data model and automated deployments belong in the first version. Retrofitting costs more than planning ahead.

What matters is that this choice is made deliberately. The transition from lean to scalable is a planned step, not an accident.

Edge, cloud or web

Industrial software rarely runs in just one place. At the edge, close to the machine, what counts is low latency, preprocessing and operation even without a stable connection. The cloud is where fleet-wide analyses run, models are trained and everything lives that has to grow with the number of machines. On the web, operators, service and management see their data without installing anything.

Usually, all three work together. The edge prepares data and sends it via MQTT, the cloud aggregates it, a web app shows the result. We plan this interplay from the start, even if the pilot only needs one layer.

Two-week sprints with working increments

We develop in two-week sprints. At the end of each sprint, there is a working interim version that you review with your team. Not a slide deck, but software you can try out.

This has three effects:

1. You see early on what is being built. Misunderstandings come to light after two weeks, not after six months.
2. You help steer. Priorities can be adjusted after every review when requirements change.
3. Risks become visible. An interface that doesn’t deliver or data that isn’t fit for purpose shows up in the first sprint in which it is needed.

For us, “done” means tested, documented and automatically deployable. The code is versioned in Git, tests run in a CI/CD pipeline and the infrastructure is described as code. This makes every version reproducible.

A prototype proves that something works. Operation proves that it holds up.

The source code is yours

You get the source code, the documentation and the pipelines used to build and deliver the software. It can be operated by us, by you or by a third party.

This is not a formality. Machines and plants are often in use for many years, and so is the software that runs on them. During this time, teams, service providers and priorities change. Whoever owns the code and can build it stays in control. Where it makes sense, we use open source components and open standards such as OPC UA and MQTT. This keeps your solution interchangeable.

Plan for operation from the start

A system in the field needs care. If you only plan operation after the rollout, you plan it under pressure. That is why four topics belong in the architecture from the beginning.

Monitoring

You should know about a fault before your customer calls. This requires metrics, central logs and alerts. Not only for servers, but also for edge devices and data flows: is the data arriving, and is it up to date?

Updates

Operating systems, libraries and containers need regular security updates. For a fleet of edge devices, that means OTA updates, rolled out in stages, with the option to roll back.

Backups

A backup is only as good as the last successful restore. That is why fixed backup intervals, separate storage locations and regular restore tests are part of it.

Response times

When a fault occurs, it must be clear who responds and how quickly. Fixed response times and a clear escalation path should be agreed before the rollout, not after it.

If you wish, we take over this operation for you: monitoring, updates, backups and fixed response times for faults.

From pilot to rollout

We start with a manageable pilot. One use case, real data, a fixed timeframe. At the end, there is a measurable result. Only when the pilot works in day-to-day operation do we roll out to further machines and sites.

Before you take the step from pilot to rollout, it is worth looking at five questions:

1. Which question did the pilot answer, and how will you measure success in the rollout?
2. Can the architecture handle the planned number of machines, sites and users?
3. How do updates get onto the devices in the field?
4. Where is the source code, and who can build and deliver it?
5. Who operates the solution, and what response time does your operation need when a fault occurs?

If you can answer these questions, your project is ready for operation. If not, now is the right time to clarify them.

You can read how we bring architecture, development, AI and operation together on our Services page. If you are facing exactly this step, get in touch.