Atlas turns every WordPress build into a JSON manifest in the client's own repository plus a GPL plugin they own outright. The deliverable survives plugin churn, agency turnover, and the end of the relationship — without locking the client into a runtime they cannot leave. One artifact, one render path, one set of keys, all owned by the client.
The pain is not in shipping a single site. The pain is in what happens to the thirty sites the agency built two years ago, every time WordPress, PHP, or a builder vendor moves.
A site built in Elementor or Divi outlives the licence renewal. When the plugin lapses, the post_content collapses into bracket strings and the client phones the agency that hasn't worked on the site in two years.
§ The client inherits your runtime debt.A retainer ends, the agency stops touching the site, and within a release cycle a plugin update or PHP bump puts the page out of action. The site's lifespan is coupled to the agency's presence whether the agency wants that responsibility or not.
§ Coupled lifespan, uncoupled invoice.You ship the site. You hand over admin credentials, a Google Doc, and a tour of the page builder. Six months later the client's in-house marketer cannot diff what changed, what shipped, or what the original page looked like.
§ No artifact a developer can read.The dentist site, the law firm site, the accounting practice — all built differently, all carrying their own hero, their own pricing table, their own grid. A bug is a per-site fix. Onboarding a new junior is a per-site tour.
§ Reuse stops at the screenshot.Atlas decouples the deliverable from the agency relationship by making each part of it portable, owned, and readable on its own. Nothing on the list requires the agency’s keys to keep working.
Authored once, compiled to a deterministic tree of section, heading, prose, and media nodes. The manifest is a flat file the client can version, diff, and migrate without your help. It is not a database export.
/content/landings/*.atlas.jsonThe plugin is GPL-2.0+. The client owns the licence the moment it is installed. They can fork it, audit it, vendor it, or pin a version forever. Nothing about the page rendering depends on a paid relationship continuing.
wp-content/plugins/atlasThe render is server-side. View source on a live page returns the same markup the manifest declared, with no hydration runtime and no editor scaffolding. What the crawler sees is what the visitor sees is what the manifest said.
response body (server)Each page lives as a deterministic JSON tree, version-controlled inside the client's repository alongside their theme. A new developer reads the file, edits it, commits it, and ships — without an account on a third-party editor.
"version": 1,
"slug": "landings/sydney-dental",
"sections": [
"type": "Hero",
"editable": ["heading", "subhead", "cta.label"],
"props":
"heading": "Gentle dentistry in Surry Hills.",
"subhead": "Same-week appointments. No upsell.",
"cta": "label": "Book online", "href": "/book"
,
"type": "FeatureGrid",
"editable": ["items[].title", "items[].body"],
"props": /* three feature cards */
]
§ Editable zones are declared in the file. The client's marketer changes copy; the agency owns the shape. Both ship from the same source of truth.
Active engagement, dormant retainer, ended retainer, and plugin deactivated entirely. In each state the page either renders the manifest, renders the last manifest, or degrades to plain HTML. There is no state in which the visitor sees a wall of bracket strings.
You compile, you commit, you push.
The manifest tree lives in the repo you already use. Pull requests review like code. Junior staff edit copy inside marked editable zones; layout is pinned by the component author.
The site keeps rendering.
No edits this quarter, no updates this quarter, no problem. The plugin renders the last manifest the client received. There is no licence countdown ticking in the admin bar.
The client owns every artifact.
Manifests in their repo. Plugin under their control. Theme untouched. The new agency reads the manifests as JSON, edits them, and ships. There is nothing for them to migrate off, because there is nothing proprietary holding the page together.
The post_content stays valid.
The block is one inert HTML comment. WordPress treats it as a comment when the plugin is gone — the page does not collapse into bracket strings or white-screen. Re-activate later and rendering resumes from the same manifest.
Per-site work caps your team. Reusable components, typed props, and version-controlled manifests turn the work into something that scales sub-linearly with the number of sites on the roster.
The hero you wrote for the dentist is a typed component the law firm and the accountant inherit. A bug is a one-place fix that compiles into every manifest on the next build.
A new junior reads typed component props and a JSON tree, not three years of bespoke ACF field naming. The first useful pull request lands in days, not weeks.
No editor runtime ships to visitors. No PageSpeed call about a 52 score. No client text wrapping breaking because a plugin update rearranged its own markup.
Every layout change is a commit. When the client asks who changed the headline and when, the answer is in the log. No screenshot comparisons, no memory work.
Agency-side scaffolding either ships or it doesn't; we'd rather say what's missing than sell a portal that hasn't been built. Today the offer is the GPL plugin and the manifest format. Everything else lives on a dated roadmap.
Install Atlas on as many client sites as you like. The plugin is free, the licence is permissive, and the manifest format is documented. No registration, no agency tier paywall to start, no per-site activation key.
There is no white-label portal, no co-branded editor, no reseller margin sheet to reproduce here. When those exist they will be on the pricing page in plain language. Until then, build with the GPL plugin and tell us what you need; the roadmap is being shaped by the agencies actually shipping.
The questions we get from principals, ops leads, and inherited-site rescuers — answered in the language they actually use, not the marketing language we'd otherwise default to.
A folder of JSON manifests in the same git repo that holds their theme, plus the GPL Atlas plugin installed on their WordPress. No proprietary export, no editor account they need to keep paying for. A developer reads the manifests; a marketer edits inside the marked zones.
Nothing. The plugin is GPL and already sitting in their wp-content. The manifests are in their repo. The render is deterministic from those two inputs. A new agency, an in-house developer, or no one at all can keep the lights on without paying us anything.
That is the design. Manifests are JSON files in the client's repository. Branch, tag, diff, and revert work the same way they work on any other source file. Layout changes show up in pull requests as readable diffs, not as a screenshot delta.
No. Atlas registers one Gutenberg block. Headers, footers, archive pages, the menu, the WooCommerce templates — everything else stays under the theme that was already there. The block sits inside post_content next to anything else WordPress already does.
Not at the moment. The plugin is GPL, so you can install it on every client site without asking permission, but a co-branded editor or formal reseller margin sheet does not exist yet. When it does it will be on the pricing page; until then we would rather under-promise than ship a feature that does not survive contact with the first agency that uses it.
Install the GPL plugin on a site you already maintain. Author one section as a manifest. Watch the post_content render server-side and survive a plugin deactivate. If it changes how you think about the rest of the roster, the rest of the roster is waiting.
One artifact. The client's keys.