Dogfooding
Synthetic users — Cast personas — that drive your product in a real browser on a schedule, record what they hit, and feed a daily Ranger that turns recurring problems into tickets.
Dogfooding puts synthetic users on your product so your backlog never goes empty. You create one or more Cast personas — each a synthetic user with a testing prompt, a device, and its own memory — and 1mn runs them through your app in a real browser on a schedule. Every session records a video and a worked / broke / missing report; a daily Dogfooding Ranger reads across all the sessions and turns recurring problems into tickets you can act on.
You manage all of this from the Dogfooding tab in the dashboard.
The daily cycle
Dogfooding is three loops working together, so no single agent both drives the browser and decides what's ticket-worthy:
- The scheduler wakes (once per day, on the cadence you set) and starts one session per active persona. It doesn't browse anything itself — it just fans the personas out.
- Each Cast session runs independently: the persona reads your app from source (when a repo is connected), drives Chromium via Playwright toward one concrete goal, records the whole run to one video, and saves a report plus structured observations. A session never files a ticket — see How a session works.
- The Dogfooding Ranger runs daily over the completed sessions. It clusters the observations across personas and days, keeps recurring problems (and discards one-off noise), and files evidence-backed tickets — flagged as synthetic. It's the Discovery Ranger for the
dogfoodingsource.
Cast personas
Create and steer synthetic users — a testing prompt or backstory, focus area, device, target URL, and login.
How a session works
What one persona does in a run: reads your source, drives a real browser, records a video, saves findings + memory.
Read-only, and aimed at staging
Cast sessions use your product; they never change it — no code, no commits, no tickets of their own. Because they drive a real browser (they click, type, and submit for real), aim them at a staging URL with a throwaway account, never production.
Point Cast at staging
Set the persona's Target URL to staging and give it a throwaway test account for flows that need a login. Credentials are encrypted at rest, decrypted server-side only, and never printed, logged, or shown in the recording.
What you get back
A findings report
Worked / broke / missing, each tied to a specific screen and action — no mood, no review-speak.
A session video
The full browser run, recorded — so you can see exactly what the persona saw.
Evolving memory
Each persona remembers past visits and re-checks whether last time's issues were fixed.
Tickets from the Ranger
Recurring, corroborated problems become tickets on your board, marked as synthetic evidence.
A paid feature
Dogfooding runs on your subscription. Sessions themselves don't consume credits — they're covered by the subscription, like chat and scheduled routines. If you create or run a persona on an unsubscribed workspace, the first run opens a checkout; the session starts automatically once payment clears. After that, personas wake on their own cadence.
Where it fits
Dogfooding is one of 1mn's three browser loops. The difference is who aims it:
| Loop | Aimed by | Output lands |
|---|---|---|
| Dogfooding / Cast | A persona pursuing its own goal, on a schedule | Session feedback + Ranger tickets |
| QA | You, per ticket, in free text | On that ticket |
| Story QA | Repo changes — it re-verifies inventoried feature stories | A finding ticket on failure/friction |
It's also the synthetic counterpart to the Recordings Reviewer: Cast drives your app as a synthetic user, the Recordings Reviewer watches your real ones.
Session recordings
Turn real visitor session replays into signal — a short written review of every recorded session, plus a draft ticket whenever one reveals a real UX problem, bug, or product insight. Read-only; it never changes your product.
Cast personas
Create and steer synthetic users — each with a testing prompt (or backstory), a focus area, a device, a target URL, and an optional throwaway login — and set the schedule they run on.