FAQ

WPFlow is a governed WordPress development subscription for one supported site. You describe the change you want in plain language, WPFlow scopes it clearly, estimates the credits before build work starts, and completes the approved work on staging so you can review it safely.

Once you are happy with the staging preview, the work can be published through the Live Release Centre with your approval. The aim is simple: give you a clearer, safer, and more predictable way to keep an important WordPress site moving without waiting in a vague developer or agency queue.

No. AI helps power WPFlow, but the product is the governed workflow around it: clear scoping, upfront estimates, staging-first implementation, checks before completion, revisions before acceptance, and approval before anything goes live.

That matters because website changes need more than raw code. WPFlow is built to turn plain-language requests into safe, reviewable WordPress work, with the structure you would expect from a strong project manager and an experienced WordPress developer.

For many day-to-day WordPress needs, yes — that is the goal. WPFlow is designed to replace much of the recurring work businesses usually send to freelancers, developers, agency retainers, or support queues.

It is strongest for ongoing improvements on one supported WordPress site: page changes, new sections, landing pages, bug fixes, forms, tracking, template updates, performance improvements, theme work, builder changes, and suitable WooCommerce presentation work.

For larger rebuilds, complex commerce, migrations, or multi-stage work, WPFlow can use Planning Mode or a custom review route so the scope, cost, and release plan stay clear.

One standard WPFlow account covers 1 active supported WordPress site.

That one-site model is deliberate. It keeps the queue, staging environment, approvals, credits, release history, and rollback awareness clear for the site you care about. If you need help across multiple sites or brands, each site should normally have its own subscription or an explicitly agreed custom arrangement.

WPFlow is a strong fit if you have one important WordPress site, regular change demand, and someone on your side who can review staging work and approve releases.

It is especially useful for founder-led or marketing-led teams that want website changes delivered more clearly and safely than a traditional retainer queue. Good-fit examples include marketing sites, custom-theme WordPress sites, Elementor or other builder-led sites, and suitable light-to-moderate WooCommerce sites.

WPFlow is built for a wide range of WordPress sites, but every site still needs to pass supportability checks before standard work begins.

That protects you as well as WPFlow. WordPress sites can vary a lot by hosting, theme, plugins, staging setup, live data, security history, and release risk. WPFlow checks whether your site can be staged, changed, reviewed, and published safely. If a site needs remediation or a custom route first, that should be made clear early.

WPFlow can help with many ordinary WordPress issues where the site is supportable: layout bugs, broken forms, template problems, tracking issues, performance problems, or other defects that can be handled safely on staging.

If a site is hacked, infected, compromised, or in active incident response, it normally needs security remediation before it can enter the standard WPFlow lane. Once the site is safe and supportable, WPFlow can be a strong way to keep improvements moving through a more controlled workflow.

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.

You can ask WPFlow for ongoing WordPress development and improvement work where the site and request fit the support rules.

Common examples include bug fixes, content and layout updates, landing pages, new sections, template changes, navigation updates, form fixes, tracking and analytics work, performance improvements, Core Web Vitals improvements, page-builder updates, theme changes, plugin configuration, and suitable WooCommerce presentation or funnel work.

The best requests describe one clear outcome. If the request is broad or unclear, WPFlow can clarify, split it, or route it into Planning Mode.

The normal request lane is best for one clear outcome that can be scoped, approved, built on staging, checked, and reviewed as one piece of work.

Examples include changing a homepage hero, adding a contact-page section, fixing a layout bug, improving a landing-page section, updating a menu, adjusting a template, fixing a form, improving tracking, or making a bounded performance improvement.

The request does not have to be tiny. It just needs a clear goal, affected area, acceptance criteria, and safe release path.

Some work is better handled through Planning Mode, remediation, or custom review rather than the standard request lane.

That includes large multi-phase projects, full redesigns as one brief, major migrations, multi-site estates, heavy WooCommerce operations, subscriptions-heavy workflows, ERP or fulfilment systems, payment logic, complex checkout changes, customer-data workflows, compromised sites, or work without a safe staging path.

This is not about slowing things down. It is how WPFlow keeps scope, cost, review, and release safety clear when a request needs stronger planning.

Yes. Page-builder sites can fit WPFlow where the site and request pass supportability checks. WPFlow should not be described as limited to one builder or one theme type.

Builder work can involve content, templates, styles, and settings that live in different parts of WordPress, so WPFlow handles it through a staging-first workflow. You get a preview to review before anything is considered for live release.

Yes, suitable WooCommerce sites can fit WPFlow, especially for presentation, catalogue, merchandising, product and archive templates, landing pages, checkout presentation, promotional pages, and conversion improvements.

WooCommerce sites are treated carefully because they usually contain live operational data such as orders, customers, payments, carts, sessions, stock, and subscriptions. WPFlow uses the right publish approach to protect that data while still allowing approved presentation and code changes to move forward safely.

Deep commerce operations, ERP, fulfilment, complex payment logic, or subscriptions-heavy workflows may need extra review or a custom route.

Yes. WPFlow can work with both custom themes and purchased themes, using the right pathway for each.

For a true custom WordPress theme, WPFlow can often work directly in the governed theme code. For a purchased, marketplace, or vendor-updated theme, WPFlow should protect long-term changes through a child theme where needed, so customisations are safer across future theme updates.

That theme pathway is checked during onboarding and supportability review.

WPFlow can help with larger redesigns and build work, but they should normally go through Planning Mode or a custom route rather than being treated as one simple request.

A rebuild usually has multiple phases, design decisions, content dependencies, review points, and release risks. Planning Mode turns that into a clearer plan with sprints, costs, assumptions, and approval points before build work begins.

Design references, screenshots, files, and Figma links can be used as helpful context, but WPFlow should not promise strict pixel-perfect matching as a standard public guarantee.

Yes, you can describe several changes together. WPFlow will then decide whether they belong together or should be split.

Related small edits can often stay in one request when they serve the same outcome. For example, updating one homepage section's copy, spacing, and button text may be one request. Several unrelated changes across different pages, systems, or business goals should be split or moved into Planning Mode.

Splitting work keeps the estimate, approval cap, staging review, and release record clear.

WPFlow is designed for plain-language requests, so you do not need to write a technical brief. If the request is missing important detail, Architect will clarify it before build work starts.

Useful details include the page or URL, what you want changed, the result you want, screenshots or examples, whether it affects desktop, mobile or both, any deadline, and anything that must not change.

A clear starting request helps WPFlow move faster, but the workflow is built to help you turn rough intent into safe, executable scope.

If a request is too broad for one clean task, WPFlow can split it into smaller approved items or route it into Planning Mode.

Planning Mode is useful when the work has multiple outcomes, design or content dependencies, strategic decisions, larger technical risk, or several stages. It creates a clearer plan with sequential sprints and approval points, so big work does not quietly become vague, open-ended work.

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.

If your site is close to being supportable but needs a fix first, WPFlow should make that clear and route it into remediation.

Remediation might involve access, staging, theme setup, plugin risk, security health, deployment, or rollback readiness. Some issues are simple; others need separate scoping or a custom route.

The aim is to get your site into a safe, reliable working state before normal requests begin, rather than onboarding a site that cannot be supported properly.

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.

WPFlow combines an AI-assisted scoping layer with a governed WordPress build workflow. Architect turns your plain-language request into a clear scope, and the build lane works against the approved brief on staging.

Quality comes from the process, not from trusting raw output. WPFlow scopes before build, works on staging, runs checks based on the risk and surface touched, captures evidence where relevant, and gives you a staging preview before live release is considered.

For normal requests, your review and approval are the key human approval points.

WPFlow uses plans and credits. Every plan follows the same governed model: one supported site, one governed lane, staging-first delivery, scoped requests, and client-approved live release.

Plans mainly change monthly capacity and value per credit. Current examples are Free at £0/month with 50 welcome credits, Core at £20/month with 50 welcome credits and 25 monthly credits, Pro at £79/month with 50 welcome credits and 100 monthly credits, Custom by quote. The Pricing page may show values in your selected currency.

Free, Core, and Pro include 50 welcome credits that expire after 30 days. PAYG credits are £1 each with a 10-credit checkout minimum.

A credit is WPFlow's unit for approved delivery capacity.

Credits are tied to the scoped outcome, risk, validation, and delivery work involved in a request. They are not developer hours, and they are not internal AI or supplier costs.

Before work starts, WPFlow scopes the request and shows an estimated credit cost and approval cap, so you know the commercial boundary before the item enters the queue.

No. Credits are outcome-based delivery units, not hours.

This keeps the conversation focused on what will be delivered and reviewed, rather than how long someone spent on it. Two requests that sound similar can have different credit estimates if one is simple content work and the other touches checkout, accounts, live data, plugin behaviour, or harder-to-prove release surfaces.

One request is one clear outcome that can be scoped, approved, built, checked, and reviewed safely as a single item.

Related micro-edits can stay together when they support the same outcome. A homepage hero copy and spacing update might be one request. A homepage redesign, checkout fix, navigation restructure, and pricing rewrite should be split or planned as a larger piece of work.

That keeps your estimate, approval cap, staging review, and release record clear.

WPFlow estimates credits during the scoping step before build work starts.

Architect looks at the requested outcome, the surfaces involved, complexity, uncertainty, proof needs, site context, and risk. Sensitive areas such as checkout, payments, accounts, customer data, plugins, schema, migrations, security, or live publish risk are handled more carefully.

You see the customer-facing result: a clear scoped outcome, an estimated credit cost, and an approval cap. Internal supplier costs, token costs, and margin are not public pricing details.

An approval cap is the maximum number of credits you have approved for a request unless you later approve a revised scope or revised cap.

When you approve work, credits may be reserved while the item is in progress. Final settlement should stay at or below the approved cap unless you approve a change. Automatic top-up, where enabled, can add capacity within your budget, but it does not approve work, publish live, change your plan, or override role permissions.

Every plan includes the same governed WPFlow operating model: one supported site, one execution lane, Architect scoping, upfront estimates, staging-first build, checks and evidence where relevant, staging review, revisions before acceptance, and client-approved live release.

Higher plans increase monthly credit capacity and value per credit, but they do not remove the safety and approval discipline. That consistency is part of the product promise.

All plans use the same governed workflow. The main differences are monthly included credits, value per credit, and whether the plan is self-serve or custom.

Current examples are Free at £0/month with 50 welcome credits, Core at £20/month with 50 welcome credits and 25 monthly credits, Pro at £79/month with 50 welcome credits and 100 monthly credits, Custom by quote.

Free is best for starting without a card or occasional pay-as-you-go use. Core and Pro are designed for regular one-site WordPress change demand. Custom is for multi-site, agency, SLA, SSO, invoicing, or other needs that should not be forced into self-serve tiers.

PAYG credit purchases add extra credits when you need capacity without starting a subscription.

New paid credits are quantity-based whole-credit purchases with a 10-credit checkout minimum: £1 per credit. The same PAYG unit price applies whether you are on Free, Core, or Pro.

Manual purchases and automatic top-up both buy whole PAYG credits. Automatic top-up starts from the 10-credit top-up minimum and can only spend within the monthly budget you set; it does not approve work, publish live, change your plan, or create surprise overage.

If there are not enough available credits, approval for new paid work may pause until you add capacity or wait for more credits to become available.

You can add capacity by buying PAYG credits, moving to a monthly bundle, upgrading where appropriate, or waiting for your next monthly credits if you are already on Core or Pro. The app should show the exact blocker, such as low credits, role permissions, payment action needed, or a request that is not ready for approval yet.

Free, Core, and Pro include a one-time 50-credit welcome grant after email verification. Welcome credits expire after 30 days and are separate from paid PAYG or subscription credits.

Free starts without a card. Core and Pro add monthly credits after Stripe confirms the paid subscription.

All self-serve plans use the same one-site, staging-first workflow with approval before live release.

Free remains Free until you explicitly buy PAYG credits, start Core or Pro, or agree a Custom arrangement.

Core and Pro monthly credits are granted after the paid invoice succeeds. If payment needs action, the app should surface the recovery path before credits are granted.

Yes. WPFlow is positioned with no long-term commitment.

Free customers can stay on Free, buy PAYG credits, or choose Core, Pro, or Custom. Core and Pro customers can cancel from the billing area. For the V4 launch model, plan changes are handled through the checkout or support route shown in Billing and billing currency stays locked at signup.

WPFlow does not automatically upgrade you without consent.

The first paid monthly subscription has a 14-day satisfaction guarantee where the offer is shown at checkout or on the Pricing page.

PAYG credits are prepaid usage funding and do not carry the monthly subscription guarantee. If you are unhappy with work, raise it in the thread or through support so WPFlow can review it, fix the issue, revise the staging output, or re-credit affected credits where appropriate.

Free and Core do not include an operator recovery entitlement. That does not remove delivery safety recovery for current staged work where WPFlow has a safe prepared recovery path.

Pro includes same-day operator recovery during UK business hours for supported in-scope platform delivery failures. Same-day means an operator recovery response within the same UK business day when the operator paging trigger fires by 14:00 UK time. Triggers after 14:00 receive next-business-day response unless handled earlier.

Custom / Enterprise agreements can include premium support with a 2-hour SLA during UK business hours where that is included in the custom agreement.

Operator recovery still follows the same scoped, staging-first process, so you review staging and approve anything before it goes live. It does not turn WPFlow into unlimited or out-of-scope work: unsupported site states, unsafe production changes, new scope, payment-truth blockers, or impossible requests still need re-scoping or a custom route.

WPFlow is designed to move faster than traditional developer or agency queues because request intake, scoping, execution, staging review, and release all sit in one governed system.

Smaller approved changes can move quickly. Larger, riskier, or more sensitive work takes longer because it needs better context, stronger checks, and sometimes Planning Mode. The aim is not reckless speed; it is faster, clearer delivery without skipping the safeguards that protect your site.

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.

Complete on staging means you have reviewed the staging result and accepted it against the approved request.

It does not mean the live site has changed. It means the work is ready to be considered for a governed live release. If the staging preview is not right, ask for a revision before marking it complete.

Open the staging preview, compare the result with the approved scope, and review the notes or evidence provided for the request.

If something is not right, ask for a revision in the thread. If you are happy, mark the work complete on staging. Reviewed staging work can then be published from the Live Release Centre through the governed live-release path.

Before publishing, make sure the right work is included, blockers are clear, the timing is suitable, and the approver has the right role.

Ask for a revision before accepting the staging preview.

WPFlow treats corrections to the approved scope differently from new scope. If the work does not meet the agreed acceptance criteria or introduces a direct regression, that should be reviewed as a correction. If you want extra features, additional pages, new variants, or a changed requirement, WPFlow may need to scope it as a new or revised request with a new estimate and approval cap.

Live release happens from the Live Release Centre after work has been reviewed and completed on staging.

WPFlow prepares a governed site-level release, checks the staging basis, looks for release blockers, applies the right publish mode, and records the release status and evidence. This is intentionally different from casual live editing. You can review what is ready, approve the release, and monitor the publish flow from one place.

Full Sync and Theme Sync are WPFlow's two governed publish modes.

Full Sync is used for suitable marketing, brochure, lead-generation, and non-live-data sites. Staging is the authority for approved site presentation, content, and configuration changes. Protected live operational data is not blindly overwritten.

Theme Sync is used for live-data sites, especially suitable WooCommerce sites. Live operational data stays authoritative. WPFlow publishes approved code and selected governed content/configuration changes only when they are scoped, verified, and rollback-covered.

In both modes, publishing is governed. Neither mode is a casual raw database overwrite button.

WPFlow is rollback-aware and prepares release records with recovery in mind.

Many changes can be reviewed and recovered more safely than ad hoc live edits because work is staged, scoped, recorded, and released through a governed process. Exact rollback support depends on the surfaces changed, site state, publish mode, hosting, data involved, and prepared rollback path.

Where rollback coverage is not suitable for a particular change, WPFlow should make that clear or route the work through a safer review path.