Launched this week
Workflo
Mac workspace automation that never sees your screen
77 followers
Mac workspace automation that never sees your screen
77 followers
Workflo sets up your Mac automatically — staging the right windows before a call or a focus block, and restoring your layout when displays change. Runs on Accessibility alone: it structurally cannot read your screen. Native Swift, ~4 MB, one-time purchase, local-only.
Workflo
Hi Product Hunt, Chirag here! 👋
Workflo is my answer to a small tax I paid every day: rebuilding my Mac workspace from scratch at every context switch. A call, a focus block, docking at my desk, each one meant another minute lost to reopen, drag, resize, and hide windows and my workspace.
Every tool I tried made that minute faster, but they all wait to be asked. Workflo removes the asking. It learns your layout for each display setup (Desks), stages the right windows before calendar events or at set times (Scenes), and snaps everything back when displays change. One hotkey clears the screen for a share and restores it after (Stash).
One design constraint I held onto: it runs on the Accessibility permission alone. It never asks for Screen Recording, so it structurally cannot see what's in your windows; the preview-style tools need that permission; Workflo doesn't. We do not collect, record, or transmit any data from your device. Everything stays local.
($19.99 one-time, 7-day free trial, no account, ~4 MB of native Swift. 20% OFF to celebrate the launch this week. I'm also giving away 5 free licenses today; at the end of the day, I'll send them to the people whose feedback shaped the roadmap most.)
I'll be here all day - please tell me which context switch annoys you most, and what per-app rules you'd love to see.
Workflo
@damien_schreurs Thanks, Damien; really appreciate the thoughtful note and the use case. Scenes do have per-Scene keyboard shortcuts, so your Stream Deck flow works with Workflo today: just assign the combo to a key, and it fires the Scene. And agreed, Moom + Spaces + Stream Deck is a strong setup. Calendar and clock triggers do not replace that; they cover the step before you reach for the shortcut.
On the Space trigger: macOS does publicly announce that the active Space changed, but not which Space you landed on. So "on any Space switch" is doable, while "on Space 3 specifically" takes a bit more care. Good idea though, noted!
Also on the roadmap: Focus mode triggers and Shortcuts actions. That is the fun part: once applying a Scene becomes a Shortcuts action, anything that can run a shortcut can become a trigger, including your Stream Deck, and Shortcuts Automations like Focus, Wi‑Fi, or opening a specific app can chain straight into it.
A project or client switch like yours is exactly the kind of trigger pattern I wanted to learn about, so thanks again for sharing it.
The context switch that costs me most right now is jumping between Chrome windows during browser automation, several profiles connected at once, and I have to figure out which one is actually signed into the right account before every session. Is a rule that snaps a specific browser profile window to a fixed spot when it becomes the active target in scope for Workflo, or is this more about layout than window identity?
Workflo
@abdullah_javaid3 Good news and one honest caveat. Chrome puts the profile name in the window title when you run multiple profiles (just tested: "… - Google Chrome - Person 1"), so each profile's window is identifiable.
The caveat: Workflo currently matches titles from the front, and the front of a Chrome title is whatever tab is active, so the stable part (the profile suffix) isn't what the matcher reads yet. That's a small fix, and it's going on the roadmap alongside the other half of your ask: a "when this window becomes active, snap it here" trigger (today's triggers are time and calendar).
Two questions back: how many profiles at once, and are they regular Chrome profiles or automation-launched with their own user data dirs? The second kind drops the suffix, which changes how I'd build this.
@ch1rag Five at once today, all regular Chrome profiles with an extension driving them, not spawned with their own user data dirs. So the title suffix should already be there in my case. Good to know that distinction matters this much though, would not have thought to mention it otherwise.
Workflo
@abdullah_javaid3 Five regular profiles are the best-case setup, since each window carries its suffix and all the identity data is present. On my side, there are two pieces to build: teaching the matcher to weight that stable suffix over the changing tab title, and adding the on-focus trigger so the snap fires the moment a window becomes the active target. Both are scoped, and window matching is already being overhauled on a branch this week. I will ping this thread when it ships. Thanks for spelling out the setup so clearly; this went from a vague idea to a buildable feature in one comment.