Software and AI
Custom applications, hosted products and AI systems for industrial operations, from engineers who use AI in every part of their own work
AI has changed how software gets built, and we have rebuilt how we work around it. Our engineers use it every day to design, write, test and document what we deliver, and we build it into the systems our clients run. A small senior team, the same people who understand your plant, now covers ground that used to take a much larger one.
Using it daily also teaches where it helps and where it has to be checked. This page sets out what that changes for you, the ways we can work together, where the AI can run and what stays under control.
What AI changes for you
The gains are practical ones, and they show up in three places.
One senior team, start to finish
The engineers who walk your site also design the data, build the application and connect it to your systems. AI does the drafting and the cross-checking, so the people who understand your operation stay on the work from the first conversation to go-live.
Working software in weeks
A first version you can use arrives early, often within weeks, built on your own data. You decide on something real instead of a specification, and changes take days rather than a new project plan.
A smaller team and less rework
Cost follows the size of the team and the amount of rework. Both come down when a few senior engineers do what used to need a larger crew, and when problems surface in a prototype instead of after launch.
Four ways to work with us
Every job starts from where you are, so we work under more than one model. Each has its own process, and it is common to move from one to another as the work grows.
A hosted product
Fits when the problem is one most operations share, and you would rather configure working software than fund a build.
- Pilot. A private deployment loaded with your own data.
- Configure. Rules, thresholds and workflows set to match how you work.
- Connect. Sign in, maintenance, finance and plant systems linked up.
- Run. Hosted, monitored, updated and supported by us.
Your prototype, made production ready
Fits when you or your team built a working app with an AI coding tool, often called vibe coding, and now other people need to rely on it.
- Review. We read the code, the data model and how it handles sign in and secrets, then tell you plainly what we found.
- Decide. Keep and strengthen what is sound, rebuild what is not, with the reasoning and a fixed scope.
- Harden. Proper sign in, a real database, automated tests, error handling, backups and monitoring.
- Launch. Deployed to your cloud or ours and documented, then handed over or supported by us.
Software built for your operation
Fits when the process is specific to your operation, or has to sit deep inside systems no product reaches.
- Understand. Time on site with the people who do the work, 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.
- Run. Deployed and supported, with the code and the roadmap yours.
AI inside the systems you already run
Fits when the answers already sit in your work orders, procedures, manuals and reports, and people cannot get to them fast enough.
- Pick one job. A single workflow where time is being lost, with a clear measure of better.
- Prove it. Tested on your own documents and real questions, with the misses counted.
- Add the controls. Access follows your existing permissions, sources are shown, and a person approves where it matters.
- Roll out. Released to a small group first, logged, and reviewed as models change.
Where the AI runs
The right model depends on the task and on where your data is allowed to go. We work with all three of the options below and often combine them, and we build each application so the model behind it can be swapped without a rewrite.
| Frontier models | Private cloud | On site, open source | |
|---|---|---|---|
| What it is | The most capable models from the leading AI labs, used through their business services | Models served inside your own cloud tenancy, under your existing agreements | Open source models running on hardware you own, with no internet connection needed |
| Where your data goes | To the provider, under business terms that keep it out of model training | It stays in your tenancy and your region | Nowhere. It never leaves your site |
| Strongest at | Hard reasoning, long documents and complex code | Most business tasks, with data residency covered | Search, extraction, summaries and assistants over your own documents |
| Downside | Data leaves your environment, and cost rises with use | Limited to what your cloud provider offers | Hardware to buy and run, and less capable than the largest models |
| Suits | Engineering and analysis work on data you are cleared to share | Corporate systems already covered by your cloud agreements | Operational networks, remote sites and anything that must stay offline |
Choosing between them follows the same five steps every time.
Sort the data
What can leave, what stays in the country and what never moves.
Start small
Try the smallest model that could do the job first.
Test it
Score each option on your own questions and documents.
Set limits
Permissions, logging, spending caps and human approval.
Review
Models improve fast. The same tests show when to change.
Sort the data
What can leave, what stays in the country and what never moves.
Start small
Try the smallest model that could do the job first.
Test it
Score each option on your own questions and documents.
Set limits
Permissions, logging, spending caps and human approval.
Review
Models improve fast. The same tests show when to change.
What stays under control
AI changes how fast the work moves. It does not change who answers for it.
- An engineer answers for every change. AI drafts and people review, to the same standard as any other code, with tests that have to pass before anything ships.
- Tested before it is trusted. AI features are scored against your own examples before release, and again whenever the model behind them changes.
- Your data is not training material. Cloud models are used under terms that exclude training, and anything sensitive can stay inside your tenancy or on your site.
- People decide where it matters. Anything touching safety, money or compliance goes to a person for approval, with the sources in front of them.
- Everything is recorded. Questions, answers and actions are logged, so a result can be traced and explained later.
- No single supplier. Applications are built so the model behind them can be replaced as better or cheaper ones appear.
We draw on references such as ISO/IEC 42001 for AI management systems, the NIST AI Risk Management Framework and the OWASP guidance for applications built on language models, applied in proportion to the risk of the job.
The problems we build for
Whichever way we work, it starts from a problem seen on site and not from a technology looking for a use.
Coordinating work across teams
Shutdowns, handovers and planned work that involve several crews, contractors and approvals, where the plan lives in too many spreadsheets for anyone to trust.
Turning plant data into decisions
Condition, production and telemetry data that exists but reaches people too late, too raw or in too many places to act on.
Getting answers out of documents
Procedures, manuals, drawings and years of work order history that hold the answer, if only someone had time to read them. An assistant searches them, answers in plain language and shows its sources.
Taking the repetitive work off people
Reading reports into a system, drafting job plans from past work, sorting and summarising alerts. Work that follows a pattern, done by software and checked by the person who used to do it.
Keeping records that stand up
Inspections, approvals and changes that have to be traceable to a person and a time, with history the screens cannot quietly overwrite.
Knowing what needs doing next
Work with a clock on it, from follow-ups to reviews to overdue actions, surfaced in one ranked list rather than remembered by whoever is busiest.
The stack
Where we usually start, and what we reach for when the problem calls for something else. Each layer is chosen against the context of the job and the evidence from building its hardest part first, so an application can be supported for years, moved between hosting environments and pointed at a different model without a rewrite.
Plant systems change the answer at every layer. Choosing a technology stack for industrial software sets out how we decide, from the automation pyramid and the control network up to the browser.
Front end
Vue and Blazor
Fast, accessible interfaces that work on a desktop in the office and a tablet in the field.
Also · React, Angular, Svelte, and Canvas or WebGL where the screen is a schedule, a trend or a map
Back end
.NET
A mature, well supported platform with long term support releases and strong security tooling.
Also · Node, Python, Go and Java, matched to the libraries the job depends on
Data
PostgreSQL
A proven relational database, with data platforms built to handle very large volumes of operational data.
Also · SQL Server, time-series and document stores, and the historian a site already runs
Models
Frontier and open source
Chosen for the task and placed behind one interface, so a model can be changed without touching the application.
Knowledge
Search over your own documents
Answers are grounded in your procedures, history and manuals, with the source shown beside each one.
Assurance
Evaluation and logging
Test sets built from your own examples, run before every release and every change of model.
Identity
Microsoft Entra ID
Single sign on with the Microsoft accounts your people already use.
Also · Okta, Auth0 and Keycloak, and local sign in where a site network cannot reach the cloud
Packaging
Docker containers
Each deployment runs the same way on any cloud or in your own environment.
Also · Kubernetes, serverless containers, and servers or edge gateways on site
Integration
APIs, historians and CMMS connectors
Data moves in and out through documented interfaces, including OPC UA for plant systems.
Also · OPC UA, MQTT with Sparkplug, message queues, and gateways for older protocols such as Modbus
How hosted products are run
Where the same gap keeps appearing across operations, we build the answer once and offer it as a product. There are two ways to run one. Either way it is a private deployment for your business, never a shared database with other customers.
| Hosted by Enco | In your environment | |
|---|---|---|
| Where it runs | A private deployment in the cloud, managed by us | Your cloud tenancy or your own infrastructure |
| Database | Dedicated to your business | Dedicated, under your control |
| Updates | Applied and tested by us | Delivered as releases your team or ours deploys |
| Monitoring and backups | Included | Run to your standards, with our support |
| Support | Sized to the operation, up to 24/7 where the work needs it | The same, working within your processes |
| Suits | Getting started quickly with no infrastructure to run | Strict data residency, security or integration requirements |
- One deployment per business. Your own database, your own application instance and your own sign in. Nothing is shared with another customer.
- Your data stays yours. It can be exported in a usable form at any time, and it leaves with you if you stop using the product.
- Configuration, not code. Rules, time limits and approval thresholds are data, so they change as your operation changes without waiting for a software release.
- History written by the platform. Audit trails are recorded centrally rather than by individual screens, so they cannot be bypassed.
- Sign in with the accounts you already have. Microsoft sign in, so access follows your existing identity and offboarding rather than a separate list of passwords.
- Built to connect. Interfaces to the maintenance, finance and operational systems you already run, rather than another island of data.
Common questions
Do you use AI to write our software?
Yes, every day. AI drafts code, tests and documentation, and our engineers review all of it and take responsibility for it, to the same standard as code written by hand. It is why a small senior team can now deliver what used to need a larger one.
Is our data used to train AI models?
No. Where we use cloud models, it is under business terms that keep your data out of training. Where data cannot leave your environment at all, the model runs inside your own cloud tenancy or on your own hardware.
Can AI run without sending data off site?
Yes. Open source models can run on hardware at your site with no internet connection, which suits operational networks and remote sites. They are less capable than the largest cloud models, so we test them on your own examples first to confirm they are good enough for the job.
We built an app with an AI coding tool. Can you make it production ready?
Yes. We review what you have, tell you what can be kept and what should be rebuilt, then add what a prototype usually lacks, such as proper sign in, a real database, tests, backups, monitoring and documentation. You keep the idea and the momentum, and other people can safely rely on the result.
Which AI model do you use?
Whichever suits the task and the data. We work with frontier models from the leading labs and with open source models, and build applications so the model can be swapped. Models change every few months, so the choice is tested against your own examples rather than made on reputation.
What about AI getting things wrong?
It does, so the work is designed for it. Answers show their sources, AI features are scored against your own examples before release, and anything touching safety, money or compliance goes to a person for approval.
Where is our data hosted?
In a private deployment for your business, either managed by us in the cloud or inside your own environment. The database is never shared with another customer, and the data can be exported whenever you need it.
Can your software connect to SAP, Maximo or our historian?
That is the normal expectation. What we build is designed around documented interfaces, and connecting it to maintenance, finance and plant systems is part of how it is deployed.
What happens if we stop using a product?
You take your data with you, in a usable format. Nothing about a product is designed to make leaving difficult.
Have a prototype, a problem or a question about AI?
Tell us where you are. We will tell you which of these models fits, what it would take and what we would do first.