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.
Top comments (0)