Magento 2 & Adobe Commerce
Nine years on Magento, most of it on the awkward end: multi-store catalogues, five-level approval chains, and the ERP and PIM boundaries no theme setting will ever express.
What it means
Magento earns its cost in exactly one situation, and it is not the one it is usually sold into. It earns it when the catalogue, the pricing logic or the approval structure is genuinely complicated, and when that complication is the business rather than an accident of how the last system was built.
At Nxtby I led delivery of 12+ multi-store Magento 2 platforms handling 500K+ SKUs and 1M+ monthly users, and designed five-level approval workflows covering development, B2B orders, quotes and vendor management. Before that, at Magneto IT Solutions, Magento builds for Saudi retail across grocery, commercial kitchen equipment and fashion, including Al Jazira Supermarkets, with layered navigation, dynamic pricing and custom checkout flows.
The performance half is not separable from the build. Magento at catalogue scale is a caching and query problem long before it is a front-end problem, which is why the Nxtby work included cutting page load times by 60% through Varnish, Redis, full-page cache, CDN and database tuning, and running the platform on AWS EC2, RDS and S3 with load balancing and auto-scaling.
Problems solved
The symptom as the person with the problem describes it, then what is usually underneath it.
The store is slow and nobody can say why
Time to first byte climbing, Core Web Vitals failing on real devices while the lab score looks fine. On Magento the cause is almost always below the front end: cache invalidation, a query plan, or an index doing a full scan.
Every B2B order needs a human, twice
Quotes, negotiated pricing and approval chains being run through email and a spreadsheet. At Nxtby, automating that took 90% of B2B order and quote processing off people and cut approval cycle time by 40%.
Multi-store has become multi-copy
Each storefront diverging until a change has to be made four times. The fix is in the store and website scope model and the attribute set design, and it is much cheaper before the fourth store than after it.
Search cannot find the catalogue
Crawl budget spent on faceted URLs, thin category pages, and product data structured so that neither a crawler nor a language model can make sense of it.
The ERP integration is the whole roadmap
Stock, price and order sync built as point-to-point scripts rather than a boundary. Every schema change on either side becomes an outage.
When it applies
Signals it is time
- More than one storefront, or more than one currency, or both
- Pricing that varies by customer, contract or volume
- An approval step between the cart and the order
- A catalogue large enough that indexing time is a planning constraint
- An ERP or PIM that is the system of record for price and stock
And when it is the wrong call
A single-store brand with two hundred SKUs and no custom workflow pays for Magento twice: once to build it, and again every month to keep it running. That business is better served on Shopify, and I will say so.
Every one of the six pages under expertise carries one of these. A consultant who recommends everything for everyone is a vendor with a wider catalogue.
Approach
Model the catalogue before the theme
Attribute sets, store and website scope, price scope and inventory sources. These are the decisions that are almost impossible to reverse once real data is in, and the ones most often made by whoever set up the first storefront.
Design the workflow as a first-class thing
Quote, approval, role and permission structures modelled explicitly rather than assembled from extensions. Five levels of approval is a data model, not a plugin.
Build the cache layer with the build
Varnish, Redis, full-page cache and CDN configured as part of the architecture rather than added when the site gets slow. Cache invalidation designed at the same time, because that is the half that breaks.
Measure on real devices
Core Web Vitals from field data, not a lab score. The number that pays is the one collected from the devices your customers actually hold.
Stack
Magento 2Adobe CommerceCustom modulesMulti-storeB2B workflowsGraphQLVarnish & RedisAWS EC2 / RDS / S3
Related work
Full case studies are published on the Raulji Technologies site, which is where delivery lives.
Related writing
Questions
How much Magento 2 experience is behind this?
Magento work since 2016, and Magento 2 specifically across Sinelogix, Magneto IT Solutions and Nxtby. At Nxtby that meant 12+ multi-store Magento 2 platforms carrying 500K+ SKUs and 1M+ monthly users, first as a senior developer and since 2023 as team leader setting architecture direction.
Is Adobe Commerce different from Magento 2 for this work?
Architecturally they are the same platform. The difference is what you get without building it: B2B modules, staging and preview, and the commercial support contract. Whether that is worth the licence depends entirely on whether you would otherwise build those pieces, which is a due diligence question rather than a preference.
Can you improve an existing Magento store rather than rebuild it?
Usually yes, and usually faster. Performance work, checkout optimisation and catalogue restructuring on a live store return value in weeks. A rebuild is justified when the data model itself is wrong, and that is rarer than it is proposed.
Do you handle Magento hosting and server setup?
Yes. Production Magento on AWS with EC2, RDS and S3, load balancing and auto-scaling, behind Nginx with Varnish and Redis. I have written up the full production setup, and that article is linked below.
Whether you are scaling an existing commerce platform, planning a migration, exploring headless architecture or looking at AI-driven transformation, the first conversation costs nothing and usually shortens the second one.