Site builders make one of two mistakes. They hand you a blank canvas and call it freedom, or they generate a finished page you never agreed to and call it magic.
Boord Sites does neither. It answers a brief with a plan, builds only after you approve, produces real files you can edit, and treats going public as a decision only a human can make.
We need a launch site for the Northstar field portal. Audience is operations managers. Calm, credible, one clear signup path.
Here is the plan before I build anything: five sections, three files, copy sourced from the June positioning notes. Change anything, then approve.
- Site plan: sections, files, copy sources Waiting for your approval
Swap the testimonial section for a rollout timeline, then approved.
Built. The preview link is live for the team. Publishing stays locked until you say otherwise.
- Built northstar-field-co: index.html, styles, assets Done
- Preview ready for team review Done
- Publish to the public web Waiting for your approval
Illustrative exchange with a synthetic company. Publishing requires an explicit approval.
Why the plan comes first
The cheapest moment to change a site is before it exists. Boord always answers a site brief with a plan: the sections, the files it will create, where the copy will come from, and what it needs from you.
The loop, end to end
- Brief
You describe the site
Audience, promise, sections, launch moment. Company facts come from Brain, so the brief stays short.
- Plan
You approve the plan
Sections, files, and copy sources, stated upfront. Edit the plan in chat until it is right.
Human decides - Build
Real files take shape
Vinci directs the experience, Sumer writes the sections, Sui assembles and checks the files.
Vinci Sumer Sui - Publish
Going public is a decision
The preview iterates freely. The public web requires your explicit yes, enforced by the platform.
Human decides
Two gates: one before the build, one before the world. Everything between them is fast iteration.
What the draft actually is
The build output is a real site, not an export you fight later.
| Artifact | What it is | Why it matters |
|---|---|---|
index.html and section files | Plain, readable markup | Any developer or Member can edit it |
css/styles.css | One honest stylesheet | The design survives outside the builder |
| Assets | Images and files on disk | Versioned with the site, not linked from nowhere |
| Preview URL | The draft, viewable by the team | Review happens on the real thing |
Because the files live on disk and under versioning, “ask Boord to change the hero” and “edit the file yourself” are the same workflow. Nothing is trapped.
After the launch
The site is one artifact in a larger launch: the checklist, the dashboard signals, and the customer follow-up can come from the same brief. The launch planning use case shows that wider fan-out; this page is the site lane of it.
And the site keeps paying into memory: the sections, claims, and structure land in Brain, so the next page starts from what the last one learned.
Use-case FAQ
Is this example based on customer data?
No. The walkthrough uses a synthetic company, Northstar Field Co. The workflow is the real product flow: plan, approve, build, preview, gated publish.
Can Boord publish the site automatically?
No. Drafts and previews are free to iterate, but making a site public requires an explicit human approval. The gate is enforced by the platform, not by politeness.
What if I want to change something in the draft?
Ask in chat, or edit the files directly. The draft is normal HTML and CSS on disk, versioned, so your edits and Boord's edits coexist and nothing is trapped in a builder.
Where do the words and design come from?
From your company memory: the audience, promises, and product facts recorded in Brain. Sumer writes against those facts, and Vinci works from your visual direction, so the draft sounds and looks like you.