DEV Community: Project Flash Build

A ServiceNow-style service desk you can self-host — as WordPress plugins

Project Flash Build — Wed, 08 Jul 2026 18:34:28 +0000

If you've ever stood up a service desk, you know the shape it needs: typed records (incidents, requests, assets), fields that mean something, queues, real permissions, and rules that push work forward. ServiceNow is very good at that shape — and it also deploys and prices like the enterprise platform it is. For a team of 5–50 people, renting a second platform just to run support is a heavy tax.

Here's the part that's easy to miss: that team already runs a permissioned, backed-up, CRUD platform every day. It's WordPress. What it lacks is the ITSM shape — and a low-code layer is exactly how you add it.

Give WordPress the shape

WP-PFManagement turns WordPress into a ServiceNow-style low-code platform. Without writing code you model typed entities (incident, request, asset), fields with real types, forms, lists and queues, row- and field-level permissions, and business rules that fire on change. Wire those together and you have a working service desk — incidents with an SLA field, a triage queue, an escalation rule — living in the wp-admin your team already opens every morning.

It's the ServiceNow idea (model your processes as data, ship apps on top) without the ServiceNow deployment: no second platform, no separate identity provider, no per-seat enterprise contract.

Why "on WordPress" is the feature

Because every ticket is a record in the same platform as the rest of your data, it composes with your stack instead of integrating with it:

A WooCommerce order can open an incident directly — the order is a native event, not a connector poll.
A visual workflow (the engine that ships beside the low-code platform) can watch incidents and act: escalate, notify, or hand a host-side job to an open-source Rust worker on your own machine.
Permissions are real and enforced at the row and field level — agents see their queue, contractors see only their tickets, nobody sees a field they shouldn't.

And it's not only a service desk: the same platform now ships Agile project management (a Kanban board and a Gantt where each task's width is its duration) on the same records, so the work and the plan live in one place.

Where it runs, plainly

Everything is plugins on your own server: no external SaaS, no telemetry, your data never leaves your database. The low-code platform and the workflow engine are commercial — licensed per domain, not per seat, and refundable — and on sale now: register, buy and self-host today, and the purchase is the trial. The AI agent that can design the whole schema from a sentence, and the Rust worker that runs host-side jobs, 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 a generated RMA file — at project-flash.com/use-case. Docs at /docs.

If your team already lives in WordPress, your service desk can live there too — typed, permissioned and automated, without renting a second platform to hold it.

Happy to answer anything about the permission model, how incidents compose with WooCommerce and workflows, or the per-domain licensing.

One WooCommerce order, five plugins: a self-hosted automation walkthrough

Project Flash Build — Wed, 08 Jul 2026 18:16:43 +0000

Let me trace a single event through a WordPress site that runs Project Flash — one WooCommerce order, all the way to a file generated on the company's own machine — because the interesting part isn't any one plugin, it's that the whole thing happens inside the site's own WordPress, with the data never leaving it.

1. The order (WooCommerce)

A customer buys a product. That's a native WordPress event — no connector polling "new order" from a cloud. Everything downstream hears it directly.

2. It becomes a ticket (WP-PFManagement)

The order opens an incident in a ServiceNow-style low-code platform: a typed record with fields that mean something (impact, status, the linked order, the customer). It lands in a real service desk — a queue with row- and field-level permissions — not a spreadsheet. Agents see their tickets; nobody sees fields they shouldn't.

This is the low-code layer: entities, forms, business rules, all modelled without writing code, running in the same wp-admin the team already uses.

3. A workflow reacts (WP-PFWorkflow)

The new incident is an event, and a visual workflow is listening. On a real canvas — triggers, conditional branches, function calls, error boundaries — the workflow decides what happens: check the order, branch on product and customer, and if the situation calls for it, ask for help.

Because it's a graph and not a linear recipe, the awkward cases (an API is down, the product is out of policy) are just other edges you drew, not walls you hit.

4. The AI agent triages (WP-PFAgent)

For the judgment call, the workflow hands off to the AI agent (open source, bring-your-own-LLM-keys). It reads the ticket and the order, classifies the issue, and proposes the next step against the platform's documented schema — and it asks for confirmation before it writes anything. It's leverage, not a black box: what it produces are real records you can inspect.

5. The work leaves PHP (wp-executor)

The resolution needs a file generated on the company's own machine — an RMA document, say. WordPress can't (and shouldn't) do that inside a web request, so it publishes a job to a queue. A single-binary Rust worker running on the company's own hardware leases the job, runs it under a local allowlist, generates the file, and reports back. Nothing transited a third party; the worker only ever talked to this WordPress.

6. Resolution

The generated file attaches to the ticket, a business rule closes the loop, and the customer gets their answer. One event, five plugins, one database — the customer's own.

Why do it this way

Every step above ran as a plugin inside the site's own WordPress. No external SaaS in the path, no per-task billing, no telemetry — the order, the ticket, the workflow state, the AI's output and the executor's result all live in one database the business owns.

Two of the five are open source and free (the AI agent, GPL-2.0; the Rust worker, MIT/Apache-2.0). The workflow engine and the low-code platform are commercial — licensed per domain, not per task, and refundable — and on sale now: register, buy and self-host today.

See the whole thing as real screenshots at project-flash.com/use-case. Docs at /docs.

Happy to answer anything about any hop in the chain — the data model, the workflow graph, the REST+HMAC queue, or the executor's allowlist.

An AI agent that designs your schema or workflow from a sentence — with your own LLM keys, inside WordPress

Project Flash Build — Wed, 08 Jul 2026 16:26:03 +0000

Most "AI in your app" turns out to be a chat box bolted onto a product, answering questions about it. We wanted the opposite: an agent that builds the product — that takes a sentence and produces the actual structured artifacts your platform runs on.

WP-PFAgent is that layer, and it's open source (GPL-2.0). You describe what you need in plain language — "a service desk with incidents, an SLA field, and a rule that escalates anything open over 24 hours" — and the agent designs it against documented schemas: entities, fields, forms, business rules, and workflow graphs. Not a mockup. The real definitions the low-code platform and the workflow engine execute.

It writes to the same primitives you would

The reason this works is that the platform underneath is already structured. WP-PFManagement models everything as typed entities, fields, permissions and rules; WP-PFWorkflow models automations as graphs of triggers, branches and functions. Those are documented, machine-legible primitives — so "turn a sentence into an app" is really "turn a sentence into the same objects a human would click together," and then you review and adjust them like anything else.

That means the agent isn't a black box that generates opaque output. It produces entities you can open, rules you can read, workflow nodes you can rewire. If it gets something 90% right, you fix the 10% by hand — you were going to own these definitions anyway.

Bring your own keys, any provider

The agent is bring-your-own-keys. You point it at your own LLM provider — OpenAI, Anthropic, Gemini, DeepSeek, Qwen, whatever you already pay for — and it uses that. Nothing routes through us. It works fine with cheap models; you're generating structured definitions against a schema, not writing novels. And because it's GPL and free, the suite is fully usable without it — the agent is leverage, not a lock-in.

Confirmation before it acts

An agent that can create entities and rules needs guardrails, so it has one: it asks for confirmation before any write or send. You see what it's about to create or change, and you approve it. The agent proposes; you commit. That keeps "designs your schema from a sentence" from turning into "silently rewired your production data model."

Where it runs, plainly

Like the rest of the suite, it's a plugin inside your own WordPress — no external SaaS, no telemetry, your data stays in your database, and the only outbound call is to the LLM provider you configured. The commercial pieces (the low-code platform and the workflow engine the agent designs for) are licensed per domain, refundable, and on sale now — register, buy and self-host today. The agent itself 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 a generated RMA file — at project-flash.com/use-case. Docs at /docs.

Describe the app; review what it built; ship it — on your own server, with your own keys.

Happy to answer anything about the schema the agent targets, the confirmation model, or bring-your-own-keys.

Your automation engine as WordPress plugins — a self-hosted alternative to Zapier and Make

Project Flash Build — Wed, 08 Jul 2026 16:24:20 +0000

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.

A Gantt where the bar's width IS the task's duration — built into WordPress, on live records

Project Flash Build — Wed, 08 Jul 2026 16:08:56 +0000

Most project tools keep your plan in one silo and the work in another. The Gantt lives in Jira or Asana; the tickets, the customers, the orders live somewhere else; and you spend your week keeping the two in sync by hand. Automation tools don't fix this — Zapier and Make move data between apps, but they have no data model and no notion of a plan. Nobody owns the place where planning and doing are the same thing.

We just shipped the opposite bet, and it runs entirely inside your own WordPress.

WP-PFManagement is a ServiceNow-style low-code platform — you model entities, fields, forms, lists, permissions and business rules, and ship real apps (ITSM, CRM, a service desk) without writing code. As of this week it also does Agile project management as a first-class citizen. Not a plugin bolted on the side: the plan is made of the same records as everything else you run.

The Gantt: width = duration

Open the planning canvas and every task is a bar. The bar's width is the task's duration — drag the right edge and you're changing the estimate, not a label. You draw typed dependencies between bars (finish-to-start and friends), drop milestones on the timeline, and right-click to connect two tasks the way you'd wire nodes on a canvas. Move a task and its dependents cascade.

If you've used a Gantt before, none of that is new. Here's what is: the bars, the dependencies and the milestones aren't chart decorations rendered from some hidden project file. They are records — rows in the same low-code platform your tickets and business rules already live in. The chart is just a view over data you can query, permission, and automate.

The Kanban board on the same data

The same records show up on a Kanban board: drag a card across committed → in progress → in review → done, filter by sprint. Move a card and the underlying record updates — there's no separate project tool holding a second copy of the truth. The Gantt and the board are two windows onto one dataset.

Why "records" is the whole point

Because the plan is data, your automations can act on it.

Shift a milestone and a workflow can fire — notify the stakeholders, reprice the engagement, open a risk ticket.
Move a card to done and a business rule can close the linked incident, log the hours, or kick off the next task.
A task bar is a record, so it obeys the same row- and field-level permissions as the rest of your data. Contractors see their tasks; nobody sees the budget field.

That closure — plan and automate on the same records, self-hosted — is the thing the automation-only tools structurally can't do (no data model) and the dedicated PM tools won't do (your plan is in their cloud, not next to your systems). WordPress stays the place where your business already runs; the planning layer just makes the plan part of it.

Where it runs, plainly

Everything is plugins inside your own WordPress. No external SaaS, no per-task pricing, no telemetry — your data never leaves your database. The low-code platform (and the workflow engine next to it) are commercial, licensed per domain, not per task, and refundable; they're 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 schema or a workflow from a sentence, and the single-binary Rust worker that runs host-side jobs, are both open source and free.

There's a worked end-to-end example — a WooCommerce order becoming a ticket, a workflow, an AI triage and a generated RMA file — at project-flash.com/use-case. Docs at /docs.

If you already live in WordPress, your next project plan doesn't have to move to somebody else's cloud to be a real Gantt. It can be data — right where the work is.

Happy to answer anything about the data model, the dependency/cascade semantics, or how the planning records hook into workflows.

A single-binary Rust worker that drains WordPress job queues

Project Flash Build — Wed, 08 Jul 2026 14:16:41 +0000

WordPress is a fine place to decide that work needs to happen and a terrible place to do heavy work.
Everything you run inside a request competes with your visitors; everything you run in WP-Cron competes
with luck. When our workflow engine needed to run shell commands, move files around and call LAN-only
APIs, we refused to do any of that inside the PHP request lifecycle — and we didn't want a SaaS in the
middle either. So we wrote wp-executor: a single-binary worker in Rust that polls a WordPress site
for jobs and runs them on your own machine, in your own tools. It's open source (MIT OR Apache-2.0):
https://github.com/Project-Flash-Build/wp-executor

The shape of the problem

The WordPress side (a workflow engine we build commercially) models automations as graphs. Most steps run
happily in PHP. But some steps are host-side by nature: run a script, read or write a file, hit an
internal service the web server can't reach. Those need an execution boundary that is not the WordPress
process — different machine, different privileges, different failure domain.

The classic answers are all unsatisfying:

WP-Cron / PHP daemon: still the same machine, same PHP, same privileges — no boundary at all.
A SaaS runner: now your shell commands, file paths and internal endpoints live in someone's cloud.
A message broker (RabbitMQ, Redis): real infrastructure — but now every WordPress install needs a broker, and most sites will never justify one.

We picked the boring fourth option: WordPress itself is the queue. The site already has a database, a
REST API and an authentication story. The engine writes jobs to a table; a REST surface exposes
poll/lease/complete; anything that can speak HTTPS can be a worker.

The protocol: poll, lease, execute, report

The worker's loop is deliberately dull:

GET the versioned contract document on startup — which capabilities the server expects, queue endpoints, signing requirements. The binary treats the server's contract as the source of truth, so a server upgrade doesn't require a worker rebuild unless the capability set itself changes.
Poll the queue endpoint on its own cadence (long-poll-ish, configurable interval).
Lease a job. Leases expire: if a worker dies mid-job, the job returns to the queue instead of vanishing. Idempotency keys keep a retried job from running twice.
Execute the job's capability locally.
Report a uniform result: { exit_code, stdout, stderr, output, duration_ms, error }.

Authentication is a per-worker bearer token, plus (by default) an X-PFW-Signature HMAC-SHA256 of the
request body, so a leaked TLS termination point still can't forge job results.

Capabilities, not arbitrary code

The worker refuses to be a remote shell. It implements exactly six typed capabilities — shell.run,
fs.read, fs.write, fs.list, http.request, system.info — and every one of them is gated by an
allowlist in the worker's own config. The server side keeps a per-worker allowlist too; a job runs
only if both agree. A compromised WordPress can't suddenly make your build machine exfiltrate files it
was never allowed to touch: the worker-side allowlist is enforced before execution, on hardware the
WordPress admin doesn't control.

Every capability carries a hard timeout and returns the same result envelope, which makes the workflow
side pleasantly uniform: a shell script that exits 3 and an HTTP call that returns 503 look structurally
identical to the graph.

Why Rust (the honest version)

Not for speed — the worker spends its life waiting on I/O. The actual reasons:

Single static binary. The install story on a random VPS, a Mac mini or a Windows box is "download, unzip, run". No PHP version matrix, no pip, no node_modules. rustls means not even an OpenSSL dependency.
A type system for the contract. Job payloads, capability schemas and result envelopes are typed end to end. Deserialization failures are loud and early.
Predictable long-running behaviour. A worker is a daemon; daemons written in scripting languages accumulate weird state. Ownership makes the "runs for six months" case boring.
Cross-compilation. Linux x86_64, macOS x86_64/aarch64 and Windows from one codebase, in CI.

The test story mattered too: the integration suite runs the whole worker loop against
wiremock standing in for WordPress, so cargo test needs no
WordPress at all.

Running it

wp-executor --base-url=https://your-site.tld --token=pfw_worker_1_xxx probe

A successful probe prints the upstream contract and exits 0. Install scripts ship for systemd, launchd
and Windows services; config is one TOML file (base_url, bearer_token, and optionally the allowlist,
poll interval, lease TTL, signing toggle).

What this buys you

A WordPress workflow can now say "run this backup script on the office NAS", "transcode this upload on
the GPU box", "call the ERP that only exists on the LAN" — and the thing that executes it is a process
you installed, on a machine you own, under an allowlist you wrote. WordPress stays the control
plane; your hardware stays the data plane; nothing transits a third party.

The worker is MIT/Apache-2.0 and needs no license to run. The WordPress side that publishes the queue is
our commercial workflow engine (that's the business model, stated plainly); its wire contract is public
REST and the worker consumes it as documentation. If you want to see the full picture there's a worked
example — a WooCommerce order turning into a ticket, a workflow, an AI triage and an executor-generated
RMA file — at https://project-flash.com/use-case.

Questions about the lease semantics, the allowlist model or the Rust internals are welcome — the code is
all in the repo.