By process
Industrial Software Development, Built for the Conditions It Runs In
Software for an industrial business has to survive a shift change, a network drop, a supervisor with gloves on, and a decade of process change. That is a different engineering problem from a consumer application, and it is the one we work on.
Who this is for
- Manufacturing and industrial companies commissioning software for plant operations
- Businesses whose previous system was abandoned by the people meant to use it
- Companies with multi-shift, multi-location or multi-company operations
- Organisations that need the system to outlast the people who commissioned it
The problem
Why software written for offices fails in plants
- 01
It assumes an office user
Long forms, small controls, a mouse, an uninterrupted five minutes and a keyboard. None of those describe a supervisor between two machines.
- 02
It assumes the day starts at nine
Shift boundaries that cross midnight, production dates that differ from calendar dates, and third-shift entries landing on the wrong day are a recurring source of wrong reports.
- 03
It assumes a reliable network
In a plant, connectivity drops. Software that loses an entry when it does will be distrusted permanently after the first occurrence.
- 04
It assumes one location and one company
Multi-unit, multi-company and inter-unit transfers are difficult to retrofit. Deciding late is one of the most expensive mistakes available.
- 05
It assumes the process will not change
Industrial processes change — new product, new line, new customer requirement, new regulation. A system that treats every change as a project becomes a constraint.
- 06
It assumes documentation is optional
When the only person who understands the system leaves, an undocumented system becomes a risk the business has to pay to remove.
How the system works
How we engineer for industrial conditions
Two design languages: floor and office
Shop-floor screens with few fields, large targets and defaults that reflect where the device is. Office screens with the depth an accountant or planner needs. Same system, different surfaces.
Shifts, not days
Shift-aware data capture including shifts that cross midnight, with production date handled separately from entry date so night-shift work lands on the right day.
Resilient capture
Entries confirmed locally and synced when the connection returns, with idempotent submission so a retry cannot double-count production.
Multi-company and multi-location from the start
Separate books and stock, shared masters, inter-unit movements and consolidated reporting designed in — because it is very hard to add later.
Role-based access down to the field
Who can see a rate, who can approve above a limit, who can back-date an entry. Enforced by the system, with an audit trail on everything sensitive.
Configuration over code
Approval limits, reason codes, reorder rules, units and thresholds are configurable, so ordinary operational change does not need a developer.
Documented and handover-ready
Data model, integrations, deployment and operational runbook documented, so your team or another vendor can take it forward. You should not be locked in by ignorance.
Automation
What stops being somebody's job
When this happens
The system does this
A night-shift entry is recorded after midnight
It is attributed to the correct production date
The network drops mid-entry
The entry is held locally and synced without duplication
A user attempts an action beyond their role
It is blocked and logged
A back-dated entry is made
It requires a reason and is flagged for review
An approval limit changes
It is updated as configuration, not as a release
An integration fails
It is retried, logged and surfaced to a named owner
None of these need a person to remember them. That is the whole point.
Management visibility
What management can see once this runs
- Shift-wise data that reconciles to the production day, not the calendar day
- A complete audit trail on sensitive fields and back-dated entries
- Per-unit and consolidated views from the same data
- Integration health — what synced, what failed, what is queued
- Who has access to what, reviewable rather than assumed
In practice
Situations this is usually bought for
A night shift that reports correctly
Entries after midnight belong to the shift that produced them, so the daily report is right without anyone adjusting it.
A tablet that loses signal
The supervisor's entry is accepted, queued and synced when the network returns — once, not twice.
A second unit added without a rewrite
Because multi-company structures were designed in, a new plant is configuration and data setup rather than a new project.
A handover that does not lose knowledge
Documentation and access handover done as part of delivery, so your dependency is on the system rather than on a particular developer.
Before / after
What changes
Before
After
Office software used reluctantly on the floor
Screens designed for the floor
Night-shift data on the wrong day
Shift-aware reporting that reconciles
Lost entries when the network drops
Queued, de-duplicated capture
A system only one person understands
A documented system you could hand to anyone
How it works
From operational chaos to a connected business system
- 01
Understand
We sit with each department and learn the process as it is actually run — including the workarounds, the informal exceptions and the things people do because the official way does not work. This is where most of the value of the project is decided.
You getA written map of your current processes, departments and bottlenecks
1–2 weeks
- 02
Map
We trace how information moves between people, departments and systems: where it is created, where it is re-entered, where it is lost, and where a decision waits on something nobody can see. The re-entry points are almost always the expensive ones.
You getAn information flow map, with every handoff and duplication marked
1–2 weeks
- 03
Design
We design the target workflow — owners, rules, gates, automations and the screens each role needs — and agree it with the people who will live in it. We also agree what we are deliberately not building yet, and say so plainly.
You getA workflow design, screen list and phased build plan with scope you have signed off
2–3 weeks
- 04
Build
We build in phases, so one department is genuinely using something early rather than waiting for a full system. Each phase is delivered, tested with real data and put into use before the next begins — which is also how the awkward details get found while they are still cheap.
You getWorking software in real use, phase by phase, with integrations and reports
Phased, typically 4–12 weeks per phase
- 05
Optimize
After go-live we look at what is actually being used, which alerts are being acted on and which are being ignored, where people are still keeping a parallel sheet, and what the data now reveals that nobody could see before. Then we improve it.
You getUsage review, workflow refinements, new reports and ongoing support
Ongoing
Questions
Frequently asked questions
Still unsure whether your processes are a fit? Walk us through one of them.
Book an Operations Automation ConsultationWhat technology do you build on?
Mainstream, well-supported web technology that runs on your own server or on cloud infrastructure, works in a browser on desktop, tablet and phone, and does not require a specialist to maintain. We choose boring and durable over novel, because these systems are expected to run for years.
Can it run on our own server inside the plant?
Yes. On-premise deployment is often the right answer where plant connectivity is unreliable or data must stay on site, and it keeps the floor working when the internet does not. We can also deploy to cloud infrastructure, or run a hybrid where the plant is local and management reporting is remote.
How do you handle security and access control?
Role-based permissions down to individual fields and actions, enforced on the server rather than hidden in the interface, with an audit trail on sensitive changes. For plants we also cover the practical realities — shared devices, shift handover and accounts belonging to people who have left.
What happens after the project is delivered?
Operational software needs ongoing work: process changes, new reports, new units, occasional defects. We offer continued support, and equally we make sure you are able to leave — documentation, code and data handover are part of delivery, not a negotiation afterwards.
Can you work with our in-house IT team?
Yes, and it usually produces a better result. Your team knows the plant and the politics; we bring the systems engineering. We are happy to build to a point and hand over, or to work alongside your developers throughout.
Keep reading
Related solutions and industries
System Integration
Custom ERP development and system integration — connect accounting, CRM and operational software into one workflow with a single source of truth.
Manufacturing Systems
Manufacturing software development covering production, material issue, quality, job work and dispatch — built for real shop-floor processes.
Business Management Systems
Custom business management software for operational companies — production, orders, inventory, purchase and dispatch modelled on how your business works.
Engineering
Project workflows, drawing and BOM control, procurement, job costing, team coordination and reporting.
Next step
Your business has a process. Let's turn it into a system.
From manual workflows and disconnected departments to connected operations, automated processes and real-time visibility.