Building a low-code/no-code platform

Introduction

Low-code/no-code platforms, among today’s most popular tools, enable users to create, execute, and maintain workflows with minimal or no need for professional coding, thanks to their ability to shorten software development processes.

You can find information on how to use these platforms or access pre-built workflows in many resources and incorporate them into your projects.

In this article, we’ll focus more on the engineering side of low-code/no-code platforms. We’ll discuss how these platforms are built, what factors are considered during the development process, and their technical details. Throughout this article, we’ll also share the insights we’ve gained while developing PARS.guru, a low-code platform that offers capabilities similar to a Business Rule Engine (BRE).

Who is this article for?

The content presented here is a technical article primarily aimed at those who wish to build such a platform, are curious about how these systems work behind the scenes, or are interested in their architecture, rather than end-users of these platforms.

Before diving deeper into the subject, it’s worth clarifying a few basic distinctions.

The difference between low-code, no-code, and pro-code

No-Code (Zero-Code)

These platforms allow users to develop workflows without writing a single line of code. They utilize drag-and-drop interfaces and pre-built components. It is one of the fastest methods; prototypes can be created in a matter of hours. The capabilities offered by the platform determine the scope of the work.

Target Audience: Business analysts with no programming knowledge, entrepreneurs, and end users known as “citizen developer”.

Examples: Zapier, Wix, etc.

Low-Code

These platforms combine the visual ease of no-code development with the ability to add manual code when needed. They are much faster than the pro-code process and offer significantly greater flexibility than no-code solutions. Database management processes and API integrations are more advanced and manageable on these platforms.

Target Audience: Professional software developers, product managers, operations leads, individuals, and teams with technical expertise who want to speed up processes.

Examples: PARS.guru, n8n etc.

Pro-Code (Traditional Software Development)

This is the traditional software development process. Software developers write code using specific programming languages. Pro-code involves the slowest development process among the various methods. It offers unlimited flexibility; here, the only limits are imagination and hardware capabilities.

Target Audience: Professional software developers and teams.

Bonus:

Vibe-Code (Vibe-Coding)

Although it may seem unrelated to our current topic, briefly touching on vibe-coding could be helpful for getting a broader perspective. Today, low-code and vibe-coding approaches are increasingly converging, giving rise to an entirely new field. In short, vibe-coding is the process of using natural language (English, Turkish, etc.) to instruct artificial intelligence to generate the code we want through prompts.

The architecture of low-code/no-code platforms

At its core, a low-code/no-code platform consists of several integrated layers. Beyond the Visual Builder, which is the interface where users design their applications, it encompasses critical components such as the Workflow Engine that orchestrates processes, Node Structure, Trigger Mechanisms, Data Storage, and various Integrations.

These layers work in coordination with one another across the entire system.

Now let’s take a closer look at base three layers; Visual Builder, Workflow Engine and Node Structure.

Visual Builder (Canvas that user designs workflow)

This is the layer where users create and manage their workflows and typically spend the majority of their time. Users can drag and drop pre-built nodes onto the editor to design their desired logic.

If a visual editor is not your primary focus or if you don’t require highly specialized node structures, out-of-the-box solutions like go-rules/zen-editor or drawflow can be used.

However, such out-of-the-box solutions are typically limited; they may not be customizable or may only offer a certain degree of flexibility, thereby not providing you with a wide range of options.

If your platform includes:

• multiple node types
• a custom theme
• embedded custom components (e.g., Monaco editor, forms, or tables)
• a bespoke data model

In such cases, you will need a flexible foundation like React Flow or Vue Flow. Rather than simple ‘plug-and-play’ editors, these are extensible frameworks that allow you to build a fully custom visual environment tailored to your specific needs.

When building PARS.guru, we used Vue Flow specifically to customize our nodes according to our requirements and to enable the creation of complex workflows. This gave us a nearly limitless playground.

Important considerations regarding Visual Builder;

1. Key Components

Every visual builder must include certain core components that are critical to the user experience. The primary goal of such platforms is to provide business analysts, software developers, or citizen developers using the editor with a simple and understandable interface. Features such as a minimap and zoom, which are typically included by default in most standard or custom libraries, must be included in your platform.

Features such as the ability to focus on specific nodes in a workflow, lock the visual builder, add sticky notes to the current workflow, and undo/redo support, as well as the ability to hide various components to expand the workspace when needed, may seem like simple details at first glance. However, these features are of critical importance for user experience in low-code/no-code platforms.

An example of a visual builder prototype:

visual builder example

2. Creating a Shared Structure

Each node must follow a common base structure. This structure must be applied as a standard for all nodes added to the system in the future. Once a common model for the node structure has been established, processes such as categorization, node type definition, and naming must be carefully defined and standardized. The same standards apply to the edges (connection paths) linking the nodes.

3. Validation

The types of nodes that a particular node type can connect to (type compatibility; for example, rules such as being able to connect only to a “Y” node after an “X” node) must be defined in advance. In addition, the use of mandatory nodes and edges must be enforced; for example, on some platforms, the use of a “Start” and “End” node may be required before a workflow can be saved.

Managing scenarios such as requiring the workflow to run successfully at least once before it is saved is of critical importance for system integrity. Furthermore, providing users with real-time alerts and feedback during all these validation processes directly impacts the user experience.

type compatibility example

4. Import/Export

Import/export capabilities are critical to a platform’s flexibility. Requirements such as moving workflows between different environments (test, production) can be a lifesaver in development processes. Without a powerful import/export mechanism, it is nearly impossible to share a created workflow with different users or systems.

Additionally, if your vision includes creating a “Template Marketplace,” this capability will be the keystone of your platform. It’s important to remember that one of the primary growth and marketing strategies for platforms like n8n is to distribute workflows designed for specific use cases through a community or marketplace.

What should the format be?

Popular data formats such as JSON, YAML, or XML can be used. Many low-code/no-code platforms offer the ability to export files with the .json extension as a standard feature. In this context, following market standards is a sensible approach for ease of integration. We, too, have chosen to use a simple and lightweight JSON schema in PARS.guru’s import/export mechanism.

What Should Be Included?

The node and edge data that form the foundation of the Visual Builder must be included in the file. In addition to these, the following components should be included:

• Node Data: Configurations, codes, rules, etc., within the node.
• Workflow Metadata: Workflow name, description, version information, etc.
• Location Information: Node location, source and target points of edges.
• Trigger Configurations: Optional settings for the mechanisms that initiate the workflow.

What Should Not Be Included?

For security reasons, “secret” data (such as API keys, passwords, private keys, etc.) used in the workflow must not be included in these export files under any circumstances. Environment variables or a secure “secret manager” should be used to manage this type of sensitive data.

Example export json file:

{
  "name": "Example Workflow",
  "nodes": [
    {
      "type": "startNode",
      "content": {
        "schema": ""
      },
      "id": "a681aaed-490d-41e6-9351-9f09bd22e9e4",
      "name": "start",
      "position": {
        "x": 240,
        "y": 125
      }
    },
    {
      "type": "endNode",
      "content": {
        "schema": ""
      },
      "id": "04a37b2d-f6b6-4010-8aba-1b582e642bd3",
      "name": "end",
      "position": {
        "x": 895,
        "y": 100
      }
    },
    {
      "type": "functionNode",
      "content": {
        "source": "export const handler = (input) => {\n  return input;\n};"
      },
      "id": "8c2cc51b-f746-44c6-aac8-fe1a145df85f",
      "name": "function1",
      "position": {
        "x": 540,
        "y": 135
      }
    }
  ],
  "edges": [
    {
      "id": "60e17844-96b2-4783-8194-bcda17c1cf39",
      "sourceId": "a681aaed-490d-41e6-9351-9f09bd22e9e4",
      "type": "edge",
      "targetId": "8c2cc51b-f746-44c6-aac8-fe1a145df85f"
    },
    {
      "id": "7a0f3f8d-11a9-43ca-b9d7-f13fa73e7125",
      "sourceId": "8c2cc51b-f746-44c6-aac8-fe1a145df85f",
      "type": "edge",
      "targetId": "04a37b2d-f6b6-4010-8aba-1b582e642bd3"
    }
  ]
}

Workflow Engine Design

There are many different approaches to workflow engine design; DAG (Directed Acyclic Graph), state machine, event-driven architecture, petri nets, BPMN, and the actor model are just a few of them.

Modern platforms mostly adopt a hybrid combination of these approaches. Today, we will focus on the three most common approaches encountered in the industry: DAG, state machine, and event-driven.

DAG (Directed Acyclic Graph) Execution Model

This is an approach where workflows advance in a specific direction, and the graph architecture itself never contains circular dependencies (infinite loops). The process is modeled as a directed and acyclic graph. In this structure, each node represents an independent unit of work, while each edge connecting the nodes represents the dependency relationship between these tasks. The engine executes the workflow by following these nodes and edges based on their order of dependency.

How It Works

• Predecessor Dependency: Each node is triggered only when all of its preceding nodes (predecessors) have successfully completed their execution.
• Parallel Branching (Successor): If a node is followed by multiple subsequent nodes (successors), the workflow branches out in parallel, executing them simultaneously.
• Join Point: A node with multiple predecessor nodes naturally acts as a “Join” point, waiting for all incoming paths to be completed before it can execute.

Advantages

• The flow is easily understandable.
• Every input you send always yields the same output (of course, if an agent node is used within the workflow, the output may change due to the LLM).
• There is no risk of infinite loops.
• It is easy to analyze statically; analyses such as detecting unconnected nodes, rule violations, or conditions that will never be true can be easily performed.

Disadvantages

• A structural loop (cycle) is forbidden. The engine will not run, but the looping issue can be solved with a special node, which is optional.
• A dynamic flow is difficult; telling the architecture to “re-run this node” at runtime goes against the design.
• Long-running processes require additional mechanisms for the DAG structure.

DAG example

State Machine (FSM / Statechart) Execution

State machine execution manages a workflow through defined states and transitions. At any given moment, the workflow is in only one state. Moving to the next state is only possible when a specific event triggers it. The execution engine receives the incoming event, checks the transition rules of the current state, and executes the transition if the defined guard (condition) is met.

During this process, three steps run in order:

1. Exit Action: Leaving the current state.
2. Transition Action: The movement between states.
3. Entry Action: Entering the target state.

Throughout these steps, the workflow’s context (active data) is updated, and the current state is saved to the database. Thanks to this model, a workflow can wait for hours, days, or even months. Even if the system goes down, the state remains safe in the database, and when a new event arrives, the workflow continues exactly where it left off.

Advantages

• Loops and retries are natural; going back to a previous state is normal behavior.
• Long-running processes can be managed easily.
• Pausing and resuming is straightforward.

Disadvantages

• It can be difficult to understand the overall flow.
• Parallel workflows are hard to implement.
• Managing states can become challenging, which may lead to a combinatorial explosion.

Event-Driven / Reactive Execution

The system operates on a publish/subscribe principle without direct connections between nodes. When a node completes a task, it publishes the result as an event to a message broker (such as Kafka, RabbitMQ, or Nats). All nodes subscribed to this event are then triggered and begin working independently. This is a loosely coupled and asynchronous structure where the producer does not know its consumers, and the consumers operate without knowledge of each other.

Advantages

• Ideal for distributed systems.
• Reactive: Naturally triggered by external events (webhooks, user actions, etc.).
• Loosely coupled: Adding a new consumer does not affect the existing producer.

Disadvantages

• Complex debugging: Distributed tracing is required to follow the end-to-end flow.
• Incompatible with visual builders: Hard to show users “this node runs after that node” in low-code platforms.
• No ordering guarantee: It is not guaranteed that events will be processed in order.

Engine Approach in PARS.guru

PARS.guru has an execution engine that uses a hybrid combination of three paradigms: DAG (weighted) + State Machine + Event-Driven. In this architecture, while DAG acts as the core engine, the state machine layer persists the workflow state and provides resume capability for long-running processes; the event-driven layer handles integration with external systems (webhook, email, message queue, manual triggering).

Thanks to this hybrid structure, PARS.guru offers a visual DAG suitable for low-code/no-code platforms; users can design their workflows intuitively on a Vue Flow-based canvas. The engine provides high performance by automatically distributing parallel branches (fork/join) into goroutines. At the same time, thanks to the state persistence mechanism, it supports long-running workflows that can last for days, such as approval processes or operations waiting for payment. Its structure, which can be triggered by events from external systems, enables real-time integrations.

Most modern low-code/no-code platforms (Temporal, n8n, AWS Step Functions) adopt similar hybrid approaches; this strategy combines the strengths of each paradigm to offer the user both visual simplicity and enterprise-grade reliability.

Node Structure and Diversity

The node diversity and node architecture provided by a low-code/no-code platform directly determine the amount of flexibility available to the user. Basic flow control nodes (Start, End, Switch etc.) are standard across all platforms; however, specialized nodes are added based on the target audience and usage scenarios. For instance, offering Function/Script Nodes for users with a technical background transforms low-code platforms into comprehensive workflow automation tools.

PARS.guru includes a Function node that allows users to write and execute JavaScript code. However, due to security risks, this node is run in an isolated environment using Goja (Go-based JavaScript interpreter); user codes are sandboxed within the Go runtime. There is no access to dangerous APIs such as the file system, process spawn, or native modules (only access to console, fetch, basic array/object operations, and the workflow context is provided). This approach does not grant the user full JavaScript freedom, but it is necessary for the balance of security and performance. Alternatively, fully isolated sandbox solutions, such as running code in Docker containers, are more secure but bring higher infrastructure costs and latency.

Beyond basic nodes, platforms generally add domain-specific nodes: Decision Table (business rule management), AI Agent (AI integration), Sub-workflow (modular structures), and Database/API connector nodes (data source integration) are examples of these. These specialized nodes offer target users a higher level of abstraction and the possibility of rapid prototyping. The success of modern low-code/no-code platforms comes from establishing the right balance between generic and specialized nodes; too few nodes limit the user, while too many nodes increase the learning curve and make the platform overly complex.

Summary

Building a low-code/no-code platform is a long-term, multi-layered engineering process. Defining the target audience (business analysts, developers, or citizen developers?) and industry (data engineering, business process automation, IoT, finance) before starting the project directly impacts critical architectural decisions. For example, PARS.guru focuses on business rule management use cases, which is why we prioritize specialized nodes like “Decision Table Node” and “Expression Node”.

In this article, we focused on three core layers that form the foundation of a low-code/no-code platform:

1. Visual Builder: The canvas where users design workflows; libraries like Vue Flow/React Flow, node structure, validation, import/export mechanisms.
2. Execution Engine: A hybrid combination of DAG, state machine, and event-driven paradigms; parallel execution, state persistence, resume capability.
3. Node Architecture: Shared base structure, categorization, security (sandbox), specialized node development strategies.

However, a production-ready platform requires many more layers: Trigger Mechanisms (webhook, cron, email, message queue, etc.), Data Storage & Versioning (workflow state persistence, execution logs, version control), AI Integration (LLM-powered operations like AgentNode), Multi-tenancy & Organization Management (security, isolation, RBAC), Observability & Logging (distributed tracing, audit trail, performance metrics). Each of these topics deserves its own article; I will cover these layers in detail in future posts.

Feel free to reach out if you have any questions or feedback.