Identity → Transaction → Control: the thinking framework that shaped Merlin

Before Merlin settled on an architecture or a stack, we first found a thinking framework. Identity → Transaction → Control became how we understand a problem before translating it into a system.

In an earlier post we talked about two patterns that kept repeating. There's a friend running a fashion brand, managing operations across several different apps at once — a till in one app, an online store in another, finances still in Excel. There are also friends who own vape stores, already using a single till app, but with data between branches not really connected yet.

That's how we came to understand the problem Merlin was meant to solve.

The next question was: how does a problem get translated into a system?

The answer turned out to be simpler than we imagined.

Every time we started discussing a feature, we kept coming back to the same three questions.

• How will the user see this feature?

• What actually happens when the feature is used?

• Who sets and controls everything behind the scenes?

At first, those three questions were just how we broke a problem down.

The more features we designed, the more often the same pattern kept resurfacing.

Every discussion could start from a different feature, but the conversation almost always ended up at those same three angles.

Eventually we felt this pattern deserved a name.

The goal was simple: to give us a shared language every time we discuss, evaluate, and decide.

Since then we've called it Identity → Transaction → Control.

One feature, three angles

One of the easiest examples to explain this thinking framework is Section Manager.

Section Manager is an admin panel used to control which sections appear on a store's page. An admin can show or hide a section, change its order, and arrange how the store page looks without touching any code.

When we looked at this feature through that thinking framework, we realized one and the same feature actually carries three angles.

From the Identity side, Section Manager decides how a store presents itself to a visitor. Which section appears first, what part deserves to stand out, and how the store's identity is shown on its public page.

Once a visitor opens that section, looks at a product, picks a variant, or adds an item to the cart, the focus shifts to Transaction. This is where the interaction between the user and the system happens.

Meanwhile, every setting about which sections show, their order, and who has the right to change them lives in Control, through the admin panel.

This is where we arrived at a new understanding.

Section Manager remains one single feature.

What changes is only the angle you look at it from.

From the user's experience, it speaks to Identity.

From the activity taking place, it becomes Transaction.

From the management side, it becomes Control.

That's when we started to see that Identity, Transaction, and Control aren't three parts of a system, but three ways of looking at one and the same feature.

Once we recognized that pattern, how we design features changed with it.

We no longer see a feature as one screen or one page, but as a single whole connected across three angles.

A way of seeing a system

The longer we've built Merlin, the clearer it's become that Identity, Transaction, and Control are a way of seeing a system.

Every feature can touch all three layers at once.

A change in Control can affect the Identity a user sees.

A change in Identity can also change the Transaction that follows.

All three stay connected because, from the start, they were always describing the same feature.

Since then, every time we start designing a feature, we keep coming back to the same three questions.

• How will the user see it?

• What actually happens?

• Who manages it and is responsible for it?

Interestingly, once those three questions start getting answered, many of the decisions that follow find their direction too.

The data structure becomes clearer.

Boundaries between components start to show.

The responsibility of each part of the system becomes easier to understand.

Architecture decisions then develop to follow those needs.

A thinking framework

Identity → Transaction → Control helps us understand a problem before we think about implementation — it's not meant to determine which technology ends up getting used.

A product will keep evolving.

Business needs will keep changing.

The technology used today may also be different in the future.

But as long as we start from the same three questions, we always have a clear starting point for the next decision.

To us, Identity → Transaction → Control isn't just three terms.

It's a thinking framework that helps us translate a business problem into a system.