Industrial software, built for a plant that does not stop for your deployment.
Data acquisition, quality and maintenance systems engineered around equipment that cannot be replaced, safety systems that must not be touched, and downtime measured in money per minute. This is a custom engineering practice rather than a product catalogue, and we say so plainly.
Custom programme - scoped and quoted in writing
No off-the-shelf track in this sector
There is no ready-made track in this sector, so every engagement is a custom programme, scoped and quoted in writing before anything starts. Custom builds elsewhere on this site run two to eight weeks; work at this scale is quoted beyond that. Every figure on this page is defined on our facts page.
What an industrial build actually contains
The sequence below is where industrial programmes are won or lost. Unlike most sectors on this site, none of it starts from a shipped platform, and the page is written accordingly.
Industrial software differs from every other sector we work in on one point: the system you are integrating with is physical, it is already running, and it was commissioned by people who are no longer at the company. A defect does not produce a bad user experience, it produces scrap, a stoppage, or in the worst case a safety event. That changes how the work is sequenced, how much of it happens before any code is written, and what "done" means.
There is no shortcut track here. What varies is how much of your plant is already instrumented, and that is discovered in the first phase rather than assumed.
Plant survey: what exists, and what may be touched
This phase happens on site, with the people who run the equipment, and it takes longer than software teams expect. What controllers are installed, what protocols they speak, what is already logged, what documentation still matches reality, and critically which systems are safety-rated and therefore outside the scope of anything we build.
Equipment in industrial settings routinely outlives several generations of software. A line running controllers commissioned twenty years ago is normal rather than exceptional, and the answer is to read from them rather than to propose replacing them.
The output is a survey document naming every data source, its protocol, its reliability, and a clear boundary around what will not be modified under any circumstances.
The operational boundary and data acquisition
The line between operational technology and business systems is the most important architectural decision in this sector, and it is a safety and availability decision before it is a security one. Control systems must continue running if everything above them fails, which means data flows out and commands do not flow in without deliberate, reviewed exception.
Acquisition itself is unglamorous engineering: polling controllers without loading them, handling protocol quirks per vendor, timestamping consistently when device clocks disagree, and buffering locally so a network interruption does not lose an hour of production data.
Edge processing belongs here where bandwidth or latency demands it, particularly for vision applications where sending raw video off site is neither practical nor necessary.
The data pipeline and what a reading actually means
Industrial data arrives at high frequency, irregularly, and with more missing and implausible values than most teams anticipate. A temperature sensor reporting a physically impossible value is a fault to detect, not a number to average. Cleaning and validating at ingestion is what makes everything downstream trustworthy.
Context is what turns readings into information. A vibration measurement means nothing without knowing which machine, which product was running, which shift, and what the machine state was at that moment. Joining process data to production context is most of the value in an industrial data platform.
Retention deserves an explicit decision: high-resolution data is expensive to keep and occasionally essential to have, so aggregation policy is designed rather than defaulted.
Applications: quality, maintenance and traceability
This is where the programme produces value, and the applications are specific rather than generic. Quality inspection using vision to catch defects a human inspector would miss at line speed. Condition monitoring that predicts a bearing failure before it stops the line. Genealogy that traces a finished unit back through every component, batch and process parameter that produced it.
Traceability deserves emphasis because it is the capability that pays for itself during a recall. Being able to identify precisely which units were affected, rather than recalling a month of production, is the difference between a contained problem and an expensive one.
Vision applications need care in how they are positioned: a model that flags suspect units for human confirmation is a useful tool; one that rejects automatically without recourse creates scrap when it drifts.
Business system integration
Production data becomes commercially useful when it reaches the systems that plan, cost and sell. Work orders arriving from the planning system, confirmations returning with actual quantities and scrap, and inventory movements posting correctly are what close the loop between the floor and the business.
These integrations are governed by the enterprise system's own release and validation process, which is usually slower than the plant work and controlled by a different team. Sequencing that dependency early is the difference between a programme that lands and one that waits.
We build to the interfaces the enterprise system supports rather than around them, because unsupported integration becomes an upgrade blocker the first time the vendor patches it.
Rollout across lines and sites
One line first, proven through a full production cycle including a changeover and a planned maintenance window, because those are when assumptions break. Only then the rest of the site, and only after that other sites.
Plants that look identical on paper are not. Different vendors for the same machine type, local modifications made over years, and operating practices that differ by shift all mean the second site is a smaller project rather than a copy.
Operator adoption decides whether any of it produces value. A system the floor works around is worse than no system, because it produces data nobody trusts.
Handover and day two
Industrial systems outlive the teams that build them, so handover is documentation, runbooks and training rather than a deployment. Your maintenance staff need to diagnose a stalled data feed at two in the morning without calling us.
Day two includes the first quality event where the system is consulted rather than the usual process, which is when trust in it is actually established. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want any of these phases costed against your plant and existing instrumentation?
Book a technical callWhere the boundary actually sits
Every industrial programme lives or dies on this line. Data crosses it outward. Commands cross it inward only by deliberate exception, and safety systems sit entirely outside anything we build.
A vendor proposing to write setpoints back to controllers as a standard feature has not worked in a plant. The value in industrial software is overwhelmingly in reading, contextualizing and deciding; the writing back, where it happens at all, is a separate conversation with the people responsible for the process.
Why downtime changes how software is deployed
In most sectors a deployment goes out, something breaks, it is rolled back, and the cost is measured in inconvenience. On a production line the same sequence costs a quantifiable amount per minute, and on a continuous process it can cost considerably more than that because restarting is not instantaneous.
That reality shapes the engineering rather than sitting beside it. Changes land in planned maintenance windows that may be weeks apart. Anything touching acquisition is proven on a single line first. The platform is built so that its own failure is invisible to production, because a system that can stop the line will eventually stop the line. None of that is caution for its own sake; it is what makes the plant willing to let software near the process at all.
Want your operational boundary reviewed before anything is specified?
Talk to an engineerEight operators, eight different programmes
"Manufacturing" is not one buyer. The process, the regulatory weight and the cost of a stoppage change completely between them.
Discrete manufacturing
Countable units through defined stations. Genealogy and station-level quality dominate, and traceability is what contains a recall to a batch rather than a month.
Custom programme
Process manufacturing
Continuous flow measured in volume rather than units. Restarting is expensive and slow, which raises the cost of any disruption and narrows deployment windows further.
Custom programme
Automotive and tier suppliers
Customer-mandated quality systems, traceability requirements imposed by the buyer, and delivery schedules with penalties. The customer often dictates the standard you must meet.
Custom programme
Food and beverage production
Hygiene regimes, allergen controls and shelf-life traceability, with equipment washed down regularly which constrains what hardware can be installed near the line.
Custom programme
Pharmaceutical manufacturing
Validated environments where the software itself is subject to qualification, and a change carries documentation weight far beyond the code. Schedules are set by that process.
Custom programme
Heavy industry
Large assets, long maintenance cycles and condition monitoring where a failure is measured in weeks of lost output rather than hours.
Custom programme
Contract manufacturers
Many customers on shared lines, which makes segregation of data and per-customer reporting a first-class requirement rather than a later feature.
Custom programme
Industrial equipment makers
Building connected products rather than running a plant. The engineering is embedded and the business model shifts toward service, which changes what the software must support.
Custom programme
None of the eight starts from a shipped platform, because we do not have one for this sector and adapting a consumer product to a plant floor would be worse than starting properly. The capability below is what we bring instead.
Not sure which of these you are, or you sit across two of them?
Book a scoping callHow the work actually runs
Six stages. Unlike every product-backed sector on this site, there is no second track, so the stages describe the only path there is.
On-site survey before any specification
We walk the floor with the people who run it, before writing a line of specification. What is installed, what it speaks, what is already logged and what documentation still reflects reality. This stage is longer than clients expect and it is the one that prevents the expensive surprises during commissioning.
Architecture around availability
The boundary is set first: data outward by default, commands inward only by reviewed exception, safety systems untouched. The platform is designed so its own failure is invisible to production, because a system capable of stopping the line eventually will.
Build against real plant data
Industrial programmes fail on assumptions about data quality. Development runs against captured plant data including the awkward parts: sensors dropping out, clocks disagreeing between devices, implausible readings, a changeover mid-batch, and a network interruption that buffered two hours of production. Synthetic clean data proves nothing here.
Depends on existing instrumentationSecurity and qualification review
Boundary controls reviewed with your operational technology owners, and where you operate in a validated environment, the qualification documentation the process requires. Our work arrives with a VAPT and compliance document so external review starts from a documented baseline rather than a blank page.
One line, through a full cycle
Commissioned on a single line and proven across a complete production cycle including a changeover and a planned maintenance window, because those are the moments assumptions break. Operators use it in anger before anything is rolled wider.
Rollout, handover and day two
The rest of the site, then other sites, each treated as a smaller project rather than a copy. Handover is runbooks and training, because these systems outlive the teams that build them. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want this sequence mapped against your plant and maintenance calendar?
Book a technical callWhat we bring to this sector
There is no shipped platform here, so this section replaces the product catalogue you will find on our other industry pages. These are the five engineering disciplines this work draws on, each a practice we staff rather than a capability we claim.
It is worth being direct about why the catalogue is absent. Our shipped products are consumer and marketplace platforms, and adapting one to a plant floor would produce something worse than starting properly. Industrial work is a custom engineering engagement every time, and the honest version of this page says so rather than showing you a demo that does not apply.
Embedded systems
Device-level and edge engineering: acquisition from controllers, protocol handling per vendor, local buffering and processing where bandwidth or latency requires it.
Computer vision
Inspection at line speed, defect classification and measurement, deployed at the edge and positioned to support a human decision rather than to reject silently.
Data engineering
Ingestion at industrial frequencies, validation against physical plausibility, contextualization against production state, and retention policy designed rather than defaulted.
SAP engineering
Integration with the enterprise systems that plan and cost production, built to supported interfaces so the connection survives the vendor's next upgrade.
Microservices
Service architecture that isolates failure, so an application problem above the boundary cannot propagate downward and production continues regardless of what is broken.
All five together
Industrial programmes need most of these at once, which is the actual argument for a single engineering team rather than four vendors coordinating across a boundary none of them owns.
Want to know which of these five your programme actually needs?
Book a scoping callTraceability is the capability that pays for itself once
Most industrial investments are justified on efficiency. Genealogy is justified on the day you need it, and on that day the difference between a contained recall and a catastrophic one is whether the records exist.
This is why traceability cannot be added retrospectively. The facts have to be captured as the unit is built, because afterwards the association between a lot and a serial simply does not exist anywhere.
Want your traceability position assessed against a recall scenario?
Talk to an engineerWhat a custom programme covers
Since there is no product to adapt here, this is the full scope rather than the exceptions. These are the capabilities an industrial programme typically includes.
Acquisition and edge
Reading from controllers without loading them, handling vendor protocol differences, aligning clocks and buffering locally so a network fault does not lose production data.
Embedded systemsVision inspection
Defect detection and measurement at line speed, deployed at the edge, positioned to flag for human confirmation rather than to reject automatically as a model drifts.
Computer visionCondition monitoring
Vibration, thermal and current signatures interpreted against machine state, so a failure is predicted with enough notice to schedule rather than to react.
Data engineeringTraceability and genealogy
Component, batch, parameter and operator attached to every finished unit, captured during production because it cannot be reconstructed afterwards.
Data engineeringEnterprise integration
Work orders in, confirmations out, inventory posted correctly, built to supported interfaces so the connection survives the next upgrade of the enterprise system.
SAP engineeringOperator interfaces
Screens usable with gloves, in poor light, by someone who has three seconds. A system the floor works around produces data nobody trusts, which is worse than no system.
Custom software developmentNeed something this list does not cover?
Ask about custom workWhat we built, and what it delivered
Three programmes in this sector, described by what was actually built rather than by a metric we cannot show you the working for.
Discrete
Line acquisition with genealogy
Data read from controllers of three vendors and two decades, contextualized against production state, with component and parameter genealogy attached to every finished serial.
Quality
Vision inspection at line speed
Edge-deployed defect classification flagging suspect units for operator confirmation, with the model's own confidence exposed rather than hidden behind a pass or fail.
Integration
Floor to enterprise system
Work orders arriving from planning and confirmations returning with actual quantities and scrap, built to supported interfaces and sequenced around the enterprise release calendar.
We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's.
Want to speak to a reference running a comparable plant?
Request a referenceWritten on this sector
Longer pieces on the problems above, written by the engineers who run these programmes.
Why data goes out and commands rarely come back
DataA reading without context is not information
TraceabilityGenealogy cannot be added after the fact
RolloutWhy site two is never a copy of site one
If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your programme.
Want these as a briefing pack for your operations leadership?
Request the packThe first vendor sent us a specification without visiting. Half of it assumed equipment we replaced in 2011, and the other half assumed we would let software write to the line.
The failure pattern this page is built around
That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented.
Questions industrial buyers actually ask
The ones that come up in the first call, answered as we would answer them there.
Do you have a ready-made platform for manufacturing?
No. Our shipped products are consumer and marketplace platforms, and adapting one to a plant floor would be worse than starting properly. Industrial work is a custom engineering engagement every time, and we would rather say that than show you an irrelevant demo.
Do we own the source code?
Yes, in full, deployed on your infrastructure, frequently on premises. In this sector that matters more than most, because these systems outlive the vendors who build them.
Will you need to modify our control systems?
No. We read from them. Writing back to a controller is a separate conversation with your process owners, reviewed individually, and never a default. Safety-rated systems are outside scope entirely.
Our equipment is twenty years old. Is that a problem?
It is normal rather than exceptional. The survey establishes what each controller speaks and whether it can be read without loading it, and the answer is usually yes with the right approach.
Can this run if the network or the platform fails?
Production must continue regardless, and that is a design requirement rather than a resilience goal. Acquisition buffers locally, and nothing we build sits in the path of the process.
How disruptive is deployment?
Changes land in planned maintenance windows, one line is proven before anything is rolled wider, and rollback is planned before each change. The schedule follows your maintenance calendar rather than ours.
Do you work in validated environments?
Yes, with the qualification documentation the process requires, and with the understanding that a change there carries documentation weight far beyond the code itself.
Can vision inspection replace our inspectors?
We build it to support them rather than replace them. A model that rejects automatically produces scrap when it drifts, and drift is not always obvious until a batch has gone.
Will it integrate with SAP?
Yes, through supported interfaces rather than around them, because unsupported integration becomes an upgrade blocker the first time the vendor patches. That dependency is sequenced early because it moves slower than the plant work.
How many sites can you roll out to?
As many as needed, treating each as a smaller project rather than a copy. Plants that look identical on paper differ in vendors, local modifications and shift practices, and assuming otherwise is how schedules slip.
What does support look like after handover?
Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates, plus runbooks and training so your maintenance staff can diagnose a stalled feed without calling us.
What if we are not ready to build yet?
We will say so. If your plant is not instrumented and the appetite for installing sensors is not there, the software has nothing to read, and we would rather scope the instrumentation conversation first.
Question not answered here?
Ask us directlyTell us what you are building.
Bring the plant and the constraint. We will tell you honestly what is worth doing - including when the answer is instrumentation before software.
A first call takes about thirty minutes and covers four things
What runs today
Controllers, protocols, and what is already being logged.
What a stoppage costs
Which sets how conservative the deployment approach has to be.
What you need to know
Quality, downtime, traceability, or all three.
Existing systems
The enterprise and maintenance stack this must fit into.
Those four answers are usually enough for us to tell you what a programme would cover, roughly what it costs, and which of the five disciplines it actually needs. If the honest answer is that your plant needs instrumenting before any software is worth writing, we will say that instead of scoping a platform with nothing to read.
