The Build Workflow
The three phases every build moves through: Setup, Design, then Build, all in plain English.
You never invoke commands or pick a procedure by name. You talk in plain English, and the orchestrator inside your WordPress site reads what you asked for and picks the right play. Every build moves through the same three phases: Setup, then Design, then Build.
At the start of every session your AI loads context first: what your site can do, the current design state, your Project Memory, and your existing widget inventory. Then it routes the work. You do not manage any of that. You describe the outcome you want, and the orchestrator handles the rest.
- 1
Setup
A one-time onboarding wizard. You activate your license, connect an AI client, pick your base builder, and choose how to set up your design system. This runs once on first install.
- 2
Design
Your design system has to be ready before any page can be built. You kick it off in plain English: import from Figma, describe it, or scan an existing site. Tokens become the single source of truth for the whole site.
- 3
Build
You describe the page or site you want and your AI builds it widget-first, section by section, every value bound to your tokens, every page verified after it renders.
Setup: the onboarding wizard
The wizard auto-opens the first time you activate BuildPress. It walks you through four things, in order:
- Activate your license. Enter your key so the AI build tools are live.
- Connect an AI client. This is the same flow as the Connection page: enable MCP access, generate an Application Password, and paste the config into your client.
- Pick your base builder. The BuildPress Builder is the default and needs no other plugin. Elementor is selectable if it is installed and active. Bricks shows as Coming soon and is not selectable yet.
- Choose how to set up your design system. Import from a Figma file, run a short AI design interview, scan an existing site, keep your current kit, or defer it to the AI in a later session.
Only once
Setup is a first-run wizard. You change your base builder later at WordPress Admin, BuildPress, Settings, General, and you can revisit the design system at any time. You do not re-run onboarding for every new build.
Design: get the design system ready first
Your design system has to be ready before any page is built. Every build play checks this. If the design system is not ready, the play stops and routes you to set it up first. This is on purpose: it is what keeps pages on a coherent palette and type scale instead of drifting into generic output.
You kick off the design system with a plain-English ask. For example:
Set up my design system from this Figma file: [URL] Build a design system from a description: a calm SaaS for finance teams, Stripe-like indigo, Inter everywhere. Use my existing site's colors and fonts as the starting point.If you chose to set it up later with the AI during onboarding, your AI offers at the start of a session: it can pull tokens from a Figma file, scan your existing site, or build a system from a short description. Say yes and it runs the interview or the import, then reports back every color and every type style it created before you move on to building pages.
Build: describe it, your AI builds it
Once the design system is ready, you describe what you want and your AI builds it widget-first. Each region of the page (each section, plus the header and footer) either reuses a library widget that genuinely matches or becomes a new BuildPress widget, token-bound, never a hardcoded hex or px. Pages are composed from those widget instances top to bottom.
Here are real prompts you can paste to your AI:
Build me an agency landing page. Create an about page with a hero, mission, team, and a closing CTA. Build a landing page: hero with headline, sub, and a 'Start free trial' button, a 3-up features row, a testimonials strip, and a closing CTA band. Draft placeholder copy. Build a Netflix-style streaming site. Build me a 5-page marketing site for an agency: Home, Services, Work, About, Contact. Reuse my design system.Two ways your AI routes a build
The orchestrator reads the size and shape of your ask and routes it one of two ways. You do not choose the route. You just notice the difference in what happens next.
- A big or system-level ask (multiple pages, multiple post types, or an X-style-Y request) gets a planning step first. Your AI produces a content model (which screens are pages versus custom post types versus taxonomies) and a widget breakdown, then waits for your sign-off before it writes a single thing.
- A vague ask (something like "build me a website" with no detail) triggers a short scope interview. Your AI asks a few questions, synthesizes a brief, and confirms it with you before building.
Drafts, not surprises
Pages are created as drafts and only published when you say so. Nothing goes live until you confirm, and every build ends with a verification report plus edit and preview links.
The quality floor that never turns off
Every build is held to a Design baseline that you cannot turn off. It is the reason pages look designed instead of generic. The baseline covers:
- Clear visual hierarchy, with one focal point per section so the eye knows where to go.
- Spacing rhythm on a coherent rem scale, so gaps feel intentional rather than random.
- Type restraint and deliberate pairing, restraint over decoration.
- Everything token-bound. Colors and typography bind to your kit globals, never raw values.
- Rem-based type, never px, with a real display tier sitting above H1.
- Bold statement sections. The hero and the closing CTA get dramatic type so the page opens and closes with intent.
Because every value is token-bound, one edit to your design system re-themes everything at once. Improving a widget updates every place it appears. To go deeper on either side of this, read Widget-first builds and the Design system guide.