Write the content contract before you choose Edge Delivery

Most teams open an Edge Delivery Services discussion with performance.

That is not wrong. Adobe positions Edge Delivery as a performance-first delivery model, with plain front-end code in GitHub and authoring surfaces that publish without a heavy rebuild cycle. If you are already living with slow marketing pages, bloated component libraries, and a publish path that feels like a release train, speed is a real reason to look.

But speed is not the decision that usually fails.

The decision that fails is quieter: who is allowed to change what, in which tool, under which rules, before that change becomes a page on the edge.

We call that the content contract. If you do not write it early, Edge Delivery becomes a new delivery layer on top of the same ownership mess that made the old site hard to run.

The pages can float. The thread cannot. Ownership is the thread.

What Edge Delivery actually changes

Adobe’s documentation is clear on the architectural shift: Edge Delivery Services is a composable set of services inside Experience Manager. It is not “a CDN.” It can sit with your own CDN or Adobe’s managed CDN. What it replaces, for the pages that use it, is the traditional AEM publish/dispatcher path and the heavier front-end model built around classic Sites components.

In practice that means three things for a program:

1. Code lives in GitHub. Site behavior is mostly HTML, CSS, and vanilla JavaScript. Adobe’s developer guidance leans hard on this simplicity: modern CSS and JS without a mandatory framework stack for the marketing head.
2. Content can enter from more than one surface. Document-based authoring (Word/SharePoint or Google Docs) and AEM authoring with the Universal Editor are both supported paths into Edge Delivery.
3. Pages are assembled from blocks. Blocks are the unit authors compose and developers implement. That is a different mental model than “one HTL component for every design variance.”

None of that automatically makes your site maintainable. It makes the boundary between content and code sharper. Sharp boundaries are useful only when both sides know their job.

The two authoring paths are not a preference poll

Adobe documents two primary authoring options for Edge Delivery. Teams often treat the choice like a taste vote. It is closer to an operating model vote.

Document-based authoring

Document-based authoring is for teams that already live in Word, SharePoint, or Google Docs. Adobe’s pitch is velocity without training: publish from documents the organization already knows how to write.

That path works when:

• Page types are mostly editorial: campaigns, articles, simple product stories, regional marketing pages.
• The authoring population is large and distributed.
• Governance is lighter: fewer legal workflows, fewer multi-brand launch gates, fewer shared content fragments across a complex site tree.
• You can accept that structure comes from document conventions and block tables, not from a full AEM content tree with decades of Sites habits.

It breaks when people try to recreate a full component-driven design system inside Word tables without a block inventory. Then every page becomes a one-off layout document, and developers spend their week decoding author improvisation.

AEM authoring with the Universal Editor

Universal Editor authoring keeps content in AEM as a Cloud Service and edits it in a WYSIWYG surface. Adobe’s docs emphasize what you keep here: workflow, governance, multi-site management, launches, and the broader AEM content management set.

That path works when:

• You already depend on AEM for localization, launches, approvals, or multi-site control.
• Authors need in-context preview with real block composition, not a document approximation.
• Content is shared, reused, and governed across brands or regions.
• Legal and brand review is part of the publish path, not an email after the fact.

It is the wrong default when the organization only needs a fast marketing surface and is not ready to operate AEM authoring seriously. Buying the heavier path “just in case” recreates the cost Edge Delivery was meant to reduce.

Rule of thumb we use in discovery: pick the authoring surface by who owns the final text and layout decisions on a weekly basis, not by which demo looked cleaner in a vendor walkthrough.

Blocks are the real product surface

In Edge Delivery, blocks are not a decorative rename of classic AEM components. They are the contract objects:

• Authors choose and arrange them.
• Developers implement their decoration, styles, and behavior in the GitHub project.
• Performance budgets live or die by how many blocks load eagerly and how much JavaScript each one brings.

A weak block inventory shows up the same way every time:

• Ten variants of “hero” because nobody named the intent.
• Authors invent layout by nesting tables until the page works once.
• Developers ship page-specific CSS that only that URL understands.
• New campaign pages take as long as the old Sites components did, only now the backlog is in GitHub issues instead of CRX packages.

A strong inventory is boring on purpose:

• Named by job, not by visual: hero, stats, card-grid, quote, form, embed.
• Documented with allowed fields and examples.
• Owned by someone who can say no to a one-off.
• Measured against a page weight budget, not only against Figma.

If you are early in an Edge Delivery program, write the block inventory before you redesign the homepage. The homepage will change. The inventory becomes the long-term product.

Coexistence is normal. Parallel ownership is not.

Adobe is explicit that Edge Delivery Services and AEM Sites can co-exist on the same domain. Larger sites often keep some pages on the current stack and move the high-velocity or high-traffic surfaces first.

That is a healthy migration pattern. The failure mode is different:

• Marketing owns “the new Edge section.”
• IT owns “the old Sites tree.”
• Brand has two design systems.
• Analytics is stitched after launch.
• Nobody owns the URL map when a campaign needs both worlds.

Coexistence needs a written boundary:

Without that table, “we can co-exist” becomes two websites wearing one hostname.

Same room. Different density. The line is the ownership decision.

When Edge Delivery is the wrong first move

Adobe recommends Edge Delivery as a strong starting point for many new projects. That recommendation is useful. It is not a substitute for program fit.

We push back when:

• The real product is a custom application shell. If the experience is a React SPA with authenticated workflows, Adobe’s own guidance points toward AEM headless patterns for that head, and using Edge more carefully for the marketing surfaces around it.
• Nobody will maintain GitHub. Edge Delivery’s developer model assumes someone can own front-end quality in a repo. If the only capacity is classic AEM backend capacity, you have not removed complexity — you have relocated it.
• The organization needs heavy launch/governance day one and expects document authoring to magically provide it. Document velocity and enterprise launch control are different jobs. Universal Editor + AEM authoring is usually the honest path.
• The brief is only “make Lighthouse green.” Green scores on a thin pilot page are easy. Operational ownership across 400 URLs is the actual work.

The content contract we write before architecture slides

In early discovery we refuse to start with a stack diagram. We start with a one-page contract the business can argue with.

1. Author roster

Who creates pages weekly? Who reviews? Who can publish? If the answer is “everyone with a SharePoint license,” document-based authoring may fit. If the answer is “a small digital team inside AEM with legal gates,” plan for AEM authoring discipline.

2. Page families

List five to twelve page families, not fifty wireframes. For each family: purpose, required fields, allowed blocks, and whether personalization or experimentation is in scope.

3. Block ownership

For each block: author-facing name, required content, performance class (eager / lazy), and a named developer owner. Unowned blocks rot.

4. Publish definition of done

What must be true before a page is live: metadata, accessibility check, legal line, tracking, preview sign-off. Edge Delivery can make publishing faster. It does not invent quality gates for you.

5. Migration slice

If this is not a greenfield site, pick the first URL set that benefits from velocity or performance without depending on the hardest enterprise integrations. Adobe’s guidance supports moving a subset of pages first. Use that. Do not “Edge everything” as a slogan.

6. Measurement that is not vanity

Operational telemetry and Core Web Vitals matter. So do author time-to-publish, block reuse rate, and how often a page needs a developer for a content change. If the last number stays high, the contract failed even if Lighthouse looks fine.

A practical decision sequence

Use this order in the first two workshops. Do not reverse it.

1. Map page families and owners.
2. Choose the primary authoring surface for the first year, not for an imaginary five-year platform purity.
3. Draft the block inventory and performance budget.
4. Decide coexistence boundaries if a classic Sites estate remains.
5. Only then lock delivery architecture, repo layout, and integration points (forms, search, commerce, Target, analytics).

Teams that reverse the order end up with a beautiful pilot and an unmaintainable second quarter.

What good looks like after six months

You are in a healthy Edge Delivery program when:

• Authors can launch a standard campaign page without a developer ticket.
• Developers spend more time improving shared blocks than patching page-specific CSS.
• New page requests get answered with “use these three blocks,” not “we will build a component.”
• Classic Sites and Edge pages can share a domain without two political owners.
• Performance work is continuous instrumentation, not a pre-launch panic.

You are not there yet if every new request invents a layout, if publish still waits on a release calendar for copy changes, or if nobody can explain which authoring path is canonical.

Closing

Edge Delivery Services is a strong option when you want AEM-class content programs with a faster front-end operating model. Adobe’s documentation gives you the pieces: dual authoring paths, GitHub-based development, block composition, domain coexistence, and a performance-first delivery posture.

The part the docs cannot write for you is the human boundary.

Write who authors, what blocks mean, and where ownership ends — then choose Edge Delivery as the delivery system for that contract.

If you reverse those steps, you do not get a modern AEM program. You get a faster pipeline into the same confusion.

Planning an AEM or Edge Delivery program? Start a project inquiry with the page families and author roster you already know. That is enough for a first architecture conversation.