Demo Apps

Demo Apps is our collection of public demo apps — a first-class asset alongside the PoV Workbook and the FlowFuse Trial Environment. Each use case is its own FlowFuse team, named Demo App - {Use-case name}.

The use case registry will live on the FlowFuse website (not inside FlowFuse): the website catalogs every use case so a prospect can find one relevant to them and explore it from the front end. The Demo then becomes a walk through the backend of a use case they have already seen. Because each use case is its own team and its own app, the collection shows FlowFuse is truly a platform for solving many use cases — not a single tool.

Planned — not yet built. The use case registry is a page to be built on flowfuse.com (intended location: /demo-apps/). The intent: a registry menu that flips through the use cases; for each one, a breakdown of the problem (the overarching use case detail), the app or apps that solve it, and the outcome — with a link to open that demo app's Dashboard 2.0 front end.

Publishing criteria

Every use case added to Demo Apps must meet these criteria:

  1. Its own team, named Demo App - {Use-case name}. Each use case is a dedicated FlowFuse team using that exact naming convention — not a shared team, a personal instance, or a one-off environment.
  2. A PoV doc for the use case. Every contributed use case has a PoV workbook defined that showcases FlowFuse's value over Node-RED — what the platform adds beyond the flows themselves. Source docs for use cases live in this shared folder.
  3. Built with the app delivery methods. The app uses one or both of FlowFuse's app delivery methods.
  4. Conforms to an app pattern. The app follows one of the app patterns in the Application Guide — a hardware app or a software app.
  5. Listed in the website use case registry. The use case is registered in the FlowFuse website's use case registry so prospects can discover it and explore it from the front end.
  6. A built-in architecture page. The app must include an architecture page that is the PoV doc visualized on the front end of the app — so a prospect exploring the front end sees the same architecture the PoV describes.

Together these make each demo app self-describing: a prospect finds a use case in the website registry, sees its architecture and value on the front end, and the sales Demo picks up from there in the backend.