We ran critical systems. This is what we learned to build.

Most industrial software looks convincing in a demo.

The real test comes later: at night, under live load, with field data arriving from different systems, alarms waiting for action, and a dispatcher who has to decide before the next report is ready.

That is the environment MetaEnergy comes from.

We are not a generic software company adapting an existing product to the energy sector. MetaEnergy was built from inside real infrastructure operations - control rooms, dispatching workflows, telemetry systems, hydraulic calculations, reporting cycles, and decisions that could not wait.

We do not begin with a screen

When we design a platform, we do not start with the interface.

We start with operational questions.

What does the dispatcher need to see first? What happens when telemetry is delayed? Can an alarm be reconstructed after the shift? Can an engineer explain a hydraulic result without calling the modeler who built it? Can management trust the report after handover? Can the system keep working under real operational load?

Those questions sound obvious.

Yet, much of today's industrial software is still not designed around them.

Most platforms in this space are designed around features - a list of capabilities a buyer can compare in a procurement spreadsheet. Features have their place. But the operator who carries responsibility at 3 a.m. does not experience the platform as a feature list. They experience it as a sequence of decisions the software either supports or does not.

The two design philosophies produce different software.

The second one is what we build.

This is what we mean when we say we are operators building for operators.

It is not a slogan. It is a design discipline.

Where this comes from

MetaEnergy was shaped by more than 18 years inside large-scale gas transmission operations - including a tenure as Deputy Director General at the Georgian Gas Transportation Company.

Before MetaEnergy became a company, the operating problems were already familiar: SCADA modernization, dispatching workflows, telemetry stability, hydraulic calculations, forecasting, reporting, and decisions that could not wait.

Several members of our core team came from inside national gas infrastructure operations. We modernized systems from the operator side first, then turned that experience into a company in 2023.

That history changes what gets built.

We have seen where static schemes fail, where spreadsheets become risky, where delayed alarms create pressure, and where disconnected systems slow down the people responsible for keeping infrastructure running.

We are now building software to close those gaps.

Proof comes from systems that run

In high-stakes infrastructure, proof does not come from a slide deck.

It comes from systems that stay up.

MetaEnergy's architecture has been shaped by demanding national infrastructure operations: 30,500+ kilometers of pipeline, 2,300+ connected IoT devices, and 1,400+ daily operational events processed and analyzed.

The numbers matter less than what they prove: the platforms have to behave correctly when the network is actually live.

A monitoring platform has to stay available.
A telemetry system has to handle communication failures gracefully.
A dispatching interface has to remain clear under pressure.
A hydraulic model has to produce results engineers can defend.
A forecasting system has to support planning decisions, not just generate charts.

Reliability is part of how we engineer from the beginning, not a property we bolt on later.

Uptime is not just a metric we report - it is the operating standard we learned from years inside live infrastructure.

Math as the engine

Many industrial platforms stop at visualization.

Visualization is only valuable when it is connected to the physics, workflows, and decisions behind the network.

That is why MetaEnergy builds around applied mathematics, real-time data, and operational traceability.

Today that approach runs across four products:

MetaFlow for pipeline monitoring, dispatching, hydraulic analysis, simulation, alarms, and reporting.

MetaPulse for field telemetry, alarm handling, reporting, reconciliation, and operational audit trails.

MetaCast for natural gas demand forecasting across hourly, day-ahead, seasonal, and planning horizons.

Hydra for browser-based hydraulic calculations, sizing, capacity checks, and project-ready reports.

Each product has a different job.

The principle behind them is the same:

Operational data should become operational intelligence.

What this blog will be

This is the first post.

The rest will be more specific.

We will write here about the engineering decisions behind the platforms - what we measured, what surprised us, what we got wrong the first time, and what changes when the next three hundred devices arrive.

Less marketing, more field notes.

Pieces that an operator, dispatcher, engineer, planner, or technology leader would find worth reading even if they never buy our software.

We will write about SCADA, telemetry, hydraulic simulation, demand forecasting, digital twins, alarm workflows, data architecture, reliability, and the small operational details that decide whether a system is useful under pressure.

Not theory for its own sake.

Not generic software commentary.

Practical lessons from the intersection of energy operations, engineering, mathematics, and software.

The bottom line

Critical infrastructure software should not become another operational risk.

It should shorten the path from data to action.
It should make the live network clearer.
It should make engineering decisions more traceable.
It should help operators respond faster, plan better, and work with confidence.

We ran critical systems.

Now we are building what we wished had existed when we did.

From Data to Decisions.

Blog