> ## Documentation Index
> Fetch the complete documentation index at: https://getfloo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Sales Demos

> Ship a branded demo app that prospects sign into with their work email. Get real usage signal from every prospect who logs in.

A sales demo is one of the highest-leverage things floo is good for. You ship a real, working app — not a static deck, not a video — and every prospect who signs in becomes a measurable intent signal.

## What you get

* A branded demo on your own domain (`demo.yourcompany.com`).
* Managed sign-in — prospects authenticate with their work email. No shared passwords.
* Per-user tracking — you see which companies have logged in, when, and how often they've come back.
* Rapid iteration — push a change, the dev URL updates immediately, promote to production when it's ready.

## The flow

### 1. Build the demo

A small web app. Keep it focused on one or two workflows that showcase the value.

### 2. Configure managed auth

```toml theme={null}
[app]
name = "acme-demo"
access_mode = "accounts"

[services.web]
type = "web"
port = 3000
ingress = "public"
```

That's the entire auth config. floo's gateway puts a hosted sign-in page in front of the demo, validates each prospect's session, and tells your app who they are.

### 3. Decide who can sign in

For a sales demo, you typically want **anyone with a work email** — but not consumer Gmail. In the dashboard app settings, allowlist by disallowing common consumer email providers, or flip to manual approval if you want to gate access more tightly.

### 4. Add a custom domain

```bash theme={null}
floo domains add demo.acme.com --app acme-demo
```

Follow the DNS instructions in the output. TLS is auto-provisioned.

### 5. Deploy and share

```bash theme={null}
git push origin main
floo releases promote --app acme-demo
```

Give the link to prospects.

## What your app code does

When a prospect signs in, floo's gateway injects identity headers into every request that reaches your app. Pull `email` and split on `@` to get the company domain:

```python theme={null}
from fastapi import Request

@app.middleware("http")
async def attach_prospect(request: Request, call_next):
    email = request.headers.get("x-floo-user-email")
    request.state.prospect = {
        "email":   email,
        "name":    request.headers.get("x-floo-user-name"),
        "company": email.split("@")[1] if email else None,
    }
    return await call_next(request)
```

Tag telemetry by company domain and you have a leaderboard of engaged prospects — who logged in, from which company, and how deep they went. No JWT verification, no token refresh, no auth library.

## The usage signal

Sales teams using floo for demos typically do two things with the sign-in data:

1. **Pipeline visibility.** The app's Users tab shows every prospect who has signed in. Cross-reference that with your CRM and you know which open deals have real hands-on interest.
2. **Re-engagement.** Someone from a target account comes back three weeks after the first demo? That is a signal — you see it in floo, not as a CRM task two weeks late.

None of this requires an analytics pipeline, a segmentation tool, or engineering time. It is a side effect of managed auth.

## Keeping the demo fresh

The dev URL (`<app>-dev.on.getfloo.com`) stays live at all times. Use it to stage changes — update copy for a specific vertical, turn a feature on for a key account, demo a new integration — without touching the production URL your other prospects are already using.

When the change is good, promote:

```bash theme={null}
floo releases promote --app acme-demo --tag pitch-v2
```

<CardGroup cols={2}>
  <Card title="Custom Domains" href="/docs/guides/custom-domains">
    Put the demo on your own branded URL.
  </Card>

  <Card title="Managed auth reference" href="/docs/guides/app-auth">
    Identity headers, access policies, and access modes in detail.
  </Card>
</CardGroup>