Software development, Perth
Operational software for mining, rail, oil and gas and agriculture, built in West Perth by engineers who know the plant it connects to.
Enco is a Perth software development company with an unusual shape. The team that writes the code also walks the site, designs the data and understands the control systems, maintenance systems and historians the software has to work with. That is why the work we take on sits where the plant meets the enterprise: production reporting, maintenance and shutdown tools, telemetry from remote assets, and the data platforms underneath them.
We do not build consumer apps, marketing websites or online stores. If the software has to read from a PLC, a historian, a CMMS or an ERP, run around the clock, or put a number in front of someone who has to act on it, it is the kind of work we do, and the Software and AI page sets out the four ways we take it on.
What we build
Each of these is a kind of system we have delivered for an operation that depends on it. The case studies describe the work without naming the client.
Production and operations reporting
Rate, availability, delays and quality from control system and historian data, in front of the shift and the morning meeting without a spreadsheet in between.
Real-time production analytics →Data platforms and ETL
Warehouses and pipelines that join plant, maintenance and business data at a scale the operation can trust, built on PostgreSQL and SQL Server where the data already lives.
SQL data platform and ETL optimisation →Integration with plant systems
Reading from PLCs, SCADA and historians through the industrial DMZ, and writing to the CMMS and ERP, without opening the control network.
Bridging OT and IT with custom software →Maintenance and shutdown tools
Applications for planners, schedulers and shutdown coordinators that sit beside the CMMS and do the parts it does badly: the board, the sequence, the live status.
Shutdown coordination platform →Telemetry for remote assets
Monitoring for pumps, bores, pivots and plant that nobody drives past, from the sensor to the alert to the work order.
Telemetry and monitoring for remote assets →AI inside operational systems
Search and question answering over procedures, manuals, work orders and reports, with access that follows existing permissions and a person approving where it matters.
How we work with AI →How a build runs
Every build starts on site and ends with software someone is using, with working versions in between rather than documents. The steps are the custom build model from our Software and AI page, and the thinking behind the technology choices is in choosing a technology stack for industrial software.
Understand
Time on site with the people who do the work, and with the systems it has to connect to, before anything is designed.
Prototype
A working version on your own data within days, so the idea is tested before the spend.
Build
Short cycles you can see, each one ending in software you can use, with the hardest part built first.
Run
Deployed to your cloud or ours, documented, and supported up to around the clock for the operations that need it.
Understand
Time on site with the people who do the work, and with the systems it has to connect to, before anything is designed.
Prototype
A working version on your own data within days, so the idea is tested before the spend.
Build
Short cycles you can see, each one ending in software you can use, with the hardest part built first.
Run
Deployed to your cloud or ours, documented, and supported up to around the clock for the operations that need it.
Where it runs, and what it is built with
The stack follows the shape of the problem rather than a favourite tool, and we are comfortable across approaches. Where there is no reason to do otherwise we start from what we know best and can support for years.
- Web applications. Vue or Blazor on the front end, .NET on the back end, PostgreSQL for data, designed to run on any cloud. Built as software that runs a 24/7 operation when it has to.
- Data. SQL Server and PostgreSQL platforms, time-series stores for historian-scale data, and the sizing done before the first row lands.
- Plant connectivity. OPC UA and MQTT through the industrial DMZ, with ISA-95, IEC 62443 and the ASD OT principles as the reference points for what crosses the boundary and how.
- Hosting. Your cloud tenancy, ours, or on site. The code and the roadmap are yours either way.
- AI. Frontier models, private cloud or open source models on site, chosen by where your data is allowed to go, and swappable without a rewrite.
Why Perth, and why engineers
The same people, site to go-live
The engineer who understood the problem on site is the one who designs the data and builds the application. Nothing is lost in a handover to a development team that has never seen a crusher.
Plant systems treated as plant systems
We work inside the slow pace of change on control networks because it is a safety and availability decision, not inertia. Reads through the DMZ, nothing written to control, and every integration documented.
Perth hours, Australian sites
Based in West Perth, in the same time zone as most of the mining and resources operations we work with, and on the same flights. Site visits are part of the method, not an exception.
A small senior team, working with AI
Our engineers use AI every day to design, write, test and document, which is why a few senior people deliver what used to need a larger crew, and why we also take prototypes built with AI tools through to production.
Who it suits
- An operation with a process that no product covers, or one that has to sit deep inside systems a product cannot reach.
- A site running on spreadsheets and reports that take a morning, where the data already exists in the control system and the CMMS.
- A business that has outgrown an internal tool, or a prototype someone built, and needs it made dependable.
- A project that needs the plant connected to the enterprise without putting the control network at risk.
If the right answer is a hosted product, a review of a prototype you already have, or AI inside the systems you already run, those are the other three ways we work, set out on the Software and AI page. A prototype review has its own page at prototype review.
Common questions
Do you only work with Perth companies?
No. We are based in West Perth and most of our work is with operations in Western Australia and across Australia, on site and remotely. The office is where the team is, not a limit on where the software runs.
Can you build a mobile app?
Yes, where the work is in the field: inspections, telemetry, shutdown status, pre-starts. We build mobile interfaces as part of an operational system rather than as standalone consumer apps, so the data goes somewhere and someone acts on it.
What does custom software development cost?
It follows the size of the team and the amount of rework, and both come down when a few senior engineers do the work and problems surface in a prototype rather than after launch. We scope a first working version before anything is committed, and quote it as a fixed scope where the problem is clear enough to allow one.
Who owns the code?
You do. Work commissioned by a client stays the client's, including the code, the data and the roadmap. Where we host and support it, that is a service around something you own.
Can you connect to our PLCs and historian?
Yes, and it is most of what makes the work different. Plant data is read through the industrial DMZ with protocols such as OPC UA and MQTT, nothing is written back to control, and the design is documented against ISA-95 and IEC 62443 as reference points. The stack article explains the approach.
Do you support what you build?
Yes. When we build a system we can support it, up to around the clock for the operations that need it. Support can also be handed to your own team, with the documentation and tests to make that safe.
Tell us about the system
A few lines on the problem and the systems it touches is enough to start. We will come back with questions, then a scope.