FlowX.AI

Merge conflicts & versioning

Processes in financial institutions used to take weeks to build, because two teams changing the same process at the same time had a very difficult time understanding what had changed between versions. There was no way to compare changes, no list of what had moved. And because it’s a low-code platform, most of the people actually configuring it for the client couldn’t read raw JSON or JavaScript to begin with.As a workaround, when merging two versions, they’d copy the code into VS Code just to read it, then come back and try to resolve the conflict on the platform itself.

The solution: translate a block of code into bite-sized, plain-language change descriptions, each tied to a clear location in the process, so the configurator could see what changed and where, with a clear path to the part in question, without reading the underlying code at all.

Merge resolution that used to take days, sometimes weeks, came down to days. Teams could now collaborate on the same process directly instead of working around each other, and the feedback from the client was strong.

We have expected this for quite some time now. Now the merge doesn’t fail anymore, and we can continue delivering at a fast pace.

Roughly five months, alongside other design work.

Comparing versions

Before even reaching a merge, configurators working on a project needed to know what had changed between two branches, to better anticipate any conflicts ahead of time. It also helped them understand more about the progress their teammates had made, with a bigger overview of the project as a whole.

Clicking into a branch surfaces the resources that changed and their type, color-coded by the kind of change: green for added, yellow for edited, red for removed, all relative to the previous version. Toggling compare mode lets configurators pick any two versions directly, not just adjacent ones, to see the progress of the project at any point in time.

Library-to-library dependencies

Large customers don’t build one app; they build a portfolio of them, and organize the shared parts (business processes, enums, templates, models, common logic) into reusable libraries. The catch: a library could only be consumed by a project, never by another library. So every domain team that needed the same KYC flow or the same customer model kept its own copy.

At the scale these organizations work, that copying compounds: the same logic duplicated across libraries, versions drifting apart, maintenance that means editing the same thing in five places, and a coordination tax between teams that grows with every new library. The design challenge was a dependency system that scales to hundreds of reusable resources while staying understandable and predictable: powerful underneath, calm on the surface.

Building on top, not copying across

The model I designed lets a library reference another library as a dependency instead of duplicating its assets. Shared resources are defined once and inherited everywhere downstream.

Making that safe meant deciding things before they could go wrong. A dependency is locked to a specific build when it’s added, so a foundation can move forward without silently shifting under everyone.

When two builds meet

Across hundreds of resources, two builds of the same library will eventually meet in one tree. Rather than asking a user to work that out from scratch each time, precedence follows a simple rule they can predict: the project’s own resource wins, then the closest library in the tree, with the newest build only as a tie-breaker. The same inputs always resolve the same way.

The payoff is architectural: enterprise teams can build modular, layered solutions, keep business definitions consistent, own their domains independently, and manage versions without fear. One update to a foundation propagates through everything built on it, instead of being re-typed into each library by hand.

Before that: copying resources

This wasn’t the first attempt at reuse. Before libraries could depend on libraries, we explored a more direct move: letting teams copy a resource (a process, a screen, an asset) from one project into another, together with everything it depends on.

It solved the immediate need and created a harder one. A copied resource could reference a library that already existed in the destination, but on a different build. As projects grew interconnected, the questions stacked up: keep the copy’s version, or the destination’s? What happens when several resources each need a different build of the same library? And, above all, how does someone see the consequences before they commit to them?

The design job wasn’t to expose the dependency machinery. It was to explain a genuinely complex situation in the simplest honest way, so a configurator could decide with confidence.

Three states, three moods. A plain copy shows New Dependencies: a calm preview of what’s about to be added. A version clash escalates to Dependency Conflicts Detected, with only the conflicting versions in red and a plain note that some usages may need fixing afterward. A copy that would create a loop is simply refused, in plain language: a circular reference, not a cryptic error.

The hardest case, several conflicts at once, gets its own view: Dependency Changes. New dependencies and version conflicts fold into one tree, so a single decision covers the whole impact. Depth by indentation, versions aligned on the right, red reserved for what actually conflicts: the hierarchy alone keeps a dense situation readable.

This exploration is what pointed to the library-to-library work. Once the real unit wasn’t a copied resource but a shared dependency, the problem changed shape: from reconciling one copy at a time to managing whole dependency trees on purpose. The same underlying question, asked better: how do you make a complex system legible enough that people trust their own decisions inside it?

UI Flows

BPMN was, and still is, the platform’s core. UI Flows didn’t replace it; it sat alongside it. The heavier processes stayed in BPMN, while UI Flows handled the simpler things that never needed a full process behind them: standalone pages, dashboards, client-360 views (a single all-round view of a client). It grew out of two practical needs. The platform was moving toward SaaS (software as a service), where standalone pages were suddenly in demand, and clients were asking for configurable chat agents.

The first version of its navigator shipped fast, because speed was genuinely needed. It showed:

• Switching the page felt disconnected from the rest of the navigator.
• Adding a new page while viewing another momentarily read as “my first page got deleted.”
• The collapse/expand icon on the tree didn’t communicate its function; there was a lot of hesitation around it.
• No process-like diagram existed for UI Flows. Joining a project meant real effort to figure out “which button leads where,” since navigation was buried inside each element’s event handlers, with no overview.

In hindsight: push earlier for a more considered first pass, by making a stronger case for it up front rather than optimizing purely for speed.

The navigation that shipped: a single vertical panel in the UI Designer’s left sidebar, split into two stacked sections. Navigationis a flat list of the flow’s root-level items (Pages, Tab Bars, Global Components). Components Tree is the full nested tree of whatever root or global component is currently selected. The two sections share one resizable vertical split, with the Components Tree taking two-thirds of the panel by default.

A newly created or reopened UI Flow opens directly on the Navigation tab, not the components list. Structure gets defined first (pages, header, footer), so that’s the natural starting point rather than an empty tree.

Chat & the AI agent

The chat component was the largest and most complex piece added for UI Flows. It meant designing both the chat UI itself and the agent-type workflows behind it. Over roughly six months, features arrived gradually: suggested prompts, notifications, the ability to upload and read documents, actions, and feedback.

• Message actions: copy message content, see the exact timestamp.
• Search across every past conversation by keyword.
• Chat sessions can be disabled once the linked business case reaches a status that no longer allows further interaction.
• Notifications surface new information in the chat with a visual cue.

The main challenge was understanding the needs of different clients’ chat use cases and prioritizing which to support. Some needed a floating chat; others a fixed interface where the content changed based on chat input; others a large, dedicated page with chat alone. That meant staying flexible while working within real technical constraints. A lot of small features folded into one component, needing fast delivery, attention to detail, and clear prioritization.

Config panels

The UI Designer’s config panel had aged out of step with the rest of the platform, full of form elements and interaction patterns that no longer matched. Feedback came directly from configurators on what they actually needed from it, and what they didn’t.

At the same time, a colleague on the MVP team was independently redesigning the Process Designer’s config panel, moving it from a bottom console to a side panel, the same pattern the UI Designer already used. Good for consistency, but it broke something. Referencing a Node Action from inside the UI Designer panel used to open the Process console on top, so a user could see the action’s context (business rules and so on) without losing their place. Once Process’s panel became a side panel too, that overlay no longer worked: two side panels wanted the same space at the same time.

Explorations ran in parallel with my colleague on both panels. A PR (pull request) built with Claude Code then stood up both panels quickly enough to test them against each other, rather than mocking them separately and guessing how they’d interact.

The panel that shipped: replacing content in place, with a way to navigate back. The referenced context takes over the panel rather than stacking a second one, with a path back to where you started.

Stronger overall visual consistency, and a more mature product perception, meaningfully so given the platform’s positioning as SaaS, where that kind of polish reads as credibility. Practically: less time spent configuring, and fewer panic clicks: the back-and-forth save clicks and the parallel tabs people opened out of uncertainty about what they were about to lose.