PlatformDigital Twins

Mirror the application on your operating model. Then retire it.

“Why are we still paying for a system that does one thing — and that one person understands?”

Show Dotwork an existing system — its data, its screens and its API. Dot and the AI Studios read it, model it, connect it and load it onto your unified operating model, with Integration Hub and the Ingestion Engine doing the heavy lifting. Bespoke, one-off and expensive applications become a twin you can check side by side — and switch off when the business is ready.

Twin a system with us How a twin is built

Source system

Capital Request Tracker

Custom app · built 2014

Twin

On your operating model

Live · read-only sync

Read6 screens · 1 export · API docs
Modeled9 object types · 74 fields · 12 relationships
ConnectedScheduled sync from the source API
Loaded3,412 requests · totals match source
Side by sideBusiness sign-off pending

Linked · StrategyLinked · BudgetLinked · PortfolioLinked · ArchitectureLinked · Controls

Illustrative view · sample data

The pressure

Every bespoke system is a silo you pay for twice.

Once in licences, hosting and upkeep. Again in the work of reconciling it with everything else. The tracker someone built in 2014, the point tool one team bought, the enterprise suite renewed for the two modules anyone uses — each holds a slice of how the company runs, and none of them talk to the budget, the portfolio or the architecture.

What it looks like today

One-off apps that only one person knows how to change
Renewals for suites where you use a fraction of what you pay for
Data that never meets the strategy, budget or architecture
Consolidation programs measured in years, not conversations

What changes

What changes.

TodayWith Dotwork

Requirements workshops before anything is built

Dot reads the system and proposes the model in a conversation

A new application to build, host and maintain

A twin on the operating model you already run

Migrating the data and hoping it matches

History loaded, checked against the source and traced to where it came from

Another silo, rebuilt somewhere else

Connected to strategy, money, portfolio, architecture and controls from day one

A big-bang cutover

Both systems side by side until the business signs off

What Dot reads

Start from the system you have, not a blank requirements doc.

The fastest specification for a system is the system itself. Dot works from what it holds, what people see and what it exposes — and from the people who use it every day.

The data

Exports, spreadsheets and extracts — what the system actually holds, and how much of it.

The interface

Screenshots of the screens people use, so Dot sees the fields, statuses and views that matter.

The API

Documentation and sample responses, so Dot sees every field the system returns and how records relate.

The way it’s used

The people who run it describe the process, the approvals and the rules — in a conversation.

How a twin is built

Seven steps. Most of them are a conversation.

Because the platform is AI-native, each step that used to be a project is now a conversation with Dot in one of the studios — and every change is previewed before it’s live.

01
Read the system
Dot
Dot studies the data, screens and API and drafts what the system is made of: the things it tracks, their fields and statuses, and how they relate.
02
Model it
Ontology Studio
The draft becomes object types, fields, relationships and lists on your operating model — reusing what’s already there — previewed and validated before anything is deployed.
Ontology Studio
03
Connect it
Integration Studio
Dot reads the system’s API documentation, sets up the connection and maps its responses to fields on a schedule. The source stays the system of record while you transition.
Integration Studio
04
Load the history
Ingestion Engine
Records come in from exports, matched to what’s already in the model by key, with counts and totals checked against the source.
Ingestion Engine
05
Rebuild the views
Apps Studio
The lists, boards and readouts people relied on, rebuilt on live data — and connected to everything else on the model.
Apps Studio
06
Carry over the rules
Actions Studio
Approvals and business rules become skills and decisions, built with Dot, with the right approvers named.
Actions Studio
07
Run side by side, then switch
You
Both systems run while the business checks the twin. When they sign off, the original is retired — or kept as an archive.

Why a twin, not a rebuild

The twin doesn’t just replace the system. It connects it.

A rebuild gives you the same silo on newer technology. A twin puts the process on the model where the strategy, money and architecture already live.

It lands connected

The twin joins strategy, budget, portfolio, architecture and controls the moment it’s deployed — the relationships the old system never had.

AI-ready from day one

Dot and every MCP client can read and work with the twin, signed in as the person and within their permissions.

Nothing new to run

No code to maintain, no servers to host and no single person who knows how it works.

It keeps changing in a conversation

The model, connections, views and rules keep evolving through the studios — without a change request to a vendor.

Good candidates

Where twins pay back fastest.

Any system that holds part of how the company runs — and that you’d rather not keep paying for, maintaining or reconciling by hand.

One-off and bespoke

Internal tools, databases and spreadsheet-driven trackers that run a real process — and that nobody wants to maintain.

Capital requestsRisk registersVendor trackersDemand intake

Overlapping point solutions

Tools that each hold a slice of the operating model in a silo, bought one team at a time.

OKRs and goalsRoadmapsStatus reportingSurveys

Expensive enterprise applications

Suites renewed every year for the few modules people actually use, where consolidation is already the goal.

Portfolio managementGRC registersIT financial managementArchitecture repositories

Consolidation

What retiring a system gives back.

Application rationalization decides what should go. A twin is how it actually goes — without losing the process, the history or the people’s way of working.

Application rationalization Enterprise Architecture

When the original is switched off, you stop paying for

The licence or subscription
Hosting and infrastructure
Maintenance and the integrations around it
The key-person risk of the one person who knows it
The reconciliation work between it and everything else

And the process it ran is now connected to the budget, portfolio and architecture.

A safe transition

Nothing switches until the business says so.

A twin is built beside the original, not on top of it. The source keeps running, the twin is checked against it and people decide when it’s ready.

The source stays untouched

Connections read from the original system. Nothing in it changes while the twin is built.

Previewed before it’s deployed

Model changes are previewed and validated first, and changes to a live site can pause for approval.

Checked against the source

Counts and totals are compared with the original before anyone is asked to switch.

Traced to where it came from

Loaded records keep a link to the source they were loaded from.

Your permissions apply

The twin inherits Dotwork’s roles and permissions from day one.

You decide when to switch

Both systems run side by side until the people who own the process sign off.

Built with you

Twin your first system alongside our engineers.

Our forward deployed engineers work beside your team on the first twin — and leave your people able to build the next one themselves.

Forward Deployed Explore the AI Studios

How it compares

Rebuilding an application creates another application. A twin consolidates one.

A custom rebuild or a low-code app replaces one silo with another. A Dotwork twin moves the process onto the operating model the rest of the company already runs on.

Capability	Custom rebuild	Low-code app platforms
Starts from the existing system’s data, screens and API	Partly	Partly
Model proposed by AI in a conversation		Partly
Nothing new to host or maintain		Partly
Connected to strategy, money, portfolio and architecture
History loaded and checked against the source	Partly	Partly
Readable by every AI through MCP		Partly
Runs side by side before you switch	Partly	Partly

The model underneath

Every module makes the next one smarter.

Steer, Fund & Optimize and Govern & Deliver all read and write the same Enterprise Operating Model. The first module you license builds the model. Every module after it adds context instead of another silo — and Dotwork AI reads all of it, stopping where the decision is yours.

See the Enterprise Operating Model

Be Decisive.Build Fast.Connect Everything.

Start Connecting

Dotwork

The living model of your organization

Twitter•LinkedIn•YouTube