DA turns three

Someone posted on LinkedIn that DA turned three years old.

Maybe because the idea of DA hatched at Adobe Summit and I'm currently in Las Vegas for Adobe Summit 2026, but I really cannot believe it's been three years. It's been a wild ride.

At this point, DA has arguably become a success story. We are radically changing how people think of content management. DA has been able to elegantly evolve with the most disruptive pieces of technology our world has seen in the last 25 years. This is not just in the way we build DA itself, but also how our creators use modern tools to create. It turns out AI is really goodat working with DA content.

Who made DA possible

Before I get too far ahead of myself, I do want to make sure everyone understands how important people are to DA's trajectory. I say it a lot because it is so important: DA would not exist without the numerous people who have worked so hard to bring it to life.

The four categories of individuals who made DA possible:

1. The internal Adobe engineers and managers that used every trick in the book to find a way to contribute to DA even though it may have gone against their own leadership's wishes.
2. The few influential people within Adobe leadership who went to bat for us when we were still a little skunkworks project pissing everyone off.
3. The leadership detractors that made noise (and not the good kind), but ultimately gave us the space to prove we were onto something.
4. The community that cared enough to use DA, ask questions, file issues, submit PRs, and everything in between.

To say these folks were vital to DA's success would be an understatement. Please keep these individuals in mind as we walk through the next sections.

The early days

The decisions we made in the early days turned out to be prescient. We made decisions purely based on constraints:

1. What is the persistence mechanism which can scale to zero cost because this is all self funded?
2. What is the persistence format that requires no developer training or documentation needed?
3. How do we build something that can be maintained by a group of individuals that are all volunteers and can be ripped away at any moment?

We simply couldn't afford to have a large support surface in every single metric. It is also not lost on me that most of DA has been built three times. Some examples:

1. Home - Originally built as Preact, then built as Lit, then pivoted away from "orgs" to "sites"
2. Browse - Again, originally built as Preact, then rewritten in Lit, then re-built again when we knew how to build better Lit components.
3. Editor - I stole the original editor from Slick 2, then I tried vanilla, then I discovered ProseMirror, then Karl added real-time collaboration. Many parts within the editor have also been built three times.
4. API - Last, but certainly not least: we built the API 3 times. First directly on disk, then using Hono, then as a bare-metal Cloudflare Worker.

Ability to evolve

The premise above is that DA has proven to be capable of rapid evolution. It turns out that when you're militant about grinding and polishing an idea down, it makes you more nimble in the long run. Every decision or even lack of decision has deliberate.

We're currently in the midst of re-building the foundational parts of DA. We are validating and formalizing all the hunches that turned out to be right. We are standardizing how we solve common problems that live across our codebase.

In the best and worst way possible, DA subscribed to Edge Delivery principles: don't over engineer, it's ok to have two functions be slightly similar, but different. Now as we look at merging the DA & Edge Delivery APIs, that nimbleness of creating several similar functions becomes annoying.

This is software development, after all. We make decisions not because they are perfect, but because they are the lesser of evils. We make decisions based on the knowledge we have at the time and the hunches we have for the future. We constantly say, "yes, this will be an issue later down the road, but forcing ourselves into this pattern prematurely would create a bigger mess today."

We didn't want to have some client-side API abstraction just for the sake of it. I barely allowed daFetch to exist as a convenient way to wrap all known origin requests with an auth header. We want to thoroughly understand the scope of our problem space before we make any big decisions. We would almost rather be late than to be early.

DA2 and beyond

As I alluded to above, we are re-building DA again. This is more of an operational concern that keeps me up at night, and not something you need to be too concerned with. For me, this next wave of major DA updates sets us up for the next 2-3 years. They pay off ideas already in place, but like before, these existing ideas need to be ground and polished down into a cohesive authoring experience for both humans and agents. The word cohesive is the perfect word for this endeavor:

• It's not that you cannot have Claude talk to DA today, but wouldn't it be great if you could do that right from DA itself?
• It's not that can't use Universal Editor with DA, but wouldn't it be great if it felt less bolt on?
• Quick Edit is great, but why can't it replace Live Preview?
• DA's user experience was built when Spectrum 2 (Adobe's design language) was still in its infancy. We can now work in lock step with that team to build world-class authoring experiences.
• Wouldn't it be great if the DA and Edge Delivery APIs were one in the same? We certainly do.

All of these will land at different times... and no, don't ask us when.

Wrapping up

I haven't been this excited about AEM's roadmap since AEM 6.3. I believe we're at a major inflection point where Edge Delivery is no longer considered experimental, but it is considered the best way to build for the future.

It's fun to say we've built things for Adobe Summit that we have never been able to build before. All with the speed and simplicity DA is known for.