The seams are the product

Almost every process automation project ends up needing three things at once: something to run the automatic steps, some screens where people do their part, and a process that decides who steps in and when.

The market sells you all three separately. An automation builder like n8n or Make for the first. A UI builder — Retool, v0, whichever — for the second. A BPMN engine like Camunda for the third. Each is good at its own job.

The problem is what sits between them.

Where it breaks

When the three layers live in different tools, the joins are yours. And the joins are what break.

• The workflow writes to a database the UI reads from, but nothing guarantees the schema matches. Change a field in the workflow and the screen stops working, silently.
• The process assigns a task to a role, but that role does not exist in the published app. Someone creates it by hand in both places and trusts themselves not to slip.
• A process step calls a workflow by webhook. When the workflow is renamed, the process still points at the old name and fails in production.

None of this is hard on its own. What is expensive is that it must be kept in sync by hand, forever, and that every new person on the team has to learn three tools before touching anything.

NoduxFlow's premise

Most tools give you one of the three layers and leave you the seams. NoduxFlow's premise is that the seams are the product.

The three layers — workflow, app and process — live on one canvas and are coupled by project. A serviceTask in the process calls a workflow that actually exists. A workflow writes what a page reads. A userTask lands in the inbox of a role that exists in the published app.

It is not that this is more convenient. It is that the three things you used to sync by hand can no longer drift apart: they are references, not strings that happen to match.

What is actually underneath

It is worth saying what is real and what is not, because this category over-promises:

• The flow engine executes a node graph with real connectors, retries and durable waits. It is not a drag-a-box demo.
• The process engine is token-based, with user tasks that have a real inbox, timers, compensation, correlation and incidents. It is a BPMN engine, not a pretty diagram.
• Apps are published to an address of their own, with permissions per page and per flow.
• A meta-agent can generate all three layers from a plain-language description and — this is the part that matters most to us — **it stops to ask when the decision genuinely belongs to the business** instead of inventing an answer.

That last point is what made us commit to the platform. A generator that fills gaps with plausible assumptions produces systems that look correct until somebody uses them. One that stops and asks produces less, more slowly, and usable.

When we use it, and when we don't

We do not build everything on NoduxFlow. When an engagement is an operational system with its own data model — an ERP, a forecasting engine — we build it bespoke, because the shape of the data *is* the product and should not live inside anyone else's abstraction.

We use it when the engagement is exactly what is described above: processes with automatic steps, people who intervene, and screens both of them share. Reinventing the engine there would be wasted work, and the seams we avoid are precisely where the next two years of maintenance budget goes.

It is the same reason both companies exist, and why the partnership makes sense: each does what it does well.