How we work
From site visit to running system.
Four stages, in the order they actually happen. No discovery theatre, no big-bang cutover, and nothing installed before your team has seen how it works.
Discovery on site
We walk the floor before proposing anything. What the process actually does, where the data already exists, and which registers and spreadsheets people rely on today.
- Map the real process, including the manual workarounds
- Inventory existing systems — SCADA, PLC, weighbridge, accounts
- Identify the assets where downtime hurts most
- Agree what success looks like in numbers
Scope and architecture
A written scope with module boundaries, integration points and a phased sequence — so you can see what lands in month two versus month six before committing.
- Module-by-module scope with clear boundaries
- Integration plan for each existing system
- Deployment decision: your servers or your cloud
- Phased rollout order, highest-risk assets first
Build and integrate
We configure against your process, wire up the existing instrumentation, and run in parallel with your current method so nothing depends on an untested system.
- Configured to your process, not a generic template
- Live integration with existing tags and instruments
- Parallel run against current records before cutover
- Your team trained on the system as it's built
Go live and support
Staged cutover, then a named engineer who knows your install. Support covers new staff, process changes and the tuning that only real operating data reveals.
- Staged cutover, one plant or module at a time
- A named engineer, not a generic ticket queue
- Training for new staff as your team changes
- Tuning thresholds against real operating data
Next step
Start with a conversation, not a proposal.
Tell us what your process looks like today. If we're not the right fit, we'll say so — that's cheaper for both of us than a project that shouldn't have started.
Questions
What clients ask before starting.
Three to six months for most deployments, driven by how many sites and modules are in scope rather than by a fixed package. A single unit with a focused module set goes faster; a multi-site plant with legacy data migration takes longer. We give you a phased schedule at scoping, not a number picked to win the deal.
More at the start, less as it goes. Discovery needs real access to your process and the people who run it — usually a few days on site. During build we need a point of contact for decisions. After go-live the load drops to normal support. Projects that stall are almost always the ones where nobody internally had time.
Both, depending on which is honest for your case. Where our products already fit — ZapNexa for ERP, Vexron for condition monitoring — configuring them is faster and cheaper for you. Where your process genuinely differs, we build. We'll tell you which applies rather than selling whichever has the bigger margin.
Next.js and React on the front end, Node.js and Python behind it, with SQL databases and time-series storage for sensor data. Hardware work uses standard industrial protocols so you aren't locked to us. The stack matters less than the integration: your existing systems dictate a lot of it.
Parallel running is the real test — the system runs alongside your current method until the numbers agree. Before that, code review on every change and automated tests on the parts where a silent error would be expensive. We'd rather find a discrepancy during parallel run than after you've retired the old process.
Yes, and most projects do once people see the system working. Changes are quoted against the written scope so the impact on timeline and cost is visible before you decide. What we avoid is absorbing changes silently and then explaining a slipped date later.
A support period is included in every engagement, covering fixes, user training and the tuning that only shows up once real data flows. Beyond that most clients move to an ongoing support arrangement. Either way you keep your data and your deployment.
That's the usual path — one plant first, then extend. Designing for it from the start costs little; retrofitting it later costs a lot, so we plan the multi-site data model even when the first phase is a single unit.
Role-based access enforced in the application, deployment on infrastructure you control, and dependency plus access review before each release. Findings get shared with your IT team rather than buried. We'll walk them through the architecture before anything is installed.
A conversation, then a site visit. No cost and no obligation for either. If we don't think we're the right fit for your process, we'll say so — that's a cheaper outcome for both of us than a project that shouldn't have started.