Manufacturing

Production visibility for the floor and the office

Manufacturing software works when it matches what the line is actually doing, and gets ignored the moment it does not. We build production visibility and quality tooling for plants where the current answer is a clipboard at the end of the line and a spreadsheet assembled the following morning.

The pressure

What makes manufacturing software hard

Before anything about us. These are the constraints that shape every manufacturing build, and the reason generic delivery comes unstuck here.

01

The floor knows before the office does

What the line knows and what management sees are usually a shift and two spreadsheets apart. By the time the number arrives, the decisions that mattered have been made.

02

Gloves, glare, and a shared terminal

The interface gets used standing up, on a screen with a scratched protector, by somebody wearing gloves who has ninety seconds before the next pallet.

03

Machines older than the network

Equipment that predates any notion of connectivity still has to appear in the reporting picture. Pretending otherwise leaves whole lines invisible and every total quietly discounted.

What we build

Manufacturing capabilities

Four areas we take on in this sector. Each one is work we do rather than a category we list.

What the line is doing while it is doing it

Most plants learn their output the next morning, from a spreadsheet built out of a clipboard. Live numbers change which decisions are still available: a changeover you can still move, an operator you can still reassign.

  • Live output and rate against target
  • Downtime capture with reason codes
  • Shift and line performance views
  • Wall-display layouts readable across the floor
  • Changeover and setup tracking
  • Shift handover summaries
Problems and approach

Where these projects actually go wrong

The recurring failure patterns in this sector, what we do differently, and what that changes. You will not find a claimed figure here. Those belong to engagements we can name, and we do not name what we cannot evidence.

Problems we solve

Management sees production numbers the next morning, assembled by hand from a clipboard and three spreadsheets.

Solutions we deliver

Live dashboards fed from the floor, with the same figures on the wall display and in the management view so nobody spends the meeting arguing about whose number is right.

Impact you will see

Decisions get made while the shift can still be changed.

Problems we solve

Operators skip defect logging because entry takes too long on a shared terminal in the middle of a run.

Solutions we deliver

Capture built for gloved hands and interruption: large targets, reason codes instead of free text, and photos wherever a photo is faster than a description.

Impact you will see

Recording a defect stops competing with keeping the line running.

Problems we solve

A sensor feed drops overnight and the dashboard carries on showing a figure that looks entirely normal.

Solutions we deliver

Explicit gap and staleness states, so a missing source renders as missing instead of being averaged into something plausible.

Impact you will see

A broken feed is visible before a decision gets made on it.

Problems we solve

Two older machines have no connectivity, so whole lines are absent from the reporting picture and everyone quietly discounts the totals.

Solutions we deliver

Structured manual entry for equipment that cannot report, held to the same data model as the automated feeds and marked with where the number came from.

Impact you will see

The whole plant appears in one picture, with the provenance of each figure visible.

How we work

Commitments, not promises

How we build for manufacturing clients. Each one is checkable in the work itself rather than a claim about results you cannot see.

Typical stack
ReactNext.jsNode.jsPostgreSQLDockerAzure
  • Designed for a gloved hand

    Large targets, high contrast, reason codes instead of free text, and as little typing as the task will allow.

  • A missing feed looks missing

    When a data source drops, the dashboard shows a gap. It does not average around it and present a plausible number.

  • Designed with the operator

    We sit with the people entering the data, not only the people reading the report, because entry that takes too long produces data nobody should trust.

Engagement

Three ways this usually starts

Prices are not listed because they depend on scope. We quote a range after discovery, along with the specific things that would move it toward each end.

Discovery

Best before you commit

A short paid engagement that ends with a scoped plan you own, whether or not we build it. If the honest answer is that you should not build software at all, that is what the document will say.

  • Requirements and constraints captured
  • Technical and integration assessment
  • Architecture and approach outline
  • An estimate as a range, with its drivers
  • Risks named rather than implied

Project build

Best for a defined outcome

A scoped build with an agreed deliverable, run in short cycles with something you can review at the end of each one. Suited to work where the shape of the outcome is already clear.

  • Fixed scope with a change process
  • Something reviewable every cycle
  • Design, build, test, and deploy
  • Documentation and runbooks
  • Handover to your team

Dedicated team

Best for an ongoing roadmap

A small team working continuously against your priorities, with capacity you can plan around. Suited to products that keep changing rather than projects that finish.

  • Named engineers, consistent over time
  • Priorities you set each cycle
  • Direct access to the people building
  • Shared repository and tooling
  • Exit on notice, with no lock-in
Related thinking

Reading that bears on this sector

All insights
Engineering

Most cloud migrations do not need a rewrite

The instinct to re-architect everything on the way to cloud is how a migration becomes a multi-year programme that stalls. Move it first. Then fix what the bill points at.

24 Apr 2026 · 6 min
Perspective

What we tell clients before they add an LLM to their product

Most requests we get for AI features describe a solution rather than a problem. The useful first conversation is about what happens when the model is confidently wrong.

30 May 2026 · 8 min
Guide

How we scope a project, and why we sometimes say no

A scoping call that ends in an honest no is worth more to both sides than an engagement that starts on a misunderstanding.

20 Mar 2026 · 6 min
Questions

Manufacturing: what buyers ask us

Including the ones where the answer is no. A limit stated up front is worth more than a capability claimed now and found out later.

Where the equipment exposes data through a supported interface or an intermediate system such as an OPC server or a historian, yes. Where it does not, we design structured manual entry into the same data model rather than leaving the line invisible, and we mark which figures a person typed in. We do not write PLC or machine firmware. We work at the data layer above it.

Only if entry costs less than the workaround, which is the main design constraint on the whole build. We design with the people entering the data, not only the people reading the reports, because slow entry reliably produces data nobody trusts. Large targets, high contrast, reason codes rather than free text, and as little typing as the task allows.

No. We build the visibility and workflow layer around those systems and integrate with them. An ERP replacement is a multi-year programme with a poor completion record, and it is not something a firm our size should be selling you. If your problem genuinely is the ERP, we will say so and step back.

The interface keeps working and reconciles afterwards. Entry queues locally and syncs on reconnect, and dashboards show staleness explicitly rather than continuing to display the last number they saw as though it were current. A quietly stale figure is more dangerous than an obviously missing one.

That is the target, and it is worth settling at scoping because it constrains the entire interface. An older browser on a terminal bolted to a pillar, gloved touch, glare from a skylight, and somebody using it standing up all shape the design. We would much rather know the device reality early than meet it on deployment day.

By pushing into the reporting tools they already open. Plant data is more useful inside an existing management reporting stack than in a new dashboard somebody has to remember exists. We build those exports and integrations alongside the floor-facing views rather than after them.

Next step

Let's talk about your manufacturing project

A scoping conversation costs nothing. You leave with a clear view of the approach, a budget range, and the main risks named out loud, including an honest no if we are not the right firm for this.