Per-task pricing is a tax on success. The more your automations actually run, the more you pay — and every task carries your orders, your forms and your customers through somebody else's cloud on the way. For a business that already runs on WordPress, that's a strange arrangement: you self-host everything that matters, then rent the automation layer forever and hand it your data as rent.
We built the other option, and it's plugins inside your own WordPress.
WP-PFWorkflow is a visual workflow engine. Not a recipe list — a real canvas. Triggers, conditional branches, function calls and error boundaries are first-class elements you wire together, the way you'd expect from a proper automation tool. Workflows react to events that already exist across your site — a WooCommerce order, a submitted form, a changed record — and run where those events live, without a round trip to an external service.
A canvas, not a wizard
The difference shows up the moment your automation stops being a straight line. Real processes branch: if the order is over €500 and the customer is new, route to manual review; otherwise auto-approve. They fail: an API is down, a file is missing, a downstream call times out. On a recipe-style tool, that's where you hit a wall. On a canvas with conditional branches and error boundaries, a failure is just another edge you drew — you decide what happens next, and the graph keeps its shape.
Because the engine lives inside WordPress, its triggers are the events you already have. No polling an external connector for "new order" — the order is a native event, and the workflow hears it directly.
When the work has to leave PHP
Some steps don't belong in a web request: run a shell script, move a file, call a service that only exists on your LAN. For those, the engine hands work to wp-executor — a single-binary worker (open source, Rust) that polls your WordPress over REST, leases the job, and runs it on your own machine, in your own tools, under an allowlist you control. WordPress stays the control plane; your hardware stays the data plane; nothing transits a third party.
So the reach isn't limited to what a SaaS connector catalog offers. It's whatever your own environment can do — because the thing executing it is a process you installed, on a box you own.
The honest comparison
We're not competing on connector count. Zapier and Make have thousands of cloud connectors; if your automation is "SaaS A → SaaS B," they're built for that. Our bet is depth inside WordPress plus reach into your own machine: the engine sits where your business data already is, and the executor extends it into your own infrastructure. Against Uncanny Automator's WP↔WP recipes, the difference is a real graph engine (branches, functions, error boundaries) instead of linear recipes. And "no SaaS" is literal here: no external runtime, no telemetry, licensing per domain, not per task.
Where it runs, plainly
Everything is plugins on your own server. Your data never leaves your database. The workflow engine (and the low-code platform beside it) are commercial, licensed per domain and refundable — on sale now, so you can register, buy and self-host today, and the purchase is the trial. The AI agent that can design a whole workflow from a sentence, and the Rust executor, are open source and free.
There's a worked end-to-end example — a WooCommerce order becoming a ticket, a workflow, an AI triage and an executor-generated RMA file — at project-flash.com/use-case. Docs at /docs.
If your automations are earning their keep, they shouldn't cost more every time they succeed — and they shouldn't ship your data to a cloud you don't own. They can run where your business already does.
Happy to answer anything about the branch/error-boundary model, the REST+HMAC contract to the executor, or the per-domain licensing.
Top comments (0)