Adobe Commerce is entering a new era - the platform is becoming faster, more modular, and easier to extend – but this transition also changes the way we, as engineers and architects, work.
This isn’t about just faster deployments or nicer APIs. It’s about making Adobe Commerce a viable, modern, and scalable platform in a world where time-to-market and developer efficiency matter more than ever.
The Cost of Complexity
Traditional Adobe Commerce development tightly couples business logic with platform internals. Customizations share infrastructure and codebase with the core system, which means every change must conform to the same strict platform development standards - abstraction (Dependency Injections), strict extending interfaces, XML coding.
This level of rigor is reasonable for platform maintainers. But for everyday solution builders, it creates friction:
- Minor features take too long to implement
- Core upgrades become a nightmare of dependency and compatibility
- Integrations (like ERP) turn into full-blown projects just to set up queues, schedulers, and cron jobs before the actual logic even begins
The result? Slower delivery and higher budgets - in today’s market, that’s no longer competitive.
The Architecture Behind the Shift
Adobe’s transition to a service-first model, led by App Builder, advanced APIs, and an event-driven development (EDD) environment – changed the game.
Instead of embedding code inside the core platform, developers now build external applications that respond to business events via asynchronous Adobe I/O triggers or synchronous webhooks. This decouples custom logic from Magento’s internals - freeing teams from the strict platform development standards.
It’s not just a technical shift - it’s architectural freedom.
These apps:
- Run independently from Adobe Commerce, reducing risk, improving performance, and simplifying maintenance
- Skip the usual structural overhead and get straight to logic
- Rely on a consistent API layer, so both internal tools and third-party systems communicate the same way
- Use a Node.js development environment, making full-stack development more accessible and scalable
- Offload custom workloads to separate infrastructure, allowing the core platform to focus on commerce operations
On one project, we used App Builder to connect Narvar with our ERP – without ever touching the core platform.
On another, we rapidly built a proof-of-concept for a new payment gateway - validating the integration approach early, without the overhead typical in traditional Magento development. This kind of architectural freedom lets teams de-risk delivery by testing/PoC critical flows before committing to full implementation.
This model doesn’t just reduce friction. it unlocks delivery velocity, staffing flexibility, and smarter allocation of engineering effort.
Worth a Closer Look
I was genuinely excited to try App Builder and that was part of the problem. Adobe doesn’t offer public access: only Adobe Commerce Cloud clients can use it. That seriously slows down adoption and engineering community growth. I truly hope Adobe reconsiders this approach and makes the tooling more accessible in the near future.
When we finally got access, what impressed me most was the simplicity of implementation and the flexibility of the environment. And more importantly, AI became a much more effective coding assistant – unlike the legacy model where structural complexity limits its value.
If you're just starting, I’d recommend picking a small use case. For example, we extended backorder logic by adding a backorder threshold:
- Added a new product attribute
- Subscribed to the After Order Place event
- Queried product data using GraphQL
- Used the REST API to set items to out-of-stock when the threshold was reached
As you can see, it's easy to start small and even that gives you a clear understanding of the new model. Continuing with the legacy architecture will only increase the time and cost of a future SaaS migration.
Right now, I don’t see any major architectural bottlenecks that would prevent adopting this approach. It’s simple and, as a consequence, highly reliable.
From Exploration to Readiness
If you're running on Adobe Commerce Cloud, I strongly recommend exploring App Builder. Start small, get familiar – especially if you're planning any future integrations.
Even limited adoption now can significantly reduce the cost and complexity of your future SaaS migration.
The earlier you start, the easier it gets.
source LinkedIn
Summary:
- Platform: Adobe Commerce (Magento 2)
- Focus: Transition to SaaS (EDS, App Builder, Catalog Service, Adobe I/O, EDD, Events)
- Use Cases: Faster development, reduced TCO, scalable architecture
- Related terms: API-first, headless, serverless, Edge Delivery Services, EDD, Commerce as a Service
tags: AdobeCommerce, SaaS, microservices, Edge Delivery Services, EDS, Magento, App Builder, Adobe Commerce As Service, Adobe I/O