CMS & Commerce
Magento
Complex e-commerce on Magento, built and operated by engineers who will tell you when you don’t need it.
Overview
Magento is an open-source e-commerce platform written in PHP, now owned by Adobe and split into two editions: Magento Open Source, which is free to use and self-hosted, and Adobe Commerce, the paid enterprise edition that adds features like B2B accounts, content staging, advanced marketing tools and a managed cloud. Both share the same core: a deep, attribute-driven catalogue model, a sophisticated pricing and promotions engine, multi-store and multi-currency support out of the box, and a granular admin that lets merchandising teams control almost everything without a developer. It is built for scale and complexity rather than for getting a shop live in a weekend.
That power comes from a heavily layered architecture — an EAV catalogue, a module system, dependency injection, service contracts, and a rich but demanding set of conventions. Done well, it is genuinely extensible: you can model complex products, run different storefronts off one backend, and build custom commerce logic that would be a fight on a hosted platform. Done badly — and much of the Magento in the wild is done badly — it becomes slow, fragile, and eye-wateringly expensive to change. The platform punishes shortcuts more than most.
We work on Magento in three modes. We build new stores for merchants whose catalogue and business rules genuinely justify it; we rescue existing stores that have become slow or unmaintainable, usually through caching, infrastructure and code that were never engineered properly; and we advise honestly on the Magento-to-Shopify decision, because a large share of Magento sites are over-engineered and would be cheaper, faster and calmer on something simpler. We operate what we build, so we care whether the thing is still tuneable in two years, not just whether it launches.
Best for — Established merchants with large, complex catalogues and sophisticated B2B or multi-store requirements — where the customisation and control genuinely justify Magento’s cost, and a simpler platform would hit a wall.
Why teams choose Magento
A catalogue model built for complexity
Magento’s attribute-driven catalogue handles configurable, bundled and grouped products, custom attribute sets and per-store overrides natively. For a genuinely complex range this is a huge head start over platforms where you would fight the data model or bolt on apps.
Multiple storefronts off one backend
The store hierarchy — websites, stores, store views — lets you run several brands, regions, currencies and languages from a single admin and codebase. For a multi-brand or international merchant that is a structural advantage, not a plugin.
Deep control and extensibility
Because it is open source and modular, nothing is off-limits. Custom pricing logic, bespoke checkout steps, integrations with ERP and PIM — all buildable properly rather than hacked around a closed platform’s constraints. That freedom is the whole point of choosing Magento.
Why businesses choose Magento
- Your catalogue or commerce logic has outgrown, or would immediately outgrow, what a hosted platform can express.
- You run multiple brands, regions or currencies and want them on one backend rather than a patchwork of separate shops.
- You need serious B2B capability — accounts, quotes, negotiated pricing — without building it from nothing.
- You want to own your platform and its code, and you have the appetite (or want us to provide it) for the hosting and maintenance that ownership entails.
What we build with Magento
The capabilities this technology is genuinely strong at — and what we most often build with it.
EAV catalogue and attribute sets
Magento’s Entity-Attribute-Value model lets products carry arbitrary attribute sets that vary by product type, with per-store-view overrides. It is what makes the catalogue so flexible — and, if misused, a source of slow queries. We model it deliberately and index it properly.
Websites, stores and store views
The multi-store hierarchy is a first-class feature: one installation serves multiple websites, each with its own stores and localised store views, sharing catalogue and customer data where it makes sense. We use it to run multi-brand and international estates cleanly.
Price rules and promotions engine
Catalogue price rules, cart price rules, tiered and customer-group pricing, and stackable promotions give merchandisers expressive control over pricing. We configure and, where needed, extend this engine rather than hard-coding discounts that nobody can later change.
The module and plugin system
Magento’s architecture is built around modules, dependency injection, and plugins (interceptors) that modify core behaviour without editing core code. Used with discipline this keeps customisation upgrade-safe; used carelessly it creates the conflict-ridden messes we are often called in to fix.
Elasticsearch-backed catalogue search
Modern Magento uses Elasticsearch or OpenSearch for catalogue and layered-navigation search, replacing the old MySQL search that buckled under large catalogues. We configure relevance, synonyms and faceting so search actually finds products rather than merely returning them.
Headless via GraphQL and PWA Studio
Magento exposes a GraphQL API and supports headless storefronts, including Adobe’s PWA Studio, so a React front end can drive a Magento backend. We build headless only when it earns its keep — the decoupling adds moving parts, and the default Luma-style storefront is often the pragmatic choice.
Use cases
Large multi-brand retail
A retailer running several brands or regional sites off one backend, with shared catalogue data, localised pricing and currencies, and a single admin — the multi-store scenario Magento was built for.
B2B and trade commerce
Wholesale and trade merchants needing company accounts, negotiated price lists, quote workflows and purchase-on-account — served by Adobe Commerce’s B2B feature set rather than a stack of extensions.
Complex configurable catalogues
Merchants whose products have deep option trees, bundles, and variant-specific pricing — furniture, industrial parts, made-to-order goods — where the catalogue model is the deciding factor.
Performance rescue of an existing store
A Magento store that has grown slow and fragile — poor caching, unindexed attributes, extension bloat, undersized infrastructure — where we tune the code and hosting rather than rebuild from scratch.
When Magento is the right choice
- Right when you have a large or complex catalogue — thousands of SKUs, deep attribute sets, configurable and bundled products — and you need real control over how it is modelled and merchandised.
- Right when your commerce rules are genuinely sophisticated: multi-store or multi-brand off one backend, multiple currencies and tax regimes, complex tiered or customer-group pricing, and intricate promotions that hosted platforms cannot express.
- Right for serious B2B or mixed B2B/B2C: company accounts, quotes, purchase-on-account, negotiated price lists — where Adobe Commerce’s B2B feature set does work you would otherwise build from scratch.
- Wrong for a small or mid-size merchant with a straightforward catalogue. Magento is heavy to build and expensive to host and maintain; Shopify or WooCommerce will get you live faster, cost far less, and need no specialist infrastructure. Choosing Magento here is over-engineering, and we will say so.
- Wrong when you want the platform to run itself. Magento needs real hosting, real caching, and someone competent watching it; if you have no appetite for infrastructure and specialist maintenance, a hosted platform removes an entire class of problem you would otherwise own.
Magento: pros and cons
Strengths
- Exceptionally capable catalogue, pricing and promotions engine — it handles complexity that hosted platforms simply cannot express.
- Open source and fully extensible: you own the code, and any behaviour can be customised or integrated properly rather than worked around.
- Native multi-store, multi-currency and multi-language support, plus a strong B2B feature set in Adobe Commerce, out of the box.
- Granular, powerful admin that gives merchandising and marketing teams real control without needing a developer for routine changes.
Trade-offs
- Heavy and expensive to build. The learning curve is steep, the conventions are strict, and getting an implementation right takes senior PHP engineers and real time — this is not a quick or cheap platform.
- Demanding to host well. It needs proper infrastructure — MySQL/MariaDB, Redis, Elasticsearch or OpenSearch, usually Varnish — and performance does not come for free; it is engineered in, with serious caching and tuning.
- Costly to upgrade and maintain. Version upgrades, security patches and extension conflicts are ongoing work, and a store left untended drifts into slowness and vulnerability faster than owners expect.
- Genuine over-engineering for smaller merchants. If your catalogue and rules are not truly complex, Magento’s weight buys you nothing — Shopify or WooCommerce will be faster to launch, cheaper to run, and less to worry about.
Architecture
A Magento build is layered by design: modules encapsulate features, dependency injection wires them together, service contracts define stable interfaces, and plugins intercept core behaviour without patching it. Respecting those layers is what keeps a store upgrade-safe; ignoring them — editing core, overriding blocks wholesale, piling in conflicting extensions — is how the platform earns its reputation for fragility. We build within the conventions, not around them, because the alternative is a store nobody can safely change.
Around the application sits infrastructure that Magento genuinely depends on: MySQL or MariaDB for the primary store, Redis for cache and session storage, Elasticsearch or OpenSearch for catalogue search, and typically Varnish as a full-page cache in front. These are not optional extras for a serious store — they are load-bearing. We provision and configure them deliberately, often on AWS with Docker for parity between development and production, so that behaviour in production is something we understood before launch rather than discovered after it.
Performance
Magento is not fast by default — performance is engineered. Left untuned, a real catalogue produces slow category pages, sluggish search and a checkout that drags. The wins are well understood: full-page caching through Varnish, Redis for cache and sessions, Elasticsearch tuned for the catalogue, correctly configured indexers, production-mode compilation and static-content deployment, and a hard look at whatever extensions are quietly adding queries to every page load. We measure with profiling rather than guesswork, because the real bottleneck is rarely the one people assume.
Most of the slow Magento stores we are asked to rescue are slow for mundane, fixable reasons — caching that was never set up properly, an EAV catalogue that is not indexed, an under-provisioned database, or a stack of extensions each doing a little damage. We are also honest that Magento carries an inherent weight a hosted platform does not, and that keeping it fast is ongoing engineering, not a one-time switch. If the merchant has no appetite for that reality, it is a reason to reconsider the platform, not to promise magic.
Security
Because Magento is self-hosted and handles payments and customer data, security is your responsibility in a way it is not on a fully hosted platform. The essentials are non-negotiable: prompt application of Adobe’s security patches, a hardened admin (renamed path, two-factor authentication, IP restriction), careful vetting of every third-party extension — extensions are the most common route in — and PCI-conscious checkout, usually delegating card data to a compliant payment provider so it never touches your servers.
Beyond patching, we treat the surrounding infrastructure as part of the security posture: a web application firewall, TLS everywhere, least-privilege database and server access, and secrets kept out of the codebase. Magento’s size means a large attack surface and a steady stream of advisories, so we keep the platform and its dependencies current as routine maintenance rather than an annual scramble. An unpatched Magento store is a genuinely dangerous thing, and we say so plainly.
Scalability
Magento scales, but it scales through infrastructure and discipline rather than by accident. The read-heavy storefront benefits from full-page caching and, at higher volumes, database read replicas and split databases; the admin and background work — reindexing, cron, order processing — need headroom of their own. Adobe Commerce Cloud packages a lot of this, but the same architecture is achievable on well-run AWS infrastructure with the caching and search tiers provisioned to match the catalogue and traffic.
The harder scaling limit is usually the codebase, not the servers. A store weighed down by poorly written extensions and unindexed customisation will fall over long before well-engineered infrastructure does. We keep customisation lean and upgrade-safe, keep indexers and caching healthy, and size the database and search tiers to the actual catalogue — so growth is a matter of adding capacity to a sound system rather than firefighting a fragile one.
Magento integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start with a blunt question: does this merchant actually need Magento? If the catalogue and rules do not justify the weight, we say so and point at Shopify or WooCommerce before anyone spends money. When Magento is the right answer, we settle the architecture and infrastructure early — module boundaries, the caching and search tiers, the hosting shape — because these are cheap to get right up front and brutally expensive to retrofit into a live store.
From there we build within Magento’s conventions rather than fighting them, favouring upgrade-safe customisation over clever hacks that break at the next patch. The engineers who build your store are the ones who tune and operate it, so decisions are made by people who will live with the two-year maintenance reality, not just the launch. You get honest trade-offs, a store that stays patchable and tuneable, and no junior learning the platform on your budget.
The service behind it
Delivered throughWeb DevelopmentWhat we build with Magento
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Magento in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in CMS & Commerce
Why teams choose us for Magento
Senior Magento engineers only
Magento punishes inexperience harder than almost any platform — the wrong architectural choice compounds for years. The people making those choices on your store have made them before and have seen how they age. No juniors learning on your project.
We operate what we build
We run the Magento stores we ship, including the hosting, caching and patching. That means we optimise for the platform that is still fast and secure in two years, not the one that merely launches — because we are the ones who would otherwise be firefighting it.
Honest about when to walk away from Magento
A large share of Magento stores are over-engineered. If Shopify or WooCommerce would serve you better and cheaper, we will tell you before you commit — whether that means not starting a Magento build, or helping you move off one.
Rescue as well as build
We are as often called in to fix a slow, fragile Magento store as to build a new one. We diagnose before we prescribe, and we will tune what you have rather than sell you a rebuild you may not need.
Typical timeline
- 01
Discovery and platform decision
One to two weeks confirming Magento is genuinely the right platform, then agreeing the catalogue model, commerce rules, integrations and infrastructure before code volume grows.
- 02
Foundations and infrastructure
Two to three weeks standing up the environments, caching and search tiers, and base configuration — the load-bearing infrastructure Magento depends on — so performance is engineered in from the start.
- 03
Iterative build
Feature-by-feature delivery of catalogue, storefront, checkout and integrations in short cycles, each tested and each staying within Magento’s upgrade-safe conventions.
- 04
Hardening and launch
Full-page caching and search tuning, load testing against real catalogue volumes, security hardening and patch review, then a controlled go-live with monitoring in place.
How pricing works
- Fixed-scope builds for a well-defined store — a defined catalogue, storefront and integration set — quoted once we understand the data model, the commerce rules and the infrastructure required.
- Performance and architecture rescues for existing Magento stores, priced by an initial assessment: we find why it is slow or fragile and cost the fix before committing to it.
- Monthly senior engagement for ongoing store development, upgrades and operation, where scope evolves and you want continuity rather than a one-off deliverable.
- A platform-decision review for merchants unsure whether to stay on, move to, or move off Magento — a fixed-price honest assessment, including the case for a simpler platform.
Hire Magento engineers
Need Magento capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Magento engineersCommon questions
What is the difference between Magento Open Source and Adobe Commerce?
Magento Open Source is the free, self-hosted edition with the full core catalogue, pricing and multi-store capability. Adobe Commerce is the paid enterprise edition built on the same core, adding B2B accounts, content staging, advanced marketing and reporting, and an optional managed cloud. The right choice depends on whether you genuinely need the enterprise features — many merchants do not, and we will help you work out which side of that line you fall on rather than defaulting to the expensive edition.
Should we choose Magento or Shopify?
Choose Shopify unless your catalogue or commerce rules are genuinely too complex for it. Shopify is hosted, simpler, faster to launch and needs no infrastructure of your own — but you trade away deep control. Magento earns its considerable cost only when you have a large, complex catalogue, multi-store or serious B2B needs, or customisation Shopify cannot express. We advise on this decision honestly, and we frequently recommend Shopify over the Magento build a merchant came to us expecting.
Why is our Magento store so slow?
Usually for fixable reasons rather than the platform being inherently broken: full-page caching (Varnish) not set up properly, Redis not handling cache and sessions, Elasticsearch misconfigured, indexers in the wrong mode, production compilation skipped, an under-provisioned database, or a stack of extensions each adding queries to every page. We profile to find the real bottleneck rather than guessing, then tune the code and infrastructure — a rescue is often far cheaper than a rebuild.
How much infrastructure does Magento really need?
More than owners expect. A serious store needs MySQL or MariaDB, Redis for cache and sessions, Elasticsearch or OpenSearch for search, and typically Varnish for full-page caching — these are load-bearing, not optional. It also needs someone competent applying security patches and watching performance. If that sounds like more than you want to own, that is itself a strong argument for a hosted platform like Shopify, and worth weighing before you commit.
Can we build a headless Magento storefront with React?
Yes. Magento exposes a GraphQL API and supports headless storefronts, including a React front end via Adobe’s PWA Studio or a custom build. It can give a faster, more app-like storefront and full control over the front-end experience — but it adds moving parts, cost and maintenance. We build headless only when the benefit is real; for many merchants the standard storefront, properly tuned, is the more sensible choice, and we will say which applies to you.
Building on Magento?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.