§ 01 / For agencies

Build sites that outlive the retainer.

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.

§ 02 / Why agency builds rot

Four pains every roster eventually hits.

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.

  1. 01
    Page-builder lock-in becomes the client's problem.

    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.
  2. 02
    Sites die when the relationship ends.

    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.
  3. 03
    Handoff is theatre when the artifact is opaque.

    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.
  4. 04
    Every build is a snowflake.

    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.
§ 03 / What the client receives

Three artifacts. All owned by the client.

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.

  1. § IN THE CLIENT'S REPO

    A JSON manifest per page.

    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.json
  2. § ON THE CLIENT'S WORDPRESS

    One GPL Gutenberg block.

    The 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/atlas
  3. § ON THEIR DOMAIN

    Plain semantic HTML.

    The 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)
§ 04 / The artifact, on disk

A manifest is a file, not a database row.

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.

content/landings/sydney-dental.atlas.json JSON

  "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.

§ 05 / Four states of handoff

The site renders in every state of the relationship.

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.

  1. § AGENCY ACTIVE

    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.

  2. § AGENCY DORMANT

    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.

  3. § AGENCY GONE

    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.

  4. § PLUGIN DEACTIVATED

    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.

§ 06 / What changes for your build economics

Four ways deterministic builds compound across a roster.

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.

  1. 01

    One library, every roster site.

    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.

  2. 02

    Onboarding is reading code.

    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.

  3. 03

    Fewer "the site looks weird" calls.

    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.

  4. 04

    Audit trail by default.

    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.

§ 07 / What's there and what isn't

Two short paragraphs so nobody is surprised.

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.

§ AVAILABLE TODAY

The GPL plugin, on every site you build.

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.

§ NOT YET

No formal partner program.

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.

§ 08 / Agency questions

Five things agencies ask before they pick a tool.

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.

  1. What does the client actually receive at handoff?

    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.

  2. What happens to the client's site if our agency goes away?

    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.

  3. Can we version client sites the way we version code?

    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.

  4. Does Atlas replace the client's theme?

    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.

  5. Is there a white-label or reseller program?

    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.

§ 09 / Try it on one site

Pick one retainer. Ship one manifest.

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.