For developers
You can open all of it.
The rest of this site is written for the person who owns the site. This page is the technical detail: what is served, what you can edit by hand, and how the finished site behaves.
Visible stylesheets
Static output
Source served directly
What you can edit by hand
Direct control outside the page body.
You direct page content through the AI. Syntax-highlighted editors cover site-wide CSS and JavaScript, plus each page’s metadata and head.
CSS and JavaScript
The site stylesheet and site script apply to every page. Your JavaScript runs unsandboxed on your site, and the source is served without minification.
The head, and JSON-LD
Write into <head> directly. Structured data is stored as bare JSON at both site and page level. We own the <script type="application/ld+json"> wrapper, which is what lets the content be validated on write and escaped on output.
Per-page CSS, JS and head
Each page carries its own, appended after the site’s. Order on a served page is: generated meta, site head, page head, site JSON-LD, page JSON-LD, analytics last, so analytics can never displace a meta tag.
Addresses and metadata
Slug, parent, title, meta title, meta description, excerpt, per-page robots directives, canonical behaviour and the 404 target are all ordinary fields, not AI-only.
The cascade
The cascade has four visible layers.
Custom properties
Every design value in a global, emitted as --mb- plus its path. No hidden second namespace: the theme global’s primary colour is var(--mb-theme-colors-primary).
Site CSS
Yours. Seeded with a small reset and two rules wiring the theme’s fonts to body and headings. Delete any of it.
Block CSS
The CSS of any reusable block the page embeds, in embed order.
Page CSS
The page’s own, last, so a page can always override the site.
These four layers contain every style rule. You can open, read and delete the rule responsible for any visible result.
Serving
What a request actually touches.
Edge → object storage
The overwhelming majority of requests. The finished HTML is read straight from storage by the edge proxy and returned compressed. No function is invoked and no database is read. Measured at ~180ms and 0 renderer invocations.
Core routes warmed during Publish
Publishing renders the homepage and robots.txt, sitemap.xml, llms.txt and feed.xml into the cache before it finishes, so the address everyone starts at, and the files a crawler or a feed reader reads first, are never left to a visitor to build. Every other page is built once by its first visitor and served from the cache to everyone after. It can never fail a publish.
One render, then cached
Any other page, or anything after an eviction, is assembled on its first visit from the release manifest, a single document naming every record the live site is made of, and written back to the cache. Roughly 0.4 seconds, once, for one visitor.
Invalidation follows the release diff
Publishing compares the new release with the old. A site-wide change purges the whole host; otherwise only affected pages are purged. The fallback favours a wider purge to prevent stale HTML.
Images
Derivatives are generated on demand and cached. Markup is a <picture> with
AVIF and WebP sources plus a WebP <img> fallback,
both branches carrying a srcset. The candidate list is computed server-side and contains only
widths at or below the file’s natural width. The resizer never enlarges, so an oversized
candidate would make the browser pick the largest and receive the smallest.
Addresses
Pages nest to any depth and the nesting is the path, so a stored URL cannot drift out of step with the tree. The homepage lends no segment, so its children sit one level up. A collection’s items are flat and sit under the collection’s own slug, and changing that slug moves all of them at once. Every address change (rename, reparent, delete-with-promotion, homepage handover, a collection’s new slug) emits a 301, and those redirects ship in the same release as the change that caused them.
The product model
A conversational editor, with direct control around it.
The page body and the surrounding code have different editing paths, each suited to the person changing it.
AI writes page bodies
Direct it in conversation, review the changes and publish. You can edit site CSS and JavaScript, head content, metadata and addresses by hand.
Source goes straight to the browser
HTML, CSS and JavaScript are served directly, with no bundler, framework runtime or platform stylesheet between what you write and what the visitor receives.
Technical questions
What is actually served?
Static HTML. Publishing assembles each page and writes it to object storage; an edge server hands that file to visitors, compressed, with no origin request. A cached page costs zero function invocations and measures around 180ms. Publishing itself renders the homepage, the top-level pages and the machine endpoints straight into the cache, so on most sites nobody is the first visitor. Anything deeper is built on its first visit, taking about 0.4 seconds, once, and served from storage after that.
What runs on the page?
Pages include only code you or the AI put there. Framework runtimes, jQuery and analytics are omitted unless you add them. A page without JavaScript is served without JavaScript.
Is there a base stylesheet?
No. The cascade contains the site’s CSS custom properties, the site stylesheet, reusable blocks and the page’s own CSS, in that order. A new site starts with a small reset at the top of its site stylesheet, which you can delete to use raw browser defaults.
Can I use a build step, npm, or a framework?
MightyBuilder serves what you write directly, without a bundler or package installation. That keeps the source and the browser output the same: ordinary HTML, CSS and JavaScript with no generated layer in between.
How does concurrent editing behave?
Writes are handled per setting. Two writers changing different settings can both succeed, while a write that would overwrite a newer change is refused with a conflict. The AI writes through the same path you do.