Yuvraj Raulji | Magento
Magento earns its cost in one situation: when the catalogue, the pricing logic or the approval structure is genuinely complicated, and that complication is the business rather than an accident of how the last system was built. Nine years on it, most of that on the awkward end. It is also the platform I most often tell people not to buy.
Quick answer
Magento is a self-hosted commerce platform, sold commercially as Adobe Commerce. Unlike a hosted platform it hands you the data model: attribute sets, store and website scope, price scope, inventory sources and the workflow layer above them. That is what makes Magento the right answer for catalogues, pricing rules and approval chains a hosted checkout cannot express, and the wrong answer for everything else. The business problem Magento addresses is complexity that genuinely exists. The cost is that you own the operating burden: hosting, caching, upgrades and the engineering time all three consume.
Best suited for
- B2B commerce with quotes, contracts and approvals
- Multi-store or multi-currency operations
- Catalogues large enough that indexing is a planning constraint
- Businesses where an ERP or PIM is the system of record
Business problems
The symptom as the person with the problem describes it, what it is costing, and where the technology actually helps.
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.
OpportunityMagento performance is a caching and query problem before it is a front-end one. Varnish, Redis, full-page cache, CDN and database tuning cut page load times by 60% on a high-traffic B2B platform, and none of that touched the theme.
Every B2B order needs a human, twice
Quotes, negotiated pricing and approval chains run through email and a spreadsheet. The cost is not the software, it is the people waiting for each other.
OpportunityMagento models approvals as a data structure rather than a plugin. Five-level chains covering development, B2B orders, quotes and vendor management took 90% of 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. Every new market makes the next one more expensive.
OpportunityThe 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. This is the decision Magento exists to give you.
Search cannot find the catalogue
Crawl budget spent on faceted URLs, thin category pages, and product data structured so neither a crawler nor a language model can make sense of it.
OpportunityLayered navigation and canonical strategy at the Magento configuration level, plus catalogue structure that makes the same product data usable by search, by on-site filtering and by AI retrieval.
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.
OpportunityAn explicit integration contract over the Magento API, with the system of record named for each field. Boring, and it is the difference between a roadmap and a maintenance rota.
Approach
Five stages, in this order, on every engagement. Skipping the first one is the most expensive habit in this industry.
Understand
Business modelCustomersProductsOperations
What the pricing rules genuinely are, who approves what, and which system is the source of truth for stock and price. On Magento this is not discovery theatre: these answers become the data model, and the data model is the part that cannot be changed later.
Architect
SystemsIntegrationsCustomer journey
Attribute sets, store and website scope, price scope and inventory sources, decided before the theme. These are close to irreversible once real data is in, and they are most often set by whoever configured the first storefront in a hurry.
Build
TechnologyExperienceFunctionality
Custom modules rather than accumulated extensions, workflow modelled explicitly, and the cache layer built with the build rather than added when the site gets slow. Cache invalidation is designed at the same time, because that is the half that breaks.
Optimize
PerformanceCROSEOCustomer experience
Core Web Vitals from field data rather than a lab score, checkout flow, and the technical SEO that catalogue-scale Magento specifically needs: faceted URL handling, canonical strategy and crawl budget.
Scale
AutomationAIAnalyticsPersonalization
Catalogue enrichment where the SKU count is past what people can maintain, semantic search over that catalogue, and operations automation across quotes, approvals and reconciliation. Magento is where most of this gets wired in, because it is where the rules already live.
Capabilities
Catalogue
- Attribute set design
- Multi-store scope
- Layered navigation
- Pricing rules
- Inventory sources
B2B commerce
- Quotes and negotiation
- Approval workflows
- Company accounts
- Contract pricing
- Requisition lists
Integrations
- ERP and PIM
- CRM
- Payment gateways
- OMS and fulfilment
- GraphQL and REST APIs
Performance
- Varnish and Redis
- Full-page cache
- Database tuning
- CDN and image pipeline
- AWS provisioning
AI
- Catalogue enrichment
- Semantic search
- Operations automation
- Data reconciliation
AI and technology
What each application does, how it works, where the value is, where a person still reviews it, and what it will not do.
Catalogue enrichment at scale
- What it does
- Generating the attributes, descriptions and structured data a 500K SKU catalogue needs and no team can write by hand.
- How it works
- A pipeline reads existing product data, supplier feeds and images, drafts missing fields against the attribute set, and writes back through the Magento API in reviewed batches.
- Where the value is
- Attribute coverage, which is what layered navigation, search relevance and category page quality all depend on. On a catalogue this size it is the difference between filters that work and filters that are decorative.
- Where a human reviews
- Review before publish, and spot checks by category afterwards. Enrichment that is 98% right across 500,000 products is still ten thousand wrong product pages.
- What it will not do
- It cannot correct a supplier feed. Wrong source dimensions become enriched wrong dimensions, faster and in more places.
Semantic search over the catalogue
- What it does
- On-site search that understands what a customer means rather than matching their words against product titles.
- How it works
- Embeddings over product text and attributes, blended with the existing keyword index so SKUs and part numbers still match exactly. On Magento this sits alongside the search engine rather than replacing it.
- Where the value is
- No-result rate and conversion on search sessions. On a large catalogue this is where the money is, because a customer who searches has already decided to buy something.
- Where a human reviews
- A merchandiser reviews the failing queries monthly, and the category gaps they expose are a buying decision rather than a search one.
- What it will not do
- It amplifies the catalogue it is given. Thin product data produces confident, thin results.
Operations automation
- What it does
- Taking repetitive work out of quotes, approvals, catalogue QA and data reconciliation.
- How it works
- Workflow automation wired into the Magento API and the approval model, with retrieval where a step needs to read policy or contract terms rather than follow a fixed rule.
- Where the value is
- Hours off the rota and cycle time on approvals. On a B2B platform this route took 90% of order and quote processing off people and cut approval cycle time by 40%, and the first version of it was deterministic rather than generative.
- Where a human reviews
- Anything touching price, credit or a customer commitment keeps a named approver. The automation prepares the decision; it does not make it.
- What it will not do
- It cannot fix a process that should not exist. Automating an unnecessary approval step makes it permanent, which is why the process redesign comes first.
Data reconciliation
- What it does
- Finding where Magento, the ERP and the PIM disagree, before a customer does.
- How it works
- Scheduled comparison across the integration boundary, with the differences classified rather than dumped into a report nobody reads.
- Where the value is
- Fewer oversells, fewer price disputes, and integration bugs found while they are still small. This is unglamorous and it is the highest-return automation on most B2B platforms.
- Where a human reviews
- Someone decides what the correct value is. The system says the two sides disagree; it does not know which one is right.
- What it will not do
- It reports, it does not repair. Automatic correction across a system boundary is how a small discrepancy becomes a large one.
Architecture
How the pieces sit together, top to bottom. Only technologies actually used appear here.
Customer
Web and mobile, plus the B2B buyer working inside an approval chain.
BrowserPWA
Storefront
Magento templates, or a decoupled front end when the front end needs its own release cycle.
Luma / custom themePWA StudioNext.js
Application
The catalogue, pricing, workflow and approval model. This is what you are paying for.
Magento 2Adobe CommerceCustom modulesPHP
APIs
How the front end and every other system reach the platform.
GraphQLRESTMessage queues
Cache and search
Designed with the build, not added when the site gets slow.
VarnishRedisFull-page cacheElasticsearch / OpenSearch
Business systems
The systems of record, behind an explicit contract rather than point-to-point scripts.
ERPPIMCRMOMSPayments
Infrastructure
Reproducible production environments rather than a server somebody configured once.
AWS EC2RDSS3NginxAuto-scaling
AI
Reads and writes through the same APIs, respecting the price and permission scope.
Enrichment pipelineSemantic searchWorkflow automation
When to use it
Good fit
- 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
Think twice
- A single store with a few hundred SKUs and no custom workflow
- No engineering capacity to own hosting, caching and upgrades
- A team that needs to ship merchandising changes without a developer
- Speed to market as the binding constraint
- Flexibility bought for a roadmap that has not been written yet
Comparison
Magento wins the rows that matter only if your business is actually in them. A single-store brand with two hundred SKUs pays for this platform twice, once to build it and again every month to keep it running, and that business belongs on Shopify. The test is whether your pricing and approval rules can be expressed inside a hosted checkout.
| Criterion | Magento | Shopify | WooCommerce |
|---|---|---|---|
| Speed to launch | Months | Weeks | Weeks to months |
| Customisation | Effectively unlimited | Within platform limits | Unlimited, at plugin quality |
| Enterprise complexity | Where it is strongest | Plus, up to a point | Rarely the right answer |
| Operations | You own the operating cost | Managed for you | You own the operating cost |
| Scalability | Yours to engineer, proven at 1M+ users | Handled by the platform | Yours to engineer |
| Content ecosystem | Adequate | Adequate | Best of the three |
| Headless capability | GraphQL, mature | Storefront API, Hydrogen | REST, workable |
| AI opportunity | Search, catalogue, operations | Search and catalogue | Search and content |
Relevant work
The two builds where Magento was doing the work it is actually for: catalogue scale, and a B2B workflow that could not be expressed anywhere else.
Magento 2 · MarketplaceMulti-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Custom platform · B2BProcurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Business outcomes
60%
Cut in page load times
Performance work on a high-traffic B2B commerce platform, where the bottleneck was below the front end rather than in it.
Where this came fromAchieved through Varnish, Redis, full-page cache, CDN and database tuning on Magento 2 at multi-store scale. It is a caching and query result, not a theme result, and it is the figure this site quotes most often because it is the best measured.
90%
Of B2B order and quote processing automated
Approval chains modelled as a data structure rather than assembled from extensions, covering development, B2B orders, quotes and vendor management.
Where this came fromFrom the same B2B commerce platform. Approval cycle time fell by 40% alongside it. The automation was deterministic workflow, not AI, which is worth saying plainly.
500K+
SKUs under management
The point where catalogue size stops being a number and starts being an architecture problem: indexing time, attribute design and search relevance all become planning constraints.
Where this came fromAcross 12+ multi-store Magento 2 platforms serving 1M+ monthly users, led end to end.
Operating cost
The figure nobody puts on a slide. Magento is worth its maintenance, hosting and upgrade burden only when the complexity it handles is real, and measuring that ratio honestly is the most useful thing a platform review produces.
Every figure above comes from Magento work and is quoted with the conditions it was measured under. They are not portable: a 60% improvement on a badly cached multi-store platform says nothing about what is available on a store that is already fast.
FAQ
- What is Magento?
- Magento is a self-hosted commerce platform, sold commercially by Adobe as Adobe Commerce. It gives you the catalogue data model, pricing rules and workflow layer directly, which is why it suits complex B2B and multi-store commerce and why it costs more to run than a hosted platform.
- When is Magento the right choice?
- When the catalogue, the pricing logic or the approval structure is genuinely complicated and that complication is the business. More than one storefront, pricing that varies by contract, an approval step between cart and order, or an ERP that owns price and stock. Any one of those is a real reason; none of them being present is a real reason not to.
- Is Magento suitable for B2B commerce?
- It is the strongest case for it. Quotes, negotiated pricing, company accounts and multi-level approvals are modelled in the platform rather than bolted on. Five-level approval chains across development, B2B orders, quotes and vendor management is the shape of work this platform is built for.
- Can Magento support multi-store commerce?
- Yes, and the store and website scope model is one of the main reasons to choose it. The caution is that scope and attribute set decisions are close to irreversible once real data is in, so they need deciding before the first storefront rather than before the fourth.
- How much Magento experience is behind this?
- Magento work since 2016 and Magento 2 specifically across three commerce teams since then. Most recently 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 arrives without being built: B2B modules, staging and preview, and a commercial support contract. Whether that is worth the licence depends on whether you would otherwise build those pieces, which is a due diligence question rather than a preference.
- Can Magento integrate with ERP and CRM systems?
- Yes, over GraphQL, REST and message queues. The integration succeeds or fails on the contract rather than the protocol: which system owns each field, what happens when they disagree, and how a schema change on either side is versioned. Point-to-point scripts are what turn every change into an outage.
- Can Magento support headless architecture?
- Yes, through GraphQL, with PWA Studio or a custom Next.js front end. It is worth doing when the front end needs its own release cycle. It is not a performance fix on its own, and on Magento the performance answer is usually the cache layer.
- How can AI be integrated with Magento?
- Catalogue enrichment with human review, semantic search over the catalogue, and operations automation across quotes, approvals and reconciliation. All three read and write through the Magento APIs so they respect the price scope and permission model, which is what separates them from a demo.
- How can Magento performance be improved?
- Start below the front end. Cache invalidation, query plans and indexing account for most Magento slowness, and Varnish, Redis, full-page cache, CDN and database tuning are where the 60% improvement on the B2B platform came from. Measure with field data from real devices, not a lab score.
- Magento or Shopify: which is better?
- Neither in the abstract. Magento wins on catalogue complexity, quote-driven pricing, multi-store and B2B workflow. Shopify wins on time to market and operating cost. If your pricing and approval rules fit inside a hosted checkout, the comparison is already settled and the answer is Shopify.
- When should a business consider migrating away from Magento?
- When the flexibility is no longer being used. If the store is single-site, the pricing is uniform and nobody approves anything, the platform is charging maintenance and hosting for capability the business does not exercise. That is a spreadsheet exercise, and it is worth doing honestly.
Next step
Let us look at your business model, the systems you already run and where you are trying to get to, before choosing the technology. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.