Product Roadmap
The product roadmap sets out what we are building towards with FlowFuse, 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.
- Vision — the destination we are working towards.
- Foundations — the pillars, lanes and customer problems that every roadmap item is measured against.
- Direction — the headline items we are considering over the next year.
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.
Foundations
This roadmap is built on strategy, principles and structure established in other parts of the handbook.
Source pages:
- Company Strategy — mission, market, problems, value, KPIs
- Company Messaging — pillars, ICP, positioning
- Product — outcomes model
- Product Swimlanes — lane definitions
- Product Principles — configuration and open-core rules
Aligning with our Company Strategy
Our 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 · Govern | Invest |
| 2 | Lack of visualization and feedback loops | Needs improvement | Build · Govern | Invest |
| 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.
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:
- How do humans use this feature?
- 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.
Direction
These are the outcomes we are working towards:
- FlowFuse provides a data layer that underpins the applications built on the platform
- A seamless onboarding journey from standalone Node-RED to FlowFuse managed
- Dashboard tooling that gets the job done without a steep learning curve
- An AI experience encompassing these things
Items under consideration
Below are the headline items we are considering over the next year.
They are not listed in any order and they are not commitments. The list will change as strategic priorities evolve, and items may be dropped.
Where a delivery date has been committed to a customer, that commitment lives in the relevant issue, not here.
Solution definitions are being worked through separately. Two items below hold regardless of where that work lands: Data Modeling and the Time Series Database underpin every solution candidate currently under discussion. The rest of the list will be re-cut once those definitions exist.
| Item | Lane | Pillar | Scope | Problem | Product outcome |
|---|---|---|---|---|---|
| Data Modeling — team-level versioned schema registry (JSON Schema) + NR validator node | Platform | Build · Govern | FlowFuse | Functional gap against competitors | A team defines a shared model once and validates against it in more than one flow |
| Time Series Database — team-scoped TSDB + NR nodes to read/write; management UI in a later iteration | Platform | 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 |
| Data Mapping Tooling — NR nodes for mapping message structure between models, UX-led | Platform | Build | FlowFuse | Mapping between models is manual and error-prone | A builder maps between two models without hand-writing transforms |
| FlowFuse Node-RED — supported distribution, drop-in for OSS Node-RED, runs standalone, FF features on connect | Platform | 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 | Platform | Deploy | FlowFuse | High barrier to connecting an existing install | An existing install connects without migration |
| Dynamic Flow Configuration — platform UX for key/value config + NR node to pull and cache at runtime | Platform | Deploy | FlowFuse | Environment variables are static and require a full redeploy to change | A team changes device-specific configuration without redeploying |
| Multi-user editing — extend multiplayer mode to interactive concurrent editing | Platform | Build | Node-RED | Collaboration on a single runtime is limited | Two people edit the same runtime without coordinating out of band |
| Bill of Material reports - downloadable SBOM | Platform | 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 | Platform | 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 |
| Dashboard: usable by default — better out-of-the-box defaults | Dashboard | Build | FF Dashboard | Too much work required to reach a good-looking dashboard | A first dashboard looks presentable without configuration |
| Dashboard: data-binding layer — widgets bind to tagged data values; flows update the data layer | Dashboard | 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 | Dashboard | Build | FF Dashboard | Grid layout can't represent a production line visually | A builder produces an HMI that mirrors the physical line |
| Dashboard: WYSIWYG layout authoring — drag, arrange, resize, configure, connect to data | Dashboard | 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 |
| AI: chat history — persistent history, separate chats each with their own context | 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 | 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 | AI | Build · Govern | FlowFuse | Sovereignty requirements rule out vendor-hosted models | Orgs with specific model requirements are able to use our AI services |
Known gaps, not yet scoped
Named as needed, with nothing on the list above that covers them. Recorded here so they are not lost, not as a commitment to build them.
- Scheduling and quality monitoring - identified as prerequisites for an OEE-style solution.
- Migration path for existing Node-RED users - we have an onboarding story for building from scratch, and a connection story for an existing install, but nothing for moving an established estate across.
- Ownership of ongoing maintenance - no way for FlowFuse to own the upkeep of a deployed solution on a customer's behalf, rather than handing that back to them.