From a36c6b0aa88489861d76d10b9c8241bb0c528589 Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Fri, 21 Aug 2026 16:45:01 +0100 Subject: [PATCH 01/10] First iteration of product roadmap --- nuxt/content/handbook/company/strategy.md | 17 +- .../engineering/product/product-swimlanes.md | 33 ++- .../handbook/engineering/product/roadmap.md | 254 ++++++++++++++++++ 3 files changed, 287 insertions(+), 17 deletions(-) create mode 100644 nuxt/content/handbook/engineering/product/roadmap.md diff --git a/nuxt/content/handbook/company/strategy.md b/nuxt/content/handbook/company/strategy.md index 2b6f93f9cf..c31beefb87 100644 --- a/nuxt/content/handbook/company/strategy.md +++ b/nuxt/content/handbook/company/strategy.md @@ -27,15 +27,10 @@ any scale. Furthermore, FlowFuse aims to make it a great experience to build, deploy, and maintain software -- especially for non-software engineers. Allowing complex -things to be achieved. Two good examples are - -1. FlowFuse Dashboard - Allowing to build Dashboards and interactive - applications -1. Project-Link - Linking Edge devices to the Cloud, enabling broadcasts and - point-to-point connections +things to be achieved. A key differentiator for FlowFuse is our approach to licensing of our software. -The core is open, free as in beer and as in speech. Our product is open for +The core is open. Our product is open for scrutiny, usage, improvements, for the world. While there's a subset of the product proprietary licensed, the source is available to read. We believe that Open Source Software plays a key part in education, reducing vendor lock-in, and @@ -75,6 +70,14 @@ often Architects, Engineering Managers, and specialists in IT or OT. This complexity makes it difficult for teams to integrate and leverage data from different sources into a view of operations that can help identify optimizations. +1. No Control Over Applications at Scale: Once solutions spread beyond a single + Node-RED, teams lose track of what is running where, who changed it, and + whether it still meets the organisation's security and compliance obligations. + IT becomes accountable for systems it cannot see into, and OT gets slowed + by approval processes designed for a different kind of software. Teams + need change to be traceable, permissioned, and auditable across every + plant — without reintroducing the delays that drove them to low-code in the + first place. ## Why these problems are significant diff --git a/nuxt/content/handbook/engineering/product/product-swimlanes.md b/nuxt/content/handbook/engineering/product/product-swimlanes.md index 9138106805..5cd48af6bc 100644 --- a/nuxt/content/handbook/engineering/product/product-swimlanes.md +++ b/nuxt/content/handbook/engineering/product/product-swimlanes.md @@ -8,18 +8,31 @@ title: "Product Swimlanes" [Product swimlanes](https://en.wikipedia.org/wiki/Swimlane) are areas of focus and expertise within the Flowfuse product. ## Why we use them -Swimlanes allow us to -1. Develop deep expertise in a particular focus area of the product -2. Assign decision rights to an individual when it comes to the features, roadmap, design and stakeholders of that area -3. Ship Faster: The teams' velocity increases as they deepen their experience within the product area. + +They allow us to: +1. identify the functional areas we work within +2. provide enough granuality so that every feature has a natural home +3. ensure we are iterating across the whole product surface + +As a team, we routinely work across all of the lanes. ## Our swimlanes -### AI Focus -AI enablement within the FlowFuse platform, including the FlowFuse Expert AI agent which has offers support and enablement (basic, pro/free) and data insights (advanced enterprise). +| # | Lane | Scope | +| :---- | :---- | :---- | +| 1 | Edge & device | Device agent, fleet-scale provisioning, offline resilience, OS/hardware/container support matrix, brownfield protocol coverage | +| 2 | DevOps for OT | Environments, promotion pipelines, snapshots, git workflows, testing, rollback | +| 3 | Data layer | Broker, historian, contextualisation, Unified Namespace | +| 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-Node-RED users | +| 5 | AI | FlowFuse Expert, assisted authoring, data insights, MCP access to live data, agents at the edge | +| 6 | Enterprise readiness | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | +| 7 | Security & product hardening | Hardening, vulnerability posture, secure defaults | +| 8 | Ecosystem & extensibility | Certified nodes, catalogue, plugin/extension architecture, partner and OEM/white-label paths | +| 9 | Platform health | Debt, migrations, scalability, upgrade paths | + +Not all of these lanes can be handled equally. -### Edge Orchestration and data acquisition -Everything edge related, from data acquisition to fleet orchestration. +- **AI** is pervasive across the whole product surface. +- **Platform Health** is the ongoing background work that customers do not notice unless it doesn't happen. +- **Security & product hardening** splits into value delivered under the Govern pillar, as well as our own, non-discretionary compliance work. -### Platform Core -The engine that runs the ship. all things relevant to the platform and its operation and resilience. \ No newline at end of file diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md new file mode 100644 index 0000000000..d6a8d6c229 --- /dev/null +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -0,0 +1,254 @@ +--- +title: "Product Roadmap" +--- + +# Product Roadmap + +The product roadmap sets out what we are building towards with FlowFuse over the next three years, and why. + +It is a statement of intent that we can work towards as a company. + +We expect this roadmap to evolve as we progress along it - and this is reflected in the granularity of detail at each stage. + +- **Vision** — the destination we are working towards. +- **Foundations** — the pillars, lanes and customer problems that every roadmap item is measured against. +- **Year 1** — specific items, quarter by quarter. Deliberately granular: this is work we intend to do. +- **Year 2** — half-year themes, no dates. Each names what has to be true in Year 1 for it to start. +- **Year 3** — a small number of bets, stated as hypotheses. + +## Vision + +**FlowFuse provides a natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** + +## Foundations + +This section pulls key points from our strategy from other parts of the handbook and resolves it to a roadmap-usable form. + +Source pages: + +- [Company Strategy](https://flowfuse.com/handbook/company/strategy/) — mission, market, problems, value, KPIs +- [Company Messaging](https://flowfuse.com/handbook/marketing/messaging/) — pillars, ICP, positioning +- [Product](https://flowfuse.com/handbook/engineering/product/) — outcomes model +- [Product Swimlanes](https://flowfuse.com/handbook/engineering/product/product-swimlanes/) — lane definitions +- [Product Principles](https://flowfuse.com/handbook/engineering/product/principles/) — configuration and open-core rules + +### What we're anchored to + +| | | +| :---- | :---- | +| Mission | Empower 1 billion people to fuse the digital realm and physical reality by building bespoke workflows, applications, and integrations. | +| Success condition | Node-RED becomes the default way hundreds of thousands of people write software. FlowFuse remains its primary contributor and the best way to run it at any scale. | +| Positioning | The open-source Industrial Application Platform. Tagline: *The Edge-Native Platform for Industrial Applications*. | + +### Product Pillars + +**Pillars** are what the customer is doing. They're outcome-facing, and they're the justification — the answer to "why should this exist at all?" + +The company one-liner is the source: + +> Build, deploy, and govern operational applications across every plant and production line, distributed to the edge and accelerated by AI. + +**Build · Deploy · Govern** are the pillars. Every roadmap item advances at least one. An item that advances none is a candidate for the non-goals list. + +| Pillar | What the customer is doing | Roadmap test | +| :---- | :---- | :---- | +| **Build** | Creating the application, flow, model, or interface | Does this let someone build something they couldn't, or build it materially faster? | +| **Deploy** | Getting it running — and running correctly — across plants, lines, and devices | Does this make the tenth site as cheap as the first? | +| **Govern** | Keeping it secure, auditable, compliant, and under control at scale | Would an IT buyer approve rollout because of this? | + +### Product Lanes + +**Lanes** are where the work lives — the answer to "who does this, and what does it sit next to?". They're a working structure we chose to give the roadmap resolution. + +| # | Lane | Scope | +| :---- | :---- | :---- | +| 1 | Edge & device | Device agent, fleet-scale provisioning, offline resilience, OS/hardware/container support matrix, brownfield protocol coverage | +| 2 | DevOps for OT | Environments, promotion pipelines, snapshots, git workflows, testing, rollback | +| 3 | Data layer | Broker, historian, contextualization, Unified Namespace | +| 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-Node-RED users | +| 5 | AI | FlowFuse Expert, assisted authoring, data insights, MCP access to live data, agents at the edge | +| 6 | Enterprise readiness | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | +| 7 | Security & product hardening | Hardening, vulnerability posture, secure defaults | +| 8 | Ecosystem & extensibility | Certified nodes, catalog, plugin/extension architecture, partner and OEM/white-label paths | +| 9 | Platform health | Debt, migrations, scalability, upgrade paths | + +Not all of these lanes can be handled equally. + +- **AI** is pervasive across the whole product surface. +- **Platform Health** is the ongoing background work that customers do not notice unless it doesn't happen. +- **Security & product hardening** splits into value delivered under the Govern pillar, as well as our own, non-discretionary compliance work. + +### Lane → pillar map + +| Lane | Build | Deploy | Govern | +| :---- | :---: | :---: | :---: | +| 1 Edge & device | | ● | ○ | +| 2 DevOps for OT | | ● | ○ | +| 3 Data layer | ● | | ○ | +| 4 Application & UX | ● | | | +| 5 AI | ● | ● | ● | +| 6 Enterprise readiness | | | ● | +| 7 Security & hardening | | | ● | +| 8 Ecosystem & extensibility | ● | | | +| 9 Platform health | - | - | - | + +● primary · ○ secondary + +### Aligning with our Company Strategy + +Our [Company Strategy](https://flowfuse.com/handbook/company/strategy/) highlights five key customer problems we set out to solve. + +Here is how those problems can be ranked to align with where we are today and where we want to get to: + +| Rank | Problem | Our position | Pillar | Roadmap posture | +| :---- | :---- | :---- | :---- | :---- | +| **1** | Barriers to building solutions | The gap we most want to close — via AI and the platform tooling around Node-RED | Build | **Invest** | +| **2** | Lack of visualization and feedback loops | Needs improvement | Build · Govern | **Invest** | +| **3** | No control over applications at scale | A key concern for our typical buyer — with a lot of scope for improvement. | Govern | **Invest** | +| **4** | Data is in silos and inaccessible | Well served already | Deploy | **Maintain** | +| **5** | Overwhelming complexity of protocols | Well served by Node-RED integrations; AI helps simplify for the end user | Build · Deploy | **Maintain** | + +Note - **Maintain** does not mean low priority. They are problems we already serve well within the product, but we must not lose ground. They still require capacity within the roadmap. + +### AI + +AI is not a singular line item. It cuts across all three pillars and every lane, and exists to help the user reach their goal, whether by guiding them through their work or removing that work entirely. + +It is the driving force of achieving our vision - but needs the foundational work behind it to be successful. + +Each new feature needs to be shaped by the two-part question: + +1. How do humans use this feature? +2. How does the AI do it for them? + +AI is not the only route to a capability, but an acceleration to the value. + +There are three distinct roles for AI within the platform. + + - **Support mode** - help the engineer to build and manage their applications + - **Insights mode** - help the operator to understand what's happening + - **Operational mode** - bring intelligence to the applications being built + +Our current model places Support and Insights mode under the responsibility of FlowFuse Expert. +The Operational mode falls to AI capabilities being built into flows. + +### Certified Nodes + +Certified Nodes is where FlowFuse provides additional Governance assurance to customers about the nodes they are using. The product roadmap will continue to accommodate time and resources to sustain the Certified Nodes program. We will be customer-led when choosing what nodes to bring into the Certified Nodes program; there are costs and overheads for maintaining the nodes, so we must be led by demand to justify the ongoing investment. + +This roadmap does not highlight any specific nodes for the roadmap; that will be managed separately. + +## Year 1 — Q4 2026 to Q3 2027 + +### Year 1 outcomes + +1. FlowFuse provides a data layer that underpins the applications built on the platform +2. A seamless onboarding journey from standalone Node-RED to FlowFuse managed +3. Dashboard tooling that gets the job done without a steep learning curve +4. An AI experience encompassing these things + +**Note:** the sequencing of the items below is a work in progress. + +#### Q4 2026 + +| Item | Lane | Pillar | Scope | Problem | Product outcome | +| :---- | :---- | :---- | :---- | :---- | :---- | +| **Data Modeling** — team-level versioned schema registry (JSON Schema) + NR validator node | 3 Data layer | Build · Govern | FlowFuse | Functional gap against competitors | A team defines a shared model once and validates against it in more than one flow | +| **FlowFuse Node-RED** — supported distribution, drop-in for OSS Node-RED, runs standalone, FF features on connect | 1 Edge & device | Deploy | FlowFuse | Friction moving from standalone Node-RED to managed | A standalone user connects to the platform without rebuilding | +| **FlowFuse Node-RED Plugin** — connects an existing NR install to the platform, subset of Device Agent capability | 1 Edge & device | Deploy | FlowFuse | High barrier to connecting an existing install | An existing install connects without migration | +| **Dashboard: usable by default** — better out-of-the-box defaults | 4 Application & UX | Build | FF Dashboard | Too much work required to reach a good-looking dashboard | A first dashboard looks presentable without configuration | + +#### Q1 2027 + +| Item | Lane | Pillar | Scope | Problem | Product outcome | +| :---- | :---- | :---- | :---- | :---- | :---- | +| **Time Series Database** — team-scoped TSDB + NR nodes to read/write; management UI in a later iteration | 3 Data layer | Build | FlowFuse | Repeated customer signal from Fleet/Edge: nowhere to put event data that doesn't fit a relational model | A team stores event data on the platform instead of standing up their own store | +| **Dashboard: data-binding layer** — widgets bind to tagged data values; flows update the data layer | 4 Application & UX | Build | FF Dashboard | Widgets only update when a message arrives, so users wire messages into each one - overt complexity | A flow updates a value once and every bound widget reflects it | +| **Dashboard: canvas pages** — freeform WYSIWYG drawing with elements bound to live data | 4 Application & UX | Build | FF Dashboard | Grid layout can't represent a production line visually | A builder produces an HMI that mirrors the physical line | + +#### Q2 2027 + +| Item | Lane | Pillar | Scope | Problem | Product outcome | +| :---- | :---- | :---- | :---- | :---- | :---- | +| **Multi-user editing** — extend multiplayer mode to interactive concurrent editing | 4 Application & UX | Build | Node-RED | Collaboration on a single runtime is limited | Two people edit the same runtime without coordinating out of band | +| **Dynamic Flow Configuration** — platform UX for key/value config + NR node to pull and cache at runtime | 1 Edge & device | Deploy | FlowFuse | Environment variables are static and require a full redeploy to change | A team changes device-specific configuration without redeploying | +| **Dashboard: WYSIWYG layout authoring** — drag, arrange, resize, configure, connect to data | 4 Application & UX | Build | FF Dashboard | Page and layout authoring is unintuitive and the visual editor is limited | A builder lays out a page without trial-and-error redeploys | + +#### Q3 2027 + +| Item | Lane | Pillar | Scope | Problem | Product outcome | +| :---- | :---- | :---- | :---- | :---- | :---- | +| **Data Mapping Tooling** — NR nodes for mapping message structure between models, UX-led | 3 Data layer | Build | FlowFuse | Mapping between models is manual and error-prone | A builder maps between two models without hand-writing transforms | + +#### Not yet scheduled - work in progress + +| Item | Lane | Pillar | Scope | Problem | Product outcome | +| :---- | :---- | :---- | :---- | :---- | :---- | +| **AI: chat history** — persistent history, separate chats each with their own context | 5 AI | Build | FlowFuse | Context is lost between sessions | A user can have multiple chats and switch between them | +| **AI: custom team skills** — teams author skills specific to their use cases | 5 AI | Govern · Build | FlowFuse | Organizational standards aren't encoded anywhere the AI can apply them | Standardization of custom use-cases within an organization | +| **AI: custom models** — connect the agent to customer-hosted models | 5 AI | Build · Govern | FlowFuse | Sovereignty requirements rule out vendor-hosted models | Orgs with specific model requirements are able to use our AI services | +| **Bill of Material reports** - downloadable SBOM | 6 Enterprise readiness | Govern | FlowFuse | Existing BoM is a readonly page - cannot be snapshotted for audit or automated checks | Compliance requirements can be met | +| **Managed Dependency Updates** - actionable updates based on the SBoM at both a team and instance level | 6 Enterprise readiness | Govern · Deploy | FlowFuse | SBom identifies out of data dependencies, but doesn't help users resolve them | Software easier to keep up to date - either automatically or by policy | + +## Year 2 — Q4 2027 to Q3 2028 + +Half-year themes. No dates. Each names what has to be true in Year 1 for it to start. + +### Year 2 outcomes + +1. An IT team can evidence what is running, where, and whether it is compliant, without asking OT +2. The AI knows the organization's own standards and data, not just the product's +3. The data layer holds context, not just values + +### H1 (Q4 2027 – Q1 2028) + +| Theme | Lane | Pillar | Outcome | Depends on (Y1) | +| ----- | ----- | ----- | ----- | ----- | +| **FlowFuse Node-RED becomes the default install** — the standard way an industrial engineer installs Node-RED, not an alternative to it | 1 Edge & device | Deploy | New estates arrive connectable rather than needing to be connected | FlowFuse Node-RED and FlowFuse Node-RED Plugin (Q4 26), plus partner uptake | +| **FlowFuse provides a digital twin of an organization** — sites, lines and assets modeled on the platform and bound to live data | 3 Data layer · 4 Application & UX | Build · Deploy | An OT engineer can model their environment to gain insight | Data Modeling (Q4 26) | +| **Governance becomes purchasable** — downloadable SBOM, managed dependency updates, audit trail | 6 Enterprise readiness | Govern | An IT buyer can satisfy an audit from the platform rather than around it | Bill of Material reports · Managed Dependency Updates | +| **AI knows the organization** — custom team skills, custom models, persistent chat context | 5 AI | Govern · Build | Organizational standards are encoded where the AI applies them, and sovereignty requirements stop being a blocker | Data Modeling (Q4 26) gives the AI something structured to reason over | + +### H2 (Q2 2028 – Q3 2028) + +| Theme | Lane | Pillar | Outcome | Depends on (Y1) | +| ----- | ----- | ----- | ----- | ----- | +| **The data layer holds context** — contextualization, Unified Namespace, models shared across instances rather than per team, TSDB management UI | 3 Data layer | Build · Govern | A model defined once is used estate-wide, and event data is queryable without a separate stack | Data Modeling, Time Series Database and Data Mapping Tooling — all three Year 1 items | +| **DevOps for OT at fleet scale** — promotion, environments, rollback across sites | 2 DevOps for OT | Deploy | A change is promoted to fifty sites with the same confidence as one | Dynamic Flow Configuration (Q2 27) | + +## Year 3 — Q4 2028 to Q3 2029 + +Three bets. Each is a hypothesis with evidence conditions, not a commitment. + +### Natural language as the interface to the estate + +| | | +| ----- | ----- | +| Lane(s) | 5 AI · 3 Data layer | +| Hypothesis | With standardized models, MCP tooling and team skills in place, asking the estate a question becomes the primary way non-builders interact with what has been built. If true, Insights mode is a product line rather than a feature of Expert | +| What's genuinely uncertain | Whether customers will stand up and maintain their own MCP servers, and whether the end-user persona actually adopts a chat surface over a dashboard | +| Evidence that advances it | Insights mode usage by end users rather than builders. Number of customer-authored MCP servers connected | +| Kill criteria | If adoption of MCP tooling is still low by the end of Year 2, this is a feature and not a bet | +| Decision point | Q2 2028 | + +### FlowFuse Node-RED becomes the standard industrial distribution + +| | | +| ----- | ----- | +| Lane(s) | 1 Edge & device · 8 Ecosystem | +| Hypothesis | If the supported distribution is a genuine drop-in, it becomes what hardware partners ship and what engineers install by default, which collapses acquisition and deployment into one motion | +| What's genuinely uncertain | Partner trust. The barrier with vendors is not capability, it is willingness to ship someone else's distribution | +| Evidence that advances it | Share of new connections arriving via the distribution rather than migration. Partners shipping it preinstalled | +| Kill criteria | If by end of Year 2 the distribution is a minority of new connections, we are running two onboarding paths permanently and should pick one | +| Decision point | Q4 2027 | + +### Governed fleet at sovereign and air-gapped scale + +| | | +| ----- | ----- | +| Lane(s) | 6 Enterprise readiness · 2 DevOps for OT | +| Hypothesis | Air-gapped and sovereign deployment is a distinct product with its own economics, not a hardening checklist on the existing one | +| What's genuinely uncertain | Whether the demand is a handful of named accounts or a segment. Sovereign requirements also pull against the hosted-service assumptions the AI work depends on | +| Evidence that advances it | Sovereign or air-gapped requirements appearing as a qualification gate rather than a late-stage objection | +| Kill criteria | If it stays concentrated in a small number of accounts, it is bespoke delivery and should be priced that way rather than roadmapped | +| Decision point | Q1 2029 | From 9ca01910353d0cb58d99b68b9d065a396e25826b Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Thu, 27 Aug 2026 12:52:07 +0100 Subject: [PATCH 02/10] Apply suggestion from @ZJvandeWeg Co-authored-by: Zeger-Jan van de Weg --- nuxt/content/handbook/engineering/product/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index d6a8d6c229..7f89a62507 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -102,7 +102,7 @@ Here is how those problems can be ranked to align with where we are today and wh | Rank | Problem | Our position | Pillar | Roadmap posture | | :---- | :---- | :---- | :---- | :---- | -| **1** | Barriers to building solutions | The gap we most want to close — via AI and the platform tooling around Node-RED | Build | **Invest** | +| **1** | Barriers to building solutions | The gap we most want to close — via AI and the platform tooling. | Build | **Invest** | | **2** | Lack of visualization and feedback loops | Needs improvement | Build · Govern | **Invest** | | **3** | No control over applications at scale | A key concern for our typical buyer — with a lot of scope for improvement. | Govern | **Invest** | | **4** | Data is in silos and inaccessible | Well served already | Deploy | **Maintain** | From bb377f7e8d69c11ab50cd13735e4df31e58c8e25 Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Thu, 27 Aug 2026 12:52:20 +0100 Subject: [PATCH 03/10] Apply suggestion from @ZJvandeWeg Co-authored-by: Zeger-Jan van de Weg --- nuxt/content/handbook/engineering/product/roadmap.md | 1 - 1 file changed, 1 deletion(-) diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index 7f89a62507..5e29ddc75e 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -5,7 +5,6 @@ title: "Product Roadmap" # Product Roadmap The product roadmap sets out what we are building towards with FlowFuse over the next three years, and why. - It is a statement of intent that we can work towards as a company. We expect this roadmap to evolve as we progress along it - and this is reflected in the granularity of detail at each stage. From 2178a34cafbbe23915d2d03ab22dbdff92dcd6da Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Thu, 27 Aug 2026 13:25:49 +0100 Subject: [PATCH 04/10] Update from initial feedback --- .../handbook/engineering/product/roadmap.md | 75 ++----------------- 1 file changed, 6 insertions(+), 69 deletions(-) diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index 5e29ddc75e..8bfe56adcd 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -17,11 +17,11 @@ We expect this roadmap to evolve as we progress along it - and this is reflected ## Vision -**FlowFuse provides a natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** +**FlowFuse provides the application platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** ## Foundations -This section pulls key points from our strategy from other parts of the handbook and resolves it to a roadmap-usable form. +This roadmap is built on strategy, principles and structure established in other parts of the handbook. Source pages: @@ -31,81 +31,18 @@ Source pages: - [Product Swimlanes](https://flowfuse.com/handbook/engineering/product/product-swimlanes/) — lane definitions - [Product Principles](https://flowfuse.com/handbook/engineering/product/principles/) — configuration and open-core rules -### What we're anchored to - -| | | -| :---- | :---- | -| Mission | Empower 1 billion people to fuse the digital realm and physical reality by building bespoke workflows, applications, and integrations. | -| Success condition | Node-RED becomes the default way hundreds of thousands of people write software. FlowFuse remains its primary contributor and the best way to run it at any scale. | -| Positioning | The open-source Industrial Application Platform. Tagline: *The Edge-Native Platform for Industrial Applications*. | - -### Product Pillars - -**Pillars** are what the customer is doing. They're outcome-facing, and they're the justification — the answer to "why should this exist at all?" - -The company one-liner is the source: - -> Build, deploy, and govern operational applications across every plant and production line, distributed to the edge and accelerated by AI. - -**Build · Deploy · Govern** are the pillars. Every roadmap item advances at least one. An item that advances none is a candidate for the non-goals list. - -| Pillar | What the customer is doing | Roadmap test | -| :---- | :---- | :---- | -| **Build** | Creating the application, flow, model, or interface | Does this let someone build something they couldn't, or build it materially faster? | -| **Deploy** | Getting it running — and running correctly — across plants, lines, and devices | Does this make the tenth site as cheap as the first? | -| **Govern** | Keeping it secure, auditable, compliant, and under control at scale | Would an IT buyer approve rollout because of this? | - -### Product Lanes - -**Lanes** are where the work lives — the answer to "who does this, and what does it sit next to?". They're a working structure we chose to give the roadmap resolution. - -| # | Lane | Scope | -| :---- | :---- | :---- | -| 1 | Edge & device | Device agent, fleet-scale provisioning, offline resilience, OS/hardware/container support matrix, brownfield protocol coverage | -| 2 | DevOps for OT | Environments, promotion pipelines, snapshots, git workflows, testing, rollback | -| 3 | Data layer | Broker, historian, contextualization, Unified Namespace | -| 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-Node-RED users | -| 5 | AI | FlowFuse Expert, assisted authoring, data insights, MCP access to live data, agents at the edge | -| 6 | Enterprise readiness | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | -| 7 | Security & product hardening | Hardening, vulnerability posture, secure defaults | -| 8 | Ecosystem & extensibility | Certified nodes, catalog, plugin/extension architecture, partner and OEM/white-label paths | -| 9 | Platform health | Debt, migrations, scalability, upgrade paths | - -Not all of these lanes can be handled equally. - -- **AI** is pervasive across the whole product surface. -- **Platform Health** is the ongoing background work that customers do not notice unless it doesn't happen. -- **Security & product hardening** splits into value delivered under the Govern pillar, as well as our own, non-discretionary compliance work. - -### Lane → pillar map - -| Lane | Build | Deploy | Govern | -| :---- | :---: | :---: | :---: | -| 1 Edge & device | | ● | ○ | -| 2 DevOps for OT | | ● | ○ | -| 3 Data layer | ● | | ○ | -| 4 Application & UX | ● | | | -| 5 AI | ● | ● | ● | -| 6 Enterprise readiness | | | ● | -| 7 Security & hardening | | | ● | -| 8 Ecosystem & extensibility | ● | | | -| 9 Platform health | - | - | - | - -● primary · ○ secondary - ### Aligning with our Company Strategy -Our [Company Strategy](https://flowfuse.com/handbook/company/strategy/) highlights five key customer problems we set out to solve. +Our [Company Strategy](https://flowfuse.com/handbook/company/strategy/) highlights four key customer problems we set out to solve. Here is how those problems can be ranked to align with where we are today and where we want to get to: | Rank | Problem | Our position | Pillar | Roadmap posture | | :---- | :---- | :---- | :---- | :---- | -| **1** | Barriers to building solutions | The gap we most want to close — via AI and the platform tooling. | Build | **Invest** | +| **1** | Barriers to building solutions | The gap we most want to close — via AI and the platform tooling. | Build · Govern | **Invest** | | **2** | Lack of visualization and feedback loops | Needs improvement | Build · Govern | **Invest** | -| **3** | No control over applications at scale | A key concern for our typical buyer — with a lot of scope for improvement. | Govern | **Invest** | -| **4** | Data is in silos and inaccessible | Well served already | Deploy | **Maintain** | -| **5** | Overwhelming complexity of protocols | Well served by Node-RED integrations; AI helps simplify for the end user | Build · Deploy | **Maintain** | +| **3** | Data is in silos and inaccessible | Well served already | Deploy | **Maintain** | +| **4** | Overwhelming complexity of protocols | Well served by Node-RED integrations; AI helps simplify for the end user | Build · Deploy | **Maintain** | Note - **Maintain** does not mean low priority. They are problems we already serve well within the product, but we must not lose ground. They still require capacity within the roadmap. From b4305c01bef7ee89ef091aca7bfef7d5558350c1 Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Thu, 27 Aug 2026 13:26:46 +0100 Subject: [PATCH 05/10] Apply suggestion from @knolleary --- nuxt/content/handbook/company/strategy.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/nuxt/content/handbook/company/strategy.md b/nuxt/content/handbook/company/strategy.md index c31beefb87..0783d6ce79 100644 --- a/nuxt/content/handbook/company/strategy.md +++ b/nuxt/content/handbook/company/strategy.md @@ -70,14 +70,6 @@ often Architects, Engineering Managers, and specialists in IT or OT. This complexity makes it difficult for teams to integrate and leverage data from different sources into a view of operations that can help identify optimizations. -1. No Control Over Applications at Scale: Once solutions spread beyond a single - Node-RED, teams lose track of what is running where, who changed it, and - whether it still meets the organisation's security and compliance obligations. - IT becomes accountable for systems it cannot see into, and OT gets slowed - by approval processes designed for a different kind of software. Teams - need change to be traceable, permissioned, and auditable across every - plant — without reintroducing the delays that drove them to low-code in the - first place. ## Why these problems are significant From 750cfc480f70046094a8b13423c709c06068a9da Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Thu, 27 Aug 2026 13:43:25 +0100 Subject: [PATCH 06/10] Apply suggestion from @knolleary --- nuxt/content/handbook/engineering/product/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index 8bfe56adcd..16a284736d 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -17,7 +17,7 @@ We expect this roadmap to evolve as we progress along it - and this is reflected ## Vision -**FlowFuse provides the application platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** +**FlowFuse provides the platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** ## Foundations From 59db32f8c652efd20a66e9bc85ecad53bda40f2d Mon Sep 17 00:00:00 2001 From: Zeger-Jan van de Weg Date: Thu, 27 Aug 2026 14:41:05 -0700 Subject: [PATCH 07/10] Apply suggestion from @allthedoll Co-authored-by: Jamie Strusz <5758031+allthedoll@users.noreply.github.com> --- nuxt/content/handbook/engineering/product/product-swimlanes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nuxt/content/handbook/engineering/product/product-swimlanes.md b/nuxt/content/handbook/engineering/product/product-swimlanes.md index 5cd48af6bc..fef2a8683f 100644 --- a/nuxt/content/handbook/engineering/product/product-swimlanes.md +++ b/nuxt/content/handbook/engineering/product/product-swimlanes.md @@ -25,7 +25,7 @@ As a team, we routinely work across all of the lanes. | 3 | Data layer | Broker, historian, contextualisation, Unified Namespace | | 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-Node-RED users | | 5 | AI | FlowFuse Expert, assisted authoring, data insights, MCP access to live data, agents at the edge | -| 6 | Enterprise readiness | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | +| 6 | Governance and Operability | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | | 7 | Security & product hardening | Hardening, vulnerability posture, secure defaults | | 8 | Ecosystem & extensibility | Certified nodes, catalogue, plugin/extension architecture, partner and OEM/white-label paths | | 9 | Platform health | Debt, migrations, scalability, upgrade paths | From da57e2691c0234d37ca3f08bfccd31043cd8630e Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Fri, 28 Aug 2026 09:41:28 +0100 Subject: [PATCH 08/10] Apply suggestions from code review Co-authored-by: Jamie Strusz <5758031+allthedoll@users.noreply.github.com> --- nuxt/content/handbook/engineering/product/product-swimlanes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nuxt/content/handbook/engineering/product/product-swimlanes.md b/nuxt/content/handbook/engineering/product/product-swimlanes.md index fef2a8683f..d858a27a88 100644 --- a/nuxt/content/handbook/engineering/product/product-swimlanes.md +++ b/nuxt/content/handbook/engineering/product/product-swimlanes.md @@ -14,7 +14,7 @@ They allow us to: 2. provide enough granuality so that every feature has a natural home 3. ensure we are iterating across the whole product surface -As a team, we routinely work across all of the lanes. +As a team, we work across all of the lanes over time, but not all of them in any one release. A release will typically invest heavily in two or three lanes, touch a few others lightly, and do nothing in the rest. That's intentional prioritisation. ## Our swimlanes From c51061cf92ca34854d75f0041c4a01da12eed9d9 Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Fri, 28 Aug 2026 09:41:52 +0100 Subject: [PATCH 09/10] Apply suggestions from code review Co-authored-by: Jamie Strusz <5758031+allthedoll@users.noreply.github.com> --- nuxt/content/handbook/engineering/product/roadmap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index 16a284736d..4a16a72f61 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -123,7 +123,7 @@ This roadmap does not highlight any specific nodes for the roadmap; that will be | **AI: chat history** — persistent history, separate chats each with their own context | 5 AI | Build | FlowFuse | Context is lost between sessions | A user can have multiple chats and switch between them | | **AI: custom team skills** — teams author skills specific to their use cases | 5 AI | Govern · Build | FlowFuse | Organizational standards aren't encoded anywhere the AI can apply them | Standardization of custom use-cases within an organization | | **AI: custom models** — connect the agent to customer-hosted models | 5 AI | Build · Govern | FlowFuse | Sovereignty requirements rule out vendor-hosted models | Orgs with specific model requirements are able to use our AI services | -| **Bill of Material reports** - downloadable SBOM | 6 Enterprise readiness | Govern | FlowFuse | Existing BoM is a readonly page - cannot be snapshotted for audit or automated checks | Compliance requirements can be met | +| **Bill of Material reports** - downloadable SBOM | 6 Governance and Operability | Govern | FlowFuse | Existing BoM is a readonly page - cannot be snapshotted for audit or automated checks | Compliance requirements can be met | | **Managed Dependency Updates** - actionable updates based on the SBoM at both a team and instance level | 6 Enterprise readiness | Govern · Deploy | FlowFuse | SBom identifies out of data dependencies, but doesn't help users resolve them | Software easier to keep up to date - either automatically or by policy | ## Year 2 — Q4 2027 to Q3 2028 @@ -142,7 +142,7 @@ Half-year themes. No dates. Each names what has to be true in Year 1 for it to s | ----- | ----- | ----- | ----- | ----- | | **FlowFuse Node-RED becomes the default install** — the standard way an industrial engineer installs Node-RED, not an alternative to it | 1 Edge & device | Deploy | New estates arrive connectable rather than needing to be connected | FlowFuse Node-RED and FlowFuse Node-RED Plugin (Q4 26), plus partner uptake | | **FlowFuse provides a digital twin of an organization** — sites, lines and assets modeled on the platform and bound to live data | 3 Data layer · 4 Application & UX | Build · Deploy | An OT engineer can model their environment to gain insight | Data Modeling (Q4 26) | -| **Governance becomes purchasable** — downloadable SBOM, managed dependency updates, audit trail | 6 Enterprise readiness | Govern | An IT buyer can satisfy an audit from the platform rather than around it | Bill of Material reports · Managed Dependency Updates | +| **Governance becomes purchasable** — downloadable SBOM, managed dependency updates, audit trail | 6 Governance and Operability | Govern | An IT buyer can satisfy an audit from the platform rather than around it | Bill of Material reports · Managed Dependency Updates | | **AI knows the organization** — custom team skills, custom models, persistent chat context | 5 AI | Govern · Build | Organizational standards are encoded where the AI applies them, and sovereignty requirements stop being a blocker | Data Modeling (Q4 26) gives the AI something structured to reason over | ### H2 (Q2 2028 – Q3 2028) @@ -182,7 +182,7 @@ Three bets. Each is a hypothesis with evidence conditions, not a commitment. | | | | ----- | ----- | -| Lane(s) | 6 Enterprise readiness · 2 DevOps for OT | +| Lane(s) | 6 Governance and Operability · 2 DevOps for OT | | Hypothesis | Air-gapped and sovereign deployment is a distinct product with its own economics, not a hardening checklist on the existing one | | What's genuinely uncertain | Whether the demand is a handful of named accounts or a segment. Sovereign requirements also pull against the hosted-service assumptions the AI work depends on | | Evidence that advances it | Sovereign or air-gapped requirements appearing as a qualification gate rather than a late-stage objection | From 033d349ee5ccf6f8b81c8af52257164e49aa7adc Mon Sep 17 00:00:00 2001 From: Nick O'Leary Date: Fri, 28 Aug 2026 17:22:37 +0100 Subject: [PATCH 10/10] Apply suggestions from code review Co-authored-by: Costin Serban --- nuxt/content/handbook/engineering/product/product-swimlanes.md | 2 +- nuxt/content/handbook/engineering/product/roadmap.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/nuxt/content/handbook/engineering/product/product-swimlanes.md b/nuxt/content/handbook/engineering/product/product-swimlanes.md index d858a27a88..7c2348e08f 100644 --- a/nuxt/content/handbook/engineering/product/product-swimlanes.md +++ b/nuxt/content/handbook/engineering/product/product-swimlanes.md @@ -23,7 +23,7 @@ As a team, we work across all of the lanes over time, but not all of them in any | 1 | Edge & device | Device agent, fleet-scale provisioning, offline resilience, OS/hardware/container support matrix, brownfield protocol coverage | | 2 | DevOps for OT | Environments, promotion pipelines, snapshots, git workflows, testing, rollback | | 3 | Data layer | Broker, historian, contextualisation, Unified Namespace | -| 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-Node-RED users | +| 4 | Application & UX | Dashboard, HMI, blueprints, the build surface for non-technical users | | 5 | AI | FlowFuse Expert, assisted authoring, data insights, MCP access to live data, agents at the edge | | 6 | Governance and Operability | SSO/SCIM, RBAC granularity, audit, HA, air-gapped, multi-tenancy | | 7 | Security & product hardening | Hardening, vulnerability posture, secure defaults | diff --git a/nuxt/content/handbook/engineering/product/roadmap.md b/nuxt/content/handbook/engineering/product/roadmap.md index 4a16a72f61..bd9993c9a1 100644 --- a/nuxt/content/handbook/engineering/product/roadmap.md +++ b/nuxt/content/handbook/engineering/product/roadmap.md @@ -17,7 +17,7 @@ We expect this roadmap to evolve as we progress along it - and this is reflected ## Vision -**FlowFuse provides the platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** +**FlowFuse provides the platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to manage your industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.** ## Foundations