# Worked examples

A **use case** is a problem to solve — a defined pain, stated in plain business terms: *"track OEE across three lines,"* *"warn the team before a tank runs dry."* The **solution** is an app — and a use case is rarely a single one. Most take **one or more apps working together**.

Each worked example takes a real use case and works it end to end — the same way a FlowFuse **Proof of Value** does: name the use case, break it into the apps that solve it, pin down how each app is delivered and what shape it takes, then draw the whole architecture.

A solution can be delivered different ways — **built entirely by FlowFuse, built together with your team, or built by you** from these examples. The breakdown is the same either way.

## From use case to apps

Every example runs the same four moves:

1. **Name the use case** — the pain in plain business terms, and what "good" looks like.
2. **Break it into apps** — list each app the use case needs and say, in one sentence, what it does. Most use cases are more than one app.
3. **Pin down each app** — for every app, name its **delivery method** (a [whole app](/docs/application-guide/app-delivery-methods/) or a reusable [piece](/docs/application-guide/app-delivery-methods/)) and its **app pattern** ([hardware](/docs/application-guide/app-delivery-methods/hardware-apps/) or [software](/docs/application-guide/app-delivery-methods/software-apps/) app), where it runs, and why that shape.
4. **Draw the architecture** — place the apps, the [data plane](/docs/application-guide/data-plane/) and the broker into one picture that shows how it ties together, and state the whole [architecture](/docs/application-guide/architectures/) in a sentence.

## The examples

<callout icon="i-lucide-arrow-right">

**OEE, end to end →** — one use case, two apps and two shared services, from edge to broker to cloud to history.

</callout>

More worked examples will land here — each one a use case, broken into its apps and drawn out end to end.
