Industry
Software engineering for Manufacturing
Manufacturing software lives where the factory floor meets the business, and that is the hard part: bridging operational technology (PLCs, SCADA, sensors, the machines themselves), with the business IT that plans, schedules and reports. On a production line downtime costs money by the minute, so the reliability bar is unforgiving. We build MES and shop-floor systems for that reality, respecting the OT world rather than treating it like another web API.
Why the domain matters
Manufacturing is where software stops being purely digital and starts touching physical processes that make real things at scale. A manufacturing execution system, the shop-floor layer that sits between the enterprise systems above and the machines below, has to reflect what is genuinely happening on the line: what is being made, on which machine, at what rate, with what quality, from which materials, in real time, and to do so reliably enough that people run a factory on it. The defining characteristic of the sector is that two very different technology worlds have to meet: operational technology, the PLCs, SCADA, sensors and machine controls that run the physical process, and information technology, the ERP, planning, quality and reporting systems that run the business. These worlds have different lifecycles, different reliability cultures, different security assumptions and often different vendors, and manufacturing software succeeds or fails on how well it bridges them.
The economics are unforgiving in a way that shapes everything. On a production line, downtime costs money by the minute (idle machines, idle people, missed output, sometimes spoiled work in progress), so the reliability standard for anything that can stop or disrupt the line is far higher than for typical business software. Overall equipment effectiveness, the sector’s core measure of how well a line is actually performing against its potential, quantifies exactly this: availability, performance and quality multiplied together, and every point of it has a cost. Software that improves OEE: by revealing where the losses are, scheduling better, catching quality problems earlier, or reducing unplanned stoppages, earns its keep directly. Software that is itself a source of instability or that the operators do not trust gets bypassed, and on a factory floor a bypassed system is worse than none, because it lies about the state of the line.
We are a senior-led team and we operate what we build, and we approach manufacturing with respect for the OT world rather than as another integration project. The recurring failure mode here is IT-minded software that treats a PLC or a SCADA system like a modern web service, ignores the timing and reliability realities of the plant floor, or assumes the operators will feed it data they have no time to enter. We would rather understand the physical process, the existing controls estate and the constraints the operators actually work under, and build the MES around that. The genuinely hard part is almost never the dashboard. It is bridging the operational and business technology cleanly, staying reliable on a line where a stall costs money, and earning enough trust from the floor that the data flowing up is real.
The challenges in manufacturing
Bridging operational technology and business IT
The defining difficulty of manufacturing software is that two worlds with different lifecycles, reliability cultures and security assumptions have to meet. OT (PLCs, SCADA, machine controls, sensors), runs the physical process and changes slowly and cautiously; IT (ERP, planning, quality, reporting), runs the business and changes constantly. An MES sits on the seam between them, and bridging it means respecting the OT world’s constraints rather than treating a controls system like a modern web API. Get this seam wrong and you either destabilise the line or build a business system that has no honest connection to what the machines are actually doing.
Reliability on a line where downtime costs money
Anything that can stall or disrupt the line carries a far higher reliability bar than typical business software, because the cost of a stoppage is measured in money per minute, idle machines, idle people, lost output, sometimes spoiled work. A shop-floor system cannot casually fail over and retry while the line waits; it has to be dependable, degrade gracefully, and never become the reason a machine stops. Designing for that reliability is core engineering here, not a non-functional afterthought, and underestimating it is how an MES loses the floor’s trust the first time it stalls production.
Legacy PLCs, SCADA and heterogeneous controls
The controls estate on a real factory floor is heterogeneous and long-lived: PLCs and SCADA systems of different ages and vendors, machines with proprietary interfaces, equipment installed decades apart that all has to be read and coordinated. New software has to talk to this estate as it is, not as a tidy standards diagram wishes it were, and any plan that assumes uniform modern connectivity ignores the machines the plant actually runs. Meeting the controls estate on its own terms is a large part of the real work, and where naive integrations quietly fail.
Data from the floor that is trustworthy and real-time
An MES is only as good as the data flowing up from the line, and that data has to be both real-time and trustworthy. Sensor readings, machine states, counts, downtime reasons and quality results have to be captured accurately, at the right cadence, without asking operators to key in data they have no time to enter. If the data is late, sparse or wrong, every OEE number, schedule and quality signal built on it is fiction, so capturing clean data automatically from the process (and earning the floor’s trust that it is right), is foundational, not incidental.
Quality and traceability that hold up under scrutiny
Manufacturing quality is not just pass or fail at the end; it is the genealogy of a product (which materials, batches, machines, settings and operators produced it), captured well enough to trace a problem to its source and, when needed, to support a recall. In regulated or safety-relevant manufacturing especially, that traceability has real weight. Building it means capturing the linkage continuously as production runs, not reconstructing it afterwards from partial records, because a traceability gap is exactly what turns a contained quality issue into an uncontained one.
Scheduling that survives contact with the real floor
Production scheduling looks like an optimisation problem and is really a negotiation with reality: machine availability, changeover times, material availability, labour, maintenance windows and constant disruption. A schedule that is optimal on paper but ignores changeovers, breakdowns or the operators’ knowledge of the line gets overridden and distrusted. Good scheduling software reflects the real constraints and re-plans sensibly when the floor changes, rather than issuing an idealised plan that the shift then quietly ignores, because a schedule nobody follows is worse than an honest rough one they do.
What we build for manufacturing
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
MES and shop-floor systems
The manufacturing execution layer between the enterprise systems and the machines: work orders and dispatch, real-time production tracking, machine and line status, materials consumption and shop-floor data collection, built to reflect what is genuinely happening on the line. We design the MES around the physical process and the controls estate as they actually are, and to a reliability standard fit for a system a factory is run on, because the MES is the honest picture of the floor and it has to be dependable before it is clever.
Industrial IoT and sensor integration
Capture of real-time data from the process (sensors, meters and machine signals), at the cadence and reliability the plant needs, feeding the MES with the clean, automatic data that makes everything above it real. We build this with respect for the timing and volume realities of industrial data and for the OT network it lives on, because the value of every dashboard, OEE figure and quality signal depends first on the integrity of the data coming off the machines, not on how the number is displayed.
OEE, performance and downtime analytics
Overall equipment effectiveness and the loss analysis beneath it, availability, performance and quality broken down so a plant can see where output is actually being lost and why, with downtime captured and reason-coded rather than guessed. We build these on trustworthy floor data so the numbers survive scrutiny from the people who run the line, because an OEE figure the operators do not believe changes nothing, while one they trust drives real improvement against losses that cost real money.
Quality management and traceability
Quality systems that capture inspections, non-conformances and corrective actions, and product genealogy that links each unit or batch to the materials, machines, settings and operators that produced it. We build the traceability continuously as production runs so a problem can be traced to its source and a recall scoped precisely, because in manufacturing the value of traceability is realised at the worst moment (the containment of a defect), and a linkage reconstructed after the fact is exactly the one that has gaps.
Production scheduling and planning
Scheduling that reflects the real constraints of the floor (machine availability, changeovers, materials, labour and maintenance), and re-plans sensibly when reality moves, rather than issuing an idealised plan the shift overrides. We build so the schedule earns the floor’s trust by respecting what the operators know about the line, because a plan people follow, even a rough honest one, delivers more than an optimal one they quietly ignore.
ERP integration and the OT/IT seam
The integration between the shop floor and the business, feeding production, consumption, quality and performance data up to ERP and planning, and receiving orders and material information down, engineered as the careful bridge between operational and business technology that it is. We treat this seam as first-class work, respecting the reliability and security differences between the two worlds, because a clean, trustworthy OT/IT bridge is the whole point of an MES and the place these projects are most often won or lost.
Where we help
Getting a real OEE picture a plant actually trusts
A plant that suspects it is losing output but cannot see where needs OEE built on trustworthy data rather than manual guesses. The real work is capturing machine states, counts and downtime reasons automatically from the process, reason-coding stoppages, and presenting the availability, performance and quality losses in a way the operators believe. Done on clean floor data, it drives genuine improvement against losses that cost money; done on sparse or keyed-in data nobody trusts, it produces a dashboard the floor ignores and the improvement never comes.
Wiring an MES into a heterogeneous controls estate
A factory with PLCs and SCADA of different ages and vendors needs an MES that reads and coordinates the machines as they actually are. This is OT integration first: meeting proprietary and legacy interfaces on their own terms, handling the timing and reliability realities of the plant floor, and never destabilising a controls system that runs the physical process. Get the integration robust and the MES reflects the true state of the line; get it naive and it either misreads the floor or, far worse, disturbs the machines it was meant to observe.
Building product genealogy for defensible traceability
A manufacturer that needs to trace any unit or batch to its materials, machines and settings (for quality, for customers, or for a possible recall), needs genealogy captured continuously as production runs. We build the linkage into the execution flow so every product carries its provenance, and so a defect can be traced to its source and a recall scoped to exactly the affected units. The value shows at the worst moment, when a well-built traceability system contains a problem precisely instead of forcing a broad, expensive recall because the records had gaps.
Scheduling that the shift actually follows
A plant whose paper or spreadsheet schedule is constantly overridden needs scheduling that reflects changeovers, material availability, maintenance and the operators’ knowledge, and re-plans when the floor moves. We build so the schedule is realistic and trusted rather than idealised and ignored, and so disruption triggers a sensible re-plan rather than an abandoned one. The measurable win is a plan the shift genuinely works to, because a schedule people follow delivers throughput that an optimal-on-paper plan nobody obeys never will.
How we build for manufacturing
We start with the physical process and the controls estate, not the dashboard. Before designing anything we want to understand what the line actually makes and how, what PLCs, SCADA and machines are on the floor, where the data genuinely comes from, and what constraints the operators work under. Manufacturing software designed from an idealised IT model rather than the real plant is the software that misreads the floor or gets bypassed, so we build from the process as it runs, not as a systems diagram imagines it.
We treat the OT/IT seam as the core of the work and resource it accordingly. Bridging operational and business technology means respecting two worlds with different lifecycles, reliability cultures and security assumptions, talking to a heterogeneous controls estate on its own terms, and never treating a PLC or SCADA system like a modern web API. We plan for the awkward interfaces, the timing realities and the reliability differences from day one, rather than discovering late that the business layer is finished but cannot honestly connect to the machines.
We build to the reliability standard a production line demands. Anything that can stall or disrupt the line has to be dependable, degrade gracefully and never become the reason a machine stops, because downtime costs money by the minute and a shop-floor system that stalls production loses the floor’s trust immediately. We design for that reliability as core engineering, and we are deliberate about the boundary between observing the process and controlling it, because software near the OT world has to earn its place there.
Because we operate what we build, the people who design a sensor-capture path or an OEE calculation are the ones accountable when the line runs on it. That concentrates the mind on the failure modes that actually matter in a plant, data that goes stale, an integration that destabilises a control system, a schedule the shift abandons, and it keeps us honest about trust: an MES only delivers if the floor believes the data flowing up is real, so we build to earn that belief rather than assuming it.
Regulation, standards and safety
Manufacturing sits under a health-and-safety regime and, depending on what is made, a web of product and process standards. Under the Health and Safety at Work etc. Act and its regulations, machinery safety, safe systems of work and the protection of people around powered equipment carry real duties, and software that observes or directs activity on the floor has to respect that the machines’ own safety systems (guarding, interlocks, emergency stops), are what keep people safe, not the MES. We are deliberate about that boundary: our software must cooperate with the plant’s safety layer and never override or assume it, and must fail into a safe, observed state rather than pushing a machine in a way its protective systems have to fight.
Quality and traceability obligations depend on the product and its market. Sectors such as food, pharmaceuticals, medical devices, automotive and aerospace carry their own quality-management and traceability expectations: recognised quality-management standards, batch and lot control, and the ability to trace and recall. That reach into what the MES must capture and evidence. We design the quality and genealogy functions to meet the relevant regime’s traceability and record-keeping requirements, because for these products the traceability is a compliance and safety obligation, not an optional analytics feature, and a gap in it is a real exposure.
The OT/IT convergence itself carries a security and safety dimension that standards increasingly address. Connecting the plant floor to business IT and the wider network expands the attack surface into systems whose compromise can have physical consequences, and industrial cyber-security guidance exists precisely because an incident on the OT side is not merely a data breach. We build with segmentation and careful boundaries between the floor and the office in mind, treating the convergence as something to engineer safely rather than to assume is benign.
We build systems that respect these obligations, but we are engineers, not your health-and-safety, quality or regulatory advisers. Duties under health-and-safety law, machinery safety, and any sector quality or traceability regime carry real legal weight, and sign-off rests with your own safety, quality and operations functions and your equipment suppliers. Our job is to build an MES that captures the traceability and quality evidence those regimes require and cooperates safely with the controls and safety systems on the floor, and to work alongside the people accountable for them.
Integration
The controls estate is the integration that defines manufacturing software. PLCs, SCADA systems, machine controls and sensors (of different ages, vendors and protocols), have to be read and coordinated as they actually are on the floor, not as a uniform standards diagram wishes. We build to meet that heterogeneous estate on its own terms, respecting the timing, volume and reliability realities of industrial data and the OT network it lives on, because a naive integration here either misreads the line or, far worse, destabilises a control system that runs the physical process.
Above the floor, the MES has to bridge cleanly to the business systems (ERP, planning, quality and reporting), feeding production, consumption, quality and performance data up, and receiving orders and material information down. This OT/IT seam is the whole point of an MES and where these projects are most often won or lost, so we engineer it as first-class work, respecting the different reliability and security cultures of the two worlds rather than pretending the plant floor is just another set of business services to be called.
Industrial IoT platforms, historians and analytics increasingly sit alongside the MES, consuming the same floor data for longer-term analysis. We integrate these so the process data captured once feeds the real-time execution layer and the historical and analytical layers coherently, because floor data that is captured inconsistently across these systems produces exactly the disagreements, between what the MES says, what the historian says and what ERP says. That erode trust in all of them.
The recurring engineering problem across manufacturing is the same as the sector’s defining challenge: keeping the operational and business worlds in honest agreement about the state of the line, in real time, across a heterogeneous and long-lived estate. We treat that reconciliation as the core of the work, design for the real controls interfaces and the OT/IT boundary from the start, and build for the reliability the line demands, rather than discovering the integration’s limits the first time a machine state or a production count disagrees between the floor and the business.
Security and resilience
In manufacturing the most acute risk is not just data theft but physical disruption, because an incident on the operational side can stop or damage a line rather than merely leaking information. The convergence of OT and IT: connecting PLCs, SCADA and machine controls to business systems and the wider network, is exactly where industrial security incidents happen, and their consequences are physical. So we treat segmentation between the plant floor and the office network as core, are deliberate about not exposing controls where they do not belong, and design the OT/IT bridge so the business side cannot become a path to the machines, because on a factory floor availability and integrity are safety-relevant properties.
Reliability and security are inseparable here for the same reason. A shop-floor system that fails, or that is compromised, can stop production that costs money by the minute, so we engineer for dependable operation, graceful degradation and recovery that restores an accurate picture of the line rather than a corrupted one. We are also deliberate about the boundary between observing the process and controlling it, keeping software that merely reads the floor from becoming an unintended route to disturbing it.
The data manufacturing holds carries real commercial sensitivity as well. Production data, recipes and process parameters, quality genealogy and performance figures are competitively valuable and sometimes safety-relevant, so we build with access scoped to genuine need, encryption where it belongs, and deliberate handling of the most sensitive process knowledge, rather than treating the plant network as a trusted zone simply because it is inside the perimeter.
Because we operate what we build, resilience and security here are not a report handed over at go-live. We instrument for the failures that actually matter on a line: data going stale, an integration destabilising a control system, a system degrading under load, keep the audit trail an investigation or a quality inquiry would need, and rehearse the degraded and recovery modes rather than hoping they work. Treating the ability to keep the line running safely, and to reconstruct exactly what happened, as part of the deliverable is what separates an MES a plant can depend on from one that merely demoed well.
What changes
An honest, trusted picture of the line
Because we capture clean data automatically from the process and reflect what is genuinely happening on the floor, the MES gives operators and managers a real-time picture they believe, so decisions, OEE figures and quality signals are built on data that survives scrutiny rather than on manual guesses the floor quietly discounts.
Measurable OEE improvement against real losses
By revealing where availability, performance and quality are actually lost, on data the operators trust, the plant can attack the specific losses that cost real money, reducing unplanned downtime and improving throughput against its true potential, instead of chasing a dashboard number nobody on the floor believes.
Traceability that contains problems precisely
Because product genealogy is captured continuously as production runs rather than reconstructed afterwards, a defect can be traced to its source and a recall scoped to exactly the affected units, turning what could be a broad, expensive containment into a precise one, at the worst moment when it matters most.
What we build for manufacturing
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for manufacturing?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in manufacturing choose us
We respect the OT world instead of treating it as another API
The classic failure is IT-minded software that treats a PLC or SCADA system like a modern web service and ignores the plant floor’s realities. We meet the controls estate on its own terms, respect its timing and reliability constraints, and are deliberate about the line between observing and controlling, because software near the OT world has to earn its place there.
We build for the reliability a line actually demands
Downtime costs money by the minute, so anything that can stall the line carries an unforgiving reliability bar. We design for dependable operation and graceful degradation as core engineering, never letting the shop-floor system become the reason a machine stops, because an MES that stalls production loses the floor’s trust the first time it happens.
We earn the floor’s trust in the data
An MES only delivers if the people running the line believe the data flowing up is real, so we build to capture it cleanly and automatically and to survive the operators’ scrutiny. A dashboard the floor discounts changes nothing; a picture they trust drives genuine improvement, and we build for the latter rather than assuming trust we have not earned.
We operate what we build
The people who design a sensor-capture path or an OEE calculation are accountable when the line runs on it, which keeps us focused on the failure modes that matter in a plant, stale data, an integration that destabilises a control system, a schedule the shift abandons, and honest about trade-offs up front rather than discovering them in production on your floor.
Related sectors
Adjacent sectors we also know.
Common questions
Can you integrate an MES with our existing PLCs and SCADA?
Yes, and we treat that as the core of the work rather than a late add-on, because the controls estate is what defines manufacturing software. Real factory floors run PLCs, SCADA and machines of different ages, vendors and protocols, and we build to meet that heterogeneous estate on its own terms: respecting the timing, volume and reliability realities of industrial data and never treating a controls system like a modern web API. We are also deliberate about the boundary between observing the process and controlling it, because a naive integration either misreads the line or, far worse, destabilises a control system that runs the physical process. Meeting the estate as it actually is, not as a tidy standards diagram wishes, is where these projects succeed or quietly fail.
How do you handle the OT/IT convergence safely?
By respecting that the operational and business worlds have genuinely different lifecycles, reliability cultures and security assumptions, and engineering the seam between them deliberately. Bridging OT and IT means feeding production, quality and performance data up to ERP and planning and receiving orders down, without letting the business side become a path to the machines, so we treat segmentation between the plant floor and the office as core, and design the bridge so a problem on the IT side cannot reach the controls. The convergence expands the attack surface into systems whose compromise has physical consequences, which is exactly why we engineer it as something to secure and reconcile carefully rather than assume is benign.
Will a shop-floor system be reliable enough not to stop our line?
That reliability is a first-order design constraint for us, because on a production line downtime costs money by the minute and a system that stalls production loses the floor’s trust immediately. We design anything that can disrupt the line to be dependable, to degrade gracefully rather than fail hard, and never to become the reason a machine stops, and we are careful that software which merely observes the process does not become an unintended route to disturbing it. This is core engineering in manufacturing, not a non-functional afterthought, and we would rather build and prove that dependability than discover its limits the first time the line is waiting on the system.
How do you make OEE numbers the operators actually trust?
By building them on data captured cleanly and automatically from the process rather than keyed in by people who have no time to enter it. OEE is only as good as the machine states, counts and downtime reasons beneath it, so we capture those at the right cadence, reason-code stoppages properly, and present availability, performance and quality losses in a way the people running the line believe. An OEE figure the operators discount changes nothing, while one they trust drives real improvement against losses that cost real money, so earning that trust in the data is foundational, and we build for it rather than assuming a dashboard alone will be believed.
Can you build traceability strong enough to support a recall?
Yes, and the key is capturing product genealogy continuously as production runs, not reconstructing it afterwards from partial records. We build the linkage into the execution flow so every unit or batch carries its provenance (the materials, batches, machines, settings and operators that produced it), which lets a defect be traced to its source and a recall scoped to exactly the affected units rather than a broad, expensive sweep. In regulated or safety-relevant manufacturing that traceability carries real compliance weight, so we design it to meet the relevant regime’s record-keeping requirements. To be clear on the boundary: we build the system that gives you defensible traceability, while the quality and recall decisions rest with your own quality function.
Building for manufacturing?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if manufacturing is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.