Platform and engineering

The foundation is already running

A digital twin built from zero is a research project with a deadline attached. Ours start on a platform already proven in production, so the engineering goes straight into your assets, your data and the decisions you want to get right.

Twin projects stall at the plumbing

Digital twin projects stall in a predictable place. Not at the modeling — at the plumbing. Six months in, the team is still reconciling tag names between a historian and an ERP, and the twin that was supposed to predict something is a diagram with a data problem.

A platform does not remove that work, but it means the work is configuration rather than invention. The data fabric, the asset model, the time-series handling and the governance already exist and have been run by someone else, under load, before you.

What is left is the part that is actually about your operation: which assets matter, what good looks like for them, and what somebody should do when it stops looking that way.

The Duora platform showing a live digital twin of a hub motor: the exploded assembly with rotor temperature, magnet loss, angular velocity and torque streaming against it.

The platform we build on

We build on Duora, the operational digital twin platform from our partner Thingspine. It unifies operational, IT and engineering data into a governed model of a physical operation — plant, building, network or supply chain — and it already does the things operations teams ask for: predictive maintenance, energy optimization, throughput and asset performance.

Thingspine builds and maintains the platform. Toobler is the engineering. We connect it to the systems you run, model your assets and processes inside it, build the interfaces and calculations your teams work from, and write whatever your operation needs that the platform does not already cover.

That division of labor is the point: a specialist keeps the foundation current while our engineers spend their time on the part that is specific to you.

Toobler's part

What we build on top

  1. Integration into your systems

    Control systems, historians, sensors, ERP and the business software around them — connected and reconciled, which is where most twin projects actually stall.

  2. Your asset and process model

    The platform provides the modeling; what each asset is, how it behaves and what good looks like for it is specific to your operation and is engineering, not configuration.

  3. Calculations the panel cannot show

    Derived quantities — efficiency, condition, deviation — computed rather than read, because the useful number is rarely one an instrument reports.

  4. Interfaces your teams will use

    Operator, maintenance and leadership views built for the decision each one has to make, not a single dashboard that serves none of them well.

  5. Whatever sits outside the platform

    Where your operation needs something the platform does not cover, we engineer it — which is why the platform is a starting point rather than a ceiling.

  6. Running it, where you want that

    We can stay on and operate what we build. Most clients take it in-house, and it is engineered to be handed over.

Approach

How an engagement runs

  1. 01

    Start with the decision

    Which operational decision should get better. A twin with no decision attached is an expensive diagram.

  2. 02

    Connect what exists

    The systems, tags and data you already produce — mapped and reconciled onto the platform's model.

  3. 03

    Model your assets

    The part that cannot be bought: what your equipment is, how it behaves, and what it looks like when it is drifting.

  4. 04

    Put it where the decision is made

    On the line, in the control room or in the maintenance queue — not in a report somebody opens afterwards.

Start with the decision, not the technology

A readiness sprint maps the systems, the data and the integration surface, and comes back with what a twin would actually change — before anyone commits to building one.

Frequently asked

Do you build digital twins from scratch?
Usually we do not need to, and that is deliberate. Most operational twins start on Duora, a platform already running in production, so our engineering goes into connecting your systems, modeling your assets and building what your operation specifically needs on top.
Who owns Duora?
Thingspine, our partner. They build and maintain the platform; Toobler is the engineering partner that implements it, extends it and builds whatever your operation needs on top of it.
What does Toobler actually build, then?
The parts that are specific to you: the integrations into your control systems, historians and business software; the model of your assets and processes; the calculations and interfaces your teams work from; and anything the platform does not cover.
Does using a platform mean we are locked in?
The asset models, integrations and custom engineering we build are yours, and your data stays in your systems. The platform layer is licensed from Thingspine — the same arrangement as any infrastructure you build on — and we map exactly what sits where before you commit.
When would you not use it?
When the problem is narrower than a platform. The extrusion twin we built is a physics simulation of one machine, engineered directly — a platform would have been overhead. We pick per problem rather than per sale.

Start with one measurable use case.

A Readiness Sprint is a fixed-scope engagement that maps your integration and AI readiness and produces a production-oriented plan — before anything is built.