Magento & Adobe CommerceBUILD · UPGRADE · OPTIMISE
Magento does the hard catalogue jobs
and charges you in operations
Deep catalogues, multi-store, multi-source inventory and native B2B — few platforms match it. The bill arrives later, in hosting, build times, indexer behaviour and every upgrade — which is the part we plan for from the first sprint rather than the last.
- Magento 2 builds
- Adobe Commerce B2B
- Extension development
- Version upgrades
- Performance work
- Magento 2 builds and upgrades
- Migration from Magento 1 or another platform
- Indexers, caching and performance
- Catalogue
- EAV and indexers
- Attributes, flat tables, reindex strategy
- Caching
- Varnish and Redis
- Full page cache, sessions, blocks
- Search
- OpenSearch
- A hard requirement since 2.4
- B2B
- Company accounts
- Shared catalogues, quotes, POs
Built with
- PHP 8.3
- GraphQL
- Varnish & Redis
- OpenSearch
Eight kinds of work on Magento and Adobe Commerce
Some of this is new builds. Most of it, in practice, is upgrades, integrations, and making a store somebody else built run faster.
- Core Service
Magento 2 Store Builds
Setup shaped around the catalogue: attribute sets that match how you actually merchandise, a category structure and layered navigation that survive a large product count, and customer groups wired to the pricing rules you really sell on.
Magento engineering
- Migration
Migration & Version Upgrades
Magento 1 has been out of support for years, and 2.x keeps moving underneath you. We handle both — data migrated with a dry run first, extension compatibility assessed before the estimate, and a redirect map so old URLs keep their rankings.
Magento engineering
- Design
Theme & Storefront
The Luma stack, with its Knockout and RequireJS layers, is why plenty of Magento storefronts feel slow. We work within it where the budget says so, and move teams to PWA Studio or a lighter modern theme when the front end is what is holding the store back.
Magento engineering
- Extensions
Extension & Module Development
Custom modules built on plugins, observers and service contracts rather than rewriting core classes — because core rewrites are exactly what makes the next upgrade expensive. Third-party extensions get reviewed before they go in, not after they collide.
Magento engineering
- Integration
APIs & Integrations
REST and GraphQL endpoints, with message queues for the work that has no business running inside a web request. ERP, WMS, PIM, CRM, tax services and marketplaces — wired with retries and reconciliation instead of a nightly file and optimism.
Magento engineering
- Payments
Payments & Checkout
Gateway integrations that keep card data off your servers, 3-D Secure where the market requires it, saved cards, and payment on account for B2B. Checkout changes live in their own module so the next upgrade does not undo them.
Magento engineering
- Performance
Performance & Indexers
The usual suspects, in order: whether full page cache is actually being hit, indexers set to update on schedule, catalogue queries not losing a fight with EAV, Redis for sessions and cache, search tuned rather than left at defaults, and assets served from a CDN.
Magento engineering
- Support
Support & Upgrades
Security patches applied when Adobe issues them, PHP and dependency upgrades planned instead of deferred, monitoring on the order path, and someone who knows the store when cron quietly stops running and nobody notices for two days.
Magento engineering
When Magento is the right answer, and when it isn't
Magento rewards complexity. If the catalogue is small, the pricing rules are simple and nobody owns infrastructure, it will cost more than it returns — and we would rather say so at the start than three months in.
Where Magento Earns Its Cost
Large or awkward catalogues, several stores and languages under one admin, stock split across warehouses, and B2B where the buyer is a company rather than a person. If none of that describes you, a lighter platform will do the job for less.
Modules, Not Core Edits
Plugins, observers, service contracts and dependency injection exist so behaviour can change without touching core. Preference rewrites and patched core files are the single biggest reason a Magento upgrade turns into a project.
Modules
not core edits
The Running Cost, Named Up Front
Adobe Commerce is licensed; Magento Open Source is not. Either way it needs hosting that can carry Varnish, Redis, a search cluster and background workers. We put that in the estimate rather than leaving your infrastructure bill to find it.
Upgrades Kept Boring
Minor releases land regularly and every one of them meets your extension stack. We keep upgrades on a schedule, rehearse them against a copy of production data, and keep the gap between your code and core small enough that the next one is dull.
After Go-Live
Cron, queue consumers, indexers and search all fail quietly on Magento. Monitoring goes on those first, alongside the order path, so a problem surfaces before a customer is the one reporting it.
On-call
agreed per retainer
Running Magento is an operations commitment
as much as a build
Cron has to run. Indexers have to stay on schedule. Varnish has to be warm, the search cluster has to be up, and the queue consumers have to be supervised. None of it is hard; all of it has to be somebody's job.
- Four engagement models
- Staging mirrors production
- Patches on a schedule
Magento Specialists
A narrower hiring pool than general PHP. Ours have worked inside this codebase.
Visible Progress
A shared board, real tickets, and a written weekly update rather than a status call.
Measured, Not Guessed
Performance work starts from profiling and cache hit rates, not from a checklist.
Patched and Hardened
Security patches, admin access rules and two-factor as standard, not as an upsell.
The stack a Magento store actually runs on
Half of this list is modern; half is the legacy the Luma frontend still carries. Knowing which half you are working in is most of the job.
- PHPEverything server-side, on PHP 8
- MySQLEAV catalogue plus flat indexes
- ElasticsearchNot optional for catalogue search
- RedisSessions, cache and locks
- GraphQLWhat headless storefronts call
- REST APIsWhere ERP and PIM plug in
- jQueryStill there, under Luma
- KnockoutJSBinds the Luma checkout
- RequireJSLuma's module loading
- LESSLuma's stylesheet layer
- SymfonyDI and console components
- DockerLocal parity with production
- AWSWhere most of it ends up hosted
- MagentoOpen Source or Adobe Commerce
What Magento gives you and what it costs to run
Five things the platform is genuinely good at, each with the operational cost that comes attached to it.
Speed You Have to Earn
Magento can be quick, but never by default. Varnish in front, Redis behind, indexers running on schedule, and a frontend that is not shipping the entire Luma bundle to a phone. Those are decisions somebody has to make, not a setting to switch on.
FPChit rate is the metric
Catalogues That Keep Growing
Attribute sets, configurable and bundled products, per-website pricing and stock split across sources are part of the platform rather than bolted on. The ceiling is high. The price is that all of it is indexed, and indexing has to be managed.
MSImulti-source inventory
Security You Have to Keep Up With
Adobe publishes security patches on a regular cycle, and an unpatched Magento is a known target rather than a theoretical one. We apply them on a schedule, lock down the admin, enable two-factor, and keep card data off your servers entirely.
Patchesapplied on a schedule
B2B Without a Second Platform
Company accounts with buyer roles and spending limits, shared catalogues, negotiable quotes, requisition lists and purchase orders. On most platforms that is an extension stack to assemble and maintain; in Adobe Commerce it ships as part of the product.
B2Bin the platform itself
Total Cost of Ownership
A licence where it applies, hosting that can carry the whole stack, specialist rates for the people who work on it, and an upgrade budget every year. Magento is worth that when the catalogue and the rules justify it, and expensive when they do not.
TCObudgeted, not discovered
The sectors that keep choosing Magento
There is a pattern to it. Magento shows up where the catalogue is large, the pricing depends on who is buying, or stock lives in more than one place.
Retail & eCommerce
Multi-store, multi-currency retail under one admin, with catalogue price rules and promotions that stack in a defined order.
Healthcare
Medical supply and pharmacy catalogues with restricted products, batch and expiry tracking, and access rules — designed to support the privacy obligations that apply to you.
Education and Course Sales
Course catalogues, institutional purchase orders and subscription renewals, with entitlements granted the moment payment clears.
Banking & Finance
Product and application journeys where eligibility, disclosures and an audit trail of what was shown matter more than the cart.
Travel & Tourism
Gear and accessory retail alongside booking systems, where the store has to read availability from something it does not own.
Publishing and Media Brands
Digital goods, merchandise and subscriptions in one catalogue, with licence windows and regional availability applied per store view.
Manufacturing
Company accounts, contract price lists, volume breaks, quotes and requisition lists — the case Adobe Commerce B2B was built for.
Logistics and Distribution
Multi-source inventory with stock reservations, several carriers, and fulfilment split across warehouses without overselling either.
Fashion and Lifestyle Retail
Deep size and colour matrices, seasonal catalogue churn, and layered navigation that has to stay fast as attributes multiply.
Food & Grocery
High SKU counts, frequent price changes, subscriptions and delivery slots — a catalogue that changes faster than the reindex window.
How a Magento engagement starts — and how it scales
What we need from you, what we come back with, and how a team gets onto your codebase without breaking anything on the way in.
- Onboarding time
- 48–72 hrs
- Engagement models
- 4 options
- NDA and IP terms
- Signed first
- Team size
- Follows the phase
- 01
Send Us the Details
The version you are on, the extensions installed, roughly how many SKUs and orders you carry, and what is actually going wrong. If you can share admin or repository access, everything that follows gets shorter.
- 02
Technical Review
We look at the store rather than the brief: patch level, third-party extension list, core modifications, indexer and cron state, cache hit rates. Then we say what we would do first, and what we would leave alone.
- 03
Pick an Engagement Model
Fixed scope, time and materials, a dedicated team, or engineers embedded in yours. Each suits a different level of certainty about the work, and we will tell you which one fits what you have described.
- 04
Onboarding
Contracts, NDAs and access, then a local environment matching your production stack, a staging branch, and one small change shipped end to end — so the pipeline is proven before anything that matters goes through it.
- 05
Scale With the Phase
More people through a build or a migration, fewer in steady-state maintenance, more again ahead of a peak season. The team size follows the work rather than the contract.
Magento Development — FAQ
The questions people ask
before committing to Magento
Editions, cost, migrating off Magento 1, integrations, performance and what support looks like afterwards. Ask us directly.
08Questions answered
Magento Open Source or Adobe Commerce — which do we actually need?
Open Source costs nothing to licence and still gives you the catalogue engine, multi-store, multi-source inventory and the module system. Adobe Commerce adds the B2B module — company accounts, shared catalogues, negotiable quotes, requisition lists — plus content staging, customer segments and vendor support, in exchange for a licence fee that scales with your revenue. The honest test is whether you would otherwise build or buy those features. If account-based B2B buying is central to how you sell, Adobe Commerce usually works out cheaper than assembling the same thing from extensions. If it is not, Open Source with a small number of well-chosen modules is normally the better deal.What does Magento work cost?
We do not publish a rate card, because the same brief costs wildly different amounts depending on the store behind it. The drivers are consistent: how many third-party extensions are installed and how well behaved they are, whether core has been modified, how far behind the current release you have fallen, and how much of the work is catalogue data rather than code. After the technical review you get a range with the assumptions written next to it, and we revise it in the open when one of them turns out to be wrong.How long does a Magento build take?
Longer than the same store on a hosted platform, and the difference is mostly environment setup, integration and testing rather than page building. A straightforward catalogue with standard payments and shipping runs to a few months. Multi-store, B2B, an ERP integration and a data migration push it well beyond that. We work in two-week cycles so you see the catalogue, then the cart, then checkout, instead of waiting for a single demo at the end.We are still on Magento 1. What does moving to Magento 2 involve?
It is a rebuild, not an upgrade — the two share a name and not much else. Data migrates: products, customers, orders, CMS content. Code does not. Every custom module and every Magento 1 extension needs a Magento 2 equivalent, written or bought, and that assessment is what really determines the estimate. The theme is rebuilt. URLs are mapped so rankings survive. We run the migration repeatedly against production data before the real one, so cutover day is a rehearsal rather than an experiment.Can you integrate Magento with our ERP or CRM?
Yes, and after the catalogue it is usually the largest single piece of work. Magento exposes REST and GraphQL APIs and supports message queues for anything that has no business blocking a web request. The questions that decide the design are the boring ones: which system owns the master record for a product, a price and a stock level; whether updates travel on an event or a schedule; and what happens while the other system is down. We build with retries, dead-letter handling and reconciliation rather than assuming both ends are always up.How do you handle Magento security and PCI scope?
Adobe issues security patches on a regular cadence, and Magento gets targeted precisely because unpatched instances are so common. We keep the patch level current, restrict the admin path and require two-factor on it, put a web application firewall in front, and use gateway-hosted fields so card data never reaches your servers — which keeps PCI scope as narrow as it can be. Systems are built to support your PCI DSS obligations; the scope of that work is agreed per engagement, and certification is something an assessor grants, not something we can claim on your behalf.Do you provide support after launch?
Yes, on a retainer with agreed response times and an agreed scope. In practice it covers security patches, minor version upgrades, extension compatibility, and monitoring on the things that fail silently — cron, queue consumers, indexers and the order path — alongside a backlog of changes. Whether that is a few hours a month or a standing team depends on how much the store changes.Our Magento store is slow. Where do you start?
With measurement rather than a checklist. Usually: whether full page cache is being hit at all or bypassed by blocks that should be private, whether indexers are set to update on schedule or thrashing on every save, how many extensions are adding layout XML and JavaScript to every page, the state of the search cluster, and what the frontend is actually shipping to a phone. Most of the largest wins are in configuration and caching rather than in code, and we tell you which is which before quoting the work.
Tell us what you're
trying to build
The problem, who it's for, and where you are now. That's enough for us to come back with something useful.
hello@aryavos.com
HQ
Noida, India & New York, USA
What happens after you send it
A developer reads it, not an auto-responder. Expect questions about scope and constraints first, then a suggested way to start.