A real incident, a technical owner, and a next action.
This is deliberately narrower than an open beta. The programme works best when
there is a dynamic request that still executes WordPress and someone able to act
on or delegate the diagnosis.
Strong fit
Agencies or freelancers managing dynamic client sites
Slow checkout, admin, editor, REST, AJAX, cron, or logged-in work
A suspected regression after a plugin, theme, core, or configuration change
Evidence needed for a developer, host, client, or plugin vendor
Probably not a fit yet
A brochure site seeking a one-click PageSpeed score increase
A request served entirely from a page cache or CDN
An expectation that WP Flame will change settings or repair the site automatically
No technical owner available to act on the evidence
How the programme works
Evidence first, with explicit boundaries.
01
Qualify the workflow
We confirm that the incident is eligible, dynamic, reproducible, and commercially meaningful.
02
Authorise the site
Every customer or production site requires separate written authorisation before installation or trace review.
03
Capture within bounds
We choose an appropriate capture mode and record what the trace could and could not observe.
04
Review the evidence
We inspect the largest measured contributors, confidence, supporting samples, and the safest next action.
05
Verify the change
Where the workflow permits, we repeat compatible captures and compare the evidence before and after.
Programme participation does not grant permission to publish trace data, research notes,
a testimonial, or a case study. Each use requires separate, specific consent.
Design-partner application
Bring one real slow workflow.
The programme is for agencies, freelancers, and operators who can reproduce a
slow dynamic WordPress request and act on the evidence with us.