AApproval gate
Stage 1
Choose the direction
Compare real navigation + hero directions, approve one, and freeze the visual rules before WordPress conversion.
Methodology
We separate what looks good, what runs, what was tested, and what is ready to sell.
WPbyAI uses explicit approval gates, versioned work, stated environments, and evidence-backed product language. A successful deployment is not automatically a verified WordPress delivery; an internal experiment is not automatically a customer feature.
Review checklist updated 5 October 2026 · A checklist is not a claim that every capability is available.
BVersioned work
Stage 2
Build and edit safely
Turn the approved specification into editable WordPress work, with versioned previews instead of production guesswork.
CEvidence pack
Stage 3
Verify the real stack
Run the agreed flows in a locked WordPress, PHP, database, theme, and plugin combination before source handoff.
Production boundary
The current public workflow ends at C-verified source handoff.
Customers can deploy the delivery package themselves or with their existing host. Assisted production launch and Managed Care remain deferred services. They require a separate scope, backups, rollback, least-privilege access, and real recovery evidence before they can be offered publicly.
Public status contract
One word should tell you how much evidence sits behind the claim.
Ready
A capability that has passed its current customer-facing production gate.
Pilot
Available only to a limited, manually reviewed group with a narrower promise.
Testing
Implemented or evaluated internally, but not yet a customer-facing promise.
Planned
A candidate direction. It must not be described as available.
Search Foundation
Included in formal builds, without a ranking promise.
Information architecture, canonical URLs, robots, sitemap, schema, internal links, accessible text, responsive output, and actual HTTP responses are checked as delivery foundations. Rankings, traffic, leads, AI citations, and third-party index timing remain outside any guarantee.
Evidence hierarchy
Our production data outranks a market estimate.
Customer-approved versions, browser results, product events, support minutes, cost, conversion, and retention are the highest internal evidence. Official documentation and direct platform data follow. Independent cases can shape tests; forum anecdotes only generate hypotheses.
What to ask for before accepting a website
Use this checklist to agree the evidence for your project. It is a review template, not a completed customer report or a promise that an untested feature is supported. A missing result stays unverified.
- Approved scope
- List the pages, intended visitors, primary action, and exact version being reviewed. Keep later requests separate from the accepted scope.
- Visitor checks
- Name the desktop and phone views tested, the navigation paths used, and what actually happened when a form or other agreed flow was tried.
- Search settings
- Record the intended public domain, page titles, canonical URLs, indexing settings, and sitemap. A protected preview and a public production site need different indexing decisions.
- Ownership and access
- Confirm what you can edit and export, who controls the domain and hosting, and which third-party assets require your own license.
- Known limitations
- Name untested integrations and remaining issues. A form saving an enquiry does not by itself prove email delivery; a backup file does not prove a successful restore.
- Launch responsibility
- Identify who will deploy, check production, handle updates, and respond to problems. Do not infer ongoing hosting or Managed Care from a source handoff.
Comparing tools? Use the builder review worksheet. For the current offers and exclusions, check pricing before describing your project through the WordPress builder route.
Limited private pilot
Bring us the brief, the source, or the authorized URL.
We will classify the project, confirm the safe next step, and only accept work that fits the current private pilot.