Our Story

We’ve been building automations for retail brands for years.

Every project started simple — a workflow here, a validation rule there — but as they grew, things became messy. Each case was unique, yet underneath they all shared the same challenge: how do we describe the domain clearly?

We kept ending up with huge amounts of hard-coded logic. Maintaining it was painful. Changing it was worse.

Over time, we noticed something: whenever the business became complex, we naturally started drawing graphs.

It was easier to talk about stores, products, or processes as connected nodes than as endless SQL tables.

The more we worked this way, the more we realized — graphs weren’t just better for explanation; they were a better way to think about software itself.

Eventually, we saw the pattern repeating: the same kind of code, written again and again, slightly different for every client.

So we decided to stop rewriting it and build a foundation — an engine that helps software engineers describe their domain as a graph, define rules once, and keep everything consistent across tenants while allowing each tenant to extend their own model.

That’s how Domain Modeller was born.

Once we had a way to describe how the world looks, we wanted to capture how it changes.

We experimented with existing workflow engines, but none of them truly understood graphs — they all treated data as flat objects.

We needed a workflow engine that could talk to graphs, mutate them safely, and respect the same validation rules.

That’s when our two projects merged into one:

a single platform where the Domain Modeller and the Workflow Engine work together —

to describe the world, and to control how it evolves.