Connect Your Site In Minutes.

Often, yes. WPFlow is designed to work with your existing WordPress setup where the site fits the support rules.

During onboarding, WPFlow checks the practical details: access, staging, hosting constraints, theme approach, plugin risk, publish mode, and the type of work you are likely to request. WPFlow is not limited to one theme or one page builder, but the site needs a safe staging and release path before normal work begins.

Usually no. WPFlow is designed to work with your current WordPress setup where the site is supportable, so moving hosting or DNS is not the default requirement.

What WPFlow does need is a safe way to connect to the site, prepare or use staging, review changes, and publish approved work. If hosting, DNS, or staging changes are genuinely needed for your site, they should be surfaced as clear onboarding facts rather than hidden surprises.

Start by choosing Free, Core, Pro, or Custom, completing the required confirmations, and connecting your WordPress site.

WPFlow then prepares or validates staging and runs supportability checks. Once the account reaches the ready state, you can start sending normal requests through the workspace.

Free starts without a card. You only add payment details when you buy PAYG credits, start Core or Pro, or agree a Custom arrangement.

WPFlow needs confirmation that you are authorised to request and approve work for the site, payment authority, a guided WordPress connection, and permission to prepare or use staging.

Depending on the site, WPFlow may also need details such as the production URL, WordPress admin URL, staging information, key pages or journeys, the main technical contact, theme details, plugin context, hosting constraints, and the person who can approve live releases.

Do not paste passwords, API keys, payment secrets, private keys, or database credentials into chat or ordinary messages. Use the approved secure connection or support route.

You do not necessarily need to have staging ready before you start. WPFlow can create, adopt, or normalise staging where the hosting setup and permissions allow it.

A viable staging path is required for standard work. Staging is where WPFlow prepares and checks changes before your live site is touched, so it is central to the safety of the service.

Supportability checks confirm whether WPFlow can work on your site safely and reliably.

They look at practical factors such as site authority, access, staging readiness, hosting constraints, theme approach, plugin risk, publish mode, key user journeys, rollback readiness, security health, and whether the requested work fits the standard model.

The result should be clear: ready for standard work, needing remediation first, or requiring a custom route.

Onboarding is designed to be low-friction for supported sites. Many sites can move through setup quickly once connection details and permissions are complete.

For the broader operational promise, supported sites can be prepared within the stated onboarding target once access, supportability checks, credential verification, staging readiness, and any selected paid-plan payment steps are complete.

The important point is that WPFlow should not ask you to spend credits until the supported site and request path are ready enough for governed work.

A good request explains the outcome you want and where it should happen.

Include the page, URL, template, form, product, or section involved; what should change; what the final result should look or feel like; examples or screenshots if useful; whether it affects desktop, mobile or both; any deadline or business context; and anything that should not change.

Try to keep each request focused on one clear outcome. Architect can help refine it, but better starting detail usually means faster, cleaner scoping.

Yes. WPFlow can use helpful request context such as screenshots, files, page URLs, images, design references, documents, Figma links, fonts, media, and voice input where enabled.

Treat design screenshots and reference files as guidance unless you explicitly want them used as real website assets. Do not upload or paste secrets such as passwords, API keys, private keys, recovery codes, database URLs, payment secrets, or webhook secrets.

If an uploaded asset becomes stale, WPFlow may ask you to re-upload it before relying on it again.

No. WPFlow is staging-first, and live release is a separate governed action.

Work is built and reviewed on staging first. Completing a request on staging does not automatically update the live site. Live publishing happens through the Live Release Centre and requires approval from an authorised role.

The Assistant also cannot publish live, approve work, mark staging complete, or bypass the governed workflow.