Demo

This document explains the process of delivering a sales demo of the features of FlowFuse. It is not intended to cover all features but to give potential customers a good understanding of FlowFuse's value. The demo outlined below is tailored for customers who are already familiar with Node-RED. A separate demo flow for Node-RED-unaware audiences is currently in development.

What the Demo establishes

The Demo is where the customer first meets the FlowFuse Application Guide. Its job is to establish two things:

• Fundamentals — what FlowFuse is and its core pieces. → Foundations
• App delivery methods — shipping the whole app by pipeline, or publishing reusable components to the Team Library. → App delivery methods

The use case shown in the demo is a hook, not the point — ideally something close or relatable to the customer's own problem from Discovery — used to make the delivery methods concrete. Coming out of the Demo, the customer should understand the fundamentals and the delivery methods: enough to move into the Solution stage, where the rest of the guide is tailored to their environment.

Tailored demos

A tailored demo is a real, working FlowFuse app built for a specific prospect's own use case, so the Demo walks the backend of their problem rather than a relatable stand-in. The goal is unchanged from any Demo — establish the fundamentals and the app delivery methods (how code and components are shared and shipped). Using the prospect's own use case simply softens a barrier: they don't have to make sense of an unfamiliar example at the same time as taking in what FlowFuse is and how it ships apps. Tailored demos are their own asset — built per deal, owned by the engagement. They are also the starting point for the public catalog: if a tailored demo turns out to be a strong, broadly relevant use case, we can later decide to roll it into the reusable Demo Apps registry so every prospect can find it. A canal monitoring and control demo, built for a water district from their own project plan, was the first of these.

The process for creating one:

1. Fill out a PoV workbook and put it in the customer's Google Drive folder. Take everything the customer has already shared — project plan, Discovery notes, requirements — and fill out a PoV workbook from it, one App tab per app. This is a required step of every tailored demo: the completed workbook goes in the customer's folder in Google Drive. Even when the engagement isn't formally a PoV, the workbook is the right shape — it's the same use case the customer would be scoping for themselves, so it keeps the demo anchored to real pains rather than a feature tour.
2. Review before building. The workbook gets a once-over from the SE lead before any build starts — confirming the right apps, the right architecture, and one tab per app. This review gate is what keeps the built demo honest to the use case.
3. Build the app in FlowFuse. Build the working app in a dedicated FlowFuse team for the customer, driven by the reviewed workbook.
4. Host the tailored front end. The app ships with its front end / architecture page hosted so the prospect can explore their use case ahead of the call.
5. Demo = walk the backend. On the call, walk the backend of the app they've already seen on the front end.

After the demo, decide whether the use case is worth publishing. A strong, broadly relevant tailored demo is a candidate to graduate into the Demo Apps registry — its own Demo App - {Use-case name} team — where it becomes discoverable to every prospect.

Filling the workbook and building the app are both AI-assisted (Claude, from the customer's project plan), which is what makes turning a prospect's requirements into a working, tailored demo fast enough to do per deal.

Standard demo environment

We have a team prepared on FlowFuse Cloud called Acme Manufacturing Corp which includes everything you will need to complete this demo.

Script for FlowFuse Demo

Note: This script is the current process and will be replaced soon, once the new demo infrastructure — the Demo Apps team — is fully established. The emerging model is that a prospect first explores a use case on the front end of a demo app, and the demo becomes a walk through its backend.

1. Introduction to FlowFuse
   • Explain that FlowFuse is a platform that allows users to host and manage instances of Node-RED, a popular open-source flow-based programming tool.
   • Mention that FlowFuse can be deployed in the cloud (e.g., AWS), on-premises, or in air-gapped networks, and the workflows demonstrated will work the same way regardless of the deployment model.
   • Highlight that FlowFuse provides a centralized way to manage multiple instances of Node-RED, both hosted directly on the FlowFuse server and remote instances running on edge devices.
2. Interacting with Remote Node-RED Instances
   • Demonstrate accessing a remote instance of Node-RED running on an edge device.
   • Explain the secure tunnel connection established from the web browser to the edge instance using HTTPS, which allows outbound-only connectivity from the edge to the FlowFuse server.
   • Open the Node-RED editor for the remote instance and show the flow that is simulating data from a production cell, including information about the current shift, temperature, cycle time, recipe, and production progress.
   • Highlight that the remote instances can continue to operate and collect data even when network connectivity to the FlowFuse server is intermittent, as the data is buffered and sent when the connection is restored.
3. DevOps Workflows
   • Make a simple change to the Node-RED flow, such as adding an inject node that outputs the string "hello demo".
   • Demonstrate the process of creating a new snapshot of the flow, which captures the specific versions of Node-RED and all dependencies.
   • Explain how the "target" setting ensures that the development instance will continue to run the new snapshot after the deployment, rather than reverting to a previous version.
   • Use the language model feature to automatically generate a concise description of the changes made to the flow.
   • Show how to deploy the new version from the development environment to the staging environment, highlighting the separation of concerns between the development and testing teams.
   • Explain the use of environment variables to manage different configurations (e.g., database credentials) for each stage (development, staging, production).
   • Deploy the new version from staging to the production environments in Japan, Europe, and the USA, demonstrating the speed and consistency of the deployment process.
   • Validate the deployment by opening a tunnel to one of the production instances and verifying that the "hello demo" change is present.
4. Data Aggregation and Visualization
   • Explain how the data from the remote Node-RED instances is being published to an MQTT topic using the Project Link nodes, which abstract away the complexity of setting up the MQTT broker.
   • Demonstrate a hosted instance of Node-RED that is subscribing to the MQTT topic and formatting the data, including identifying the source of each payload based on the environment variables.
   • Show the dashboard that is displaying the aggregated data from all the production cells, including the status (running, stopped), production metrics (actual vs. projected), temperature, and the ability to acknowledge and log stoppages.
   • Highlight the benefits of the Unified Namespace (UNS) approach, which makes the data easily accessible to any authorized application or user within the organization.
5. Additional Features
   • Discuss the Bill of Materials feature, which provides an audit of all the software dependencies (Node-RED versions, custom nodes, etc.) used in the application.
   • Explain how this information can be used to quickly identify and update dependencies if a security vulnerability is discovered in a specific version.
   • Demonstrate the user management and role-based access control features, and how they integrate with the organization's identity provider (e.g., Microsoft, Google) for seamless user provisioning and de-provisioning.
   • Showcase the Team Library and Blueprints features, which allow sharing of best practices and reusable Node-RED flows within the organization.
   • Highlight how the Team Library can be used to share code snippets, while Blueprints provide complete, ready-to-use Node-RED flows for common use cases.
6. Conclusion
   • Summarize the key capabilities of the FlowFuse platform demonstrated in the demo, such as remote Node-RED management, DevOps workflows, data aggregation, visualization, and the additional features that enhance collaboration and governance.
   • Emphasize how the platform can help organizations streamline their industrial automation and IoT initiatives by providing a centralized, secure, and scalable solution for managing their Node-RED deployments.
   • Encourage the audience to explore the FlowFuse platform further and consider how it could benefit their own use cases, whether in manufacturing, energy, transportation, or other industries.

White-Glove Onboarding Flow

We've launched a new sign-up flow where we offer white-glove onboarding to all customers. It’s designed to provide a tailored experience based on a lead’s specific operational needs and technical maturity. The process is triggered immediately when a customer signs up via the website, with HubSpot automatically handling contact creation. It also includes steps through a live demo on how to provision the customer with the correct license and start their trial. The entire flow, associated scripts, and documents can be found here.

More Resources

A video recording of this demo can be accessed here.

The technical setup for this demo is documented here.