Every new Edge Delivery project seems to start with the same anxious meeting: document authoring or the Universal Editor, and which one are we betting the whole build on?
It feels like a fork in the road that decides everything downstream, so teams treat it like one. They research both, argue about both, and stall, because the choice sounds irreversible and toolchain-defining. The latest Launch Kit takes that meeting off the calendar. It supports both content sources, DA and JCR, with the Universal Editor available on either, so the decision becomes a dropdown at project creation instead of a bet you have to get right up front.
Is the DA-or-JCR choice a one-way door?
Mostly, no. And it helps to name the decision correctly first, because that anxious meeting usually mislabels it. Teams argue “documents or the Universal Editor,” but that pair isn’t the fork. Your content source is: Document Authoring or JCR. The Universal Editor sits on top of both, so it was never the thing you were choosing between.
Even the content-source choice is far less binding than it sounds. The story goes that one source commits you to one toolchain and the other to a completely different one, with different skills, different conventions, and a different definition of “done,” and that choosing wrong means rebuilding. That framing is mostly wrong, and it costs teams weeks. The two paths differ far less than the anxiety around them suggests. Once you see what actually changes between them, the fork mostly disappears.
What actually differs between DA and JCR?
Not as much as the fork metaphor implies. Whichever content source you pick, you get the same kind of thing: a front-end Edge Delivery project. Blocks are JavaScript and CSS running on the edge, the code lives in a GitHub repo, and content syncs through AEM Code Sync. That delivery model is identical either way.
What differs is narrower than it looks: where your content lives, and how authors edit it.
| Document Authoring (DA) | JCR | |
|---|---|---|
| Content source | Documents on da.live | AEM’s JCR |
| Authoring surface | Documents, or the Universal Editor | The Universal Editor |
| Delivery model | Edge-delivered EDS blocks | Edge-delivered EDS blocks |
| Repo & sync | GitHub + AEM Code Sync | GitHub + AEM Code Sync |
| Front-end stack | Vanilla JS/CSS, no build pipeline | Vanilla JS/CSS, no build pipeline |
The bottom three rows are identical on both sides. The choice changes where content comes from and how authors touch it, not how the site is built or delivered.
The authoring row is the one to read carefully, because it’s where the real misconception lives. The Universal Editor is not “the JCR option.” It’s an authoring surface, and Launch Kit supports it on both sources. On DA, authors can work in documents or in the Universal Editor. On JCR, the Universal Editor is the authoring surface, since JCR content is authored there. So picking JCR doesn’t mean picking the Universal Editor as though it were unavailable elsewhere, and picking DA doesn’t rule the Universal Editor out.
And picking JCR does not mean classic AEM component development. A JCR-source project is a front-end EDS project like any other. No OSGi, no Sling, no HTL, no Maven, no Java; JCR is simply where its content lives. Most of the hesitation around it is really a fear of being pulled back into that old AEM stack. That fear is misplaced.
How can one accelerator support both DA and JCR?
Because the delivery model is shared. One accelerator can serve both sources, and that’s what Launch Kit now is. It’s a single package built to support DA and JCR, with Universal Editor authoring available on both, and you choose your setup as a project type in the Create New Project form. Not a different download, not a separate “xwalk kit” to hunt down and configure. One kit, one choice at the start.
Pick a JCR project and you get full Universal Editor support out of the box: in-context, WYSIWYG authoring, with the developer agent, the /admin surfaces, and the content interfaces all understanding the aem-jcr project type natively. Pick DA and you get the Universal Editor as an option alongside document authoring, so authors can work whichever way suits them. Either way, the platform knows what it scaffolded and the agentic workflow that follows is correct for the route you chose, without any manual reconfiguration.
The practical shape of it: instead of spending the first days of a project hand-assembling boilerplate for whichever setup you picked, and hoping you set it up the way EDS expects, you choose a project type from a dropdown and Launch Kit hands you a correct, opinionated starting point in minutes. Then the same Agentic Delivery workflow takes over from there. The setup tax that used to front-load every EDS project, and that got paid twice by anyone who wanted to support both sources, is carried by the kit.
Every Launch Studio customer gets Launch Kit
Launch Kit isn’t an upsell or a bespoke engagement. It’s the standard accelerator every Launch Studio org starts new projects from. That’s what makes “dual-source” more than a feature note: it means every customer, on every project, can start either flavor of EDS without a special arrangement or a services conversation. Access is the story as much as capability is.
So the anxious meeting doesn’t just get easier for one well-resourced team that happened to build the right internal tooling. It gets easier for everyone on the platform, by default, on the next project they create.
What if you’d rather bring your own accelerator?
Then bring it. Launch Kit is the starting point we ship, not a cage. Take it as-is, borrow the parts you like, or leave it entirely; nothing about Launch Studio assumes you started from our kit.
Most teams, in practice, will end up wanting their own. A shop develops house conventions, a shared block library, a layout it likes new projects to follow, and it wants work to start from that rather than from a generic base. Launch Studio’s Starter Kits feature is built for exactly that. Cut a GitHub release of your accelerator repository, upload the compressed archive into the platform, and it becomes a one-click bootstrap for every future project from your own source. Your template, your conventions, scaffolded in the same minutes-not-days way Launch Kit is.
So “dual-source” isn’t a ceiling. It’s the default you get out of the box, on top of a platform that’s just as happy to launch from an accelerator your own team built.
The DA-or-JCR choice is smaller than it feels
The fork was never as sharp as it felt. DA and JCR are two content sources on top of the same edge-delivered front end, with the Universal Editor available on either, and a single accelerator can hand you whichever fits in minutes. A lean team can start whichever suits the client in front of them, and switch its mental model between projects without switching tools or relearning a stack.
That fits the larger recalibration EDS asks of teams, which we walked through in Migrating to Edge Delivery Services Is a Paradigm Shift: the delivery model is the constant, and most of what feels like a hard, permanent choice is really a smaller decision than it appears. Launch Kit is where that shows up on day one of a project.
If you’re staring at the DA-versus-JCR decision and trying to figure out which one commits you to what, we’re happy to talk it through, or just show you a project scaffolded both ways in a few minutes so you can see how little actually diverges. Tell us what you’re building and we’ll point you at the right project type for it.
