Yuvraj Raulji | Magento consulting
The expensive Magento decisions are made in the first fortnight, by whoever configured the first storefront, and they are close to irreversible once real data is in. Consulting is the work of making those decisions deliberately: attribute sets, store and website scope, price scope, where the system of record sits, and whether Magento is the right platform at all.
Direct answer
Magento consulting is independent advice on the Magento decisions that are hard to reverse: whether Magento is the right platform for the business at all, how the catalogue data model should be structured, which system is the source of truth for stock and price, how many storefronts the scope model actually needs, and what order the work should happen in. It is judgement about trade-offs rather than the delivery of a build, and on Magento specifically it matters more than on a hosted platform, because Magento hands you the data model and expects you to have an opinion about it.
Best suited for
- Choosing between Magento, Adobe Commerce and a hosted platform
- Inheriting a Magento build nobody can explain
- Planning a second, third or fourth storefront
- Technical due diligence before an acquisition or an investment
What this page is not
This page is the thinking, not the delivery. If the decision is already made and the job is moving a live store onto Magento, that is a different piece of work with a different shape.
Magento migration, for a store already committed to the move
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
Nobody can say whether Magento is the right platform
What it costs
The debate runs on preference and on whichever agency spoke last. Magento is genuinely the wrong answer for most catalogues, and the cost of finding that out after the build is a second replatform inside three years.
The attribute set was designed in a hurry, two years ago
What it costs
Every new product type needs a workaround, layered navigation returns filters nobody can use, and the fix gets more expensive with every SKU added. This is the single most common inherited Magento problem and it is a data model problem, not a theme problem.
Two systems both think they own the price
What it costs
Magento and the ERP disagree, and which one is right depends on the day. Support absorbs it as a manual correction rota, and the correction rota is treated as normal until someone counts the hours.
The roadmap is a list of features with no order
What it costs
Work gets sequenced by whoever asked most recently rather than by what unblocks the next thing. On Magento this shows up as a theme rebuild scheduled before the scope model is settled, which is the wrong way round and has to be paid for twice.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Understand the business
What the pricing rules genuinely are, who approves what, where the margin actually sits, and which parts of the current complexity are the business rather than an accident of the last system. This is the part that gets skipped, and it is the part the data model is built out of.
Read the current state
The attribute sets, the scope model, the extension list, the integration boundary and the deployment path. On an inherited build this usually takes a week and produces a document the team has never had, which on its own changes how the next decision gets made.
Test the platform decision honestly
Including the answer where Magento is the wrong choice. A catalogue that fits a hosted platform should be on one, and saying so is the point of hiring someone independent rather than an agency that only builds one thing.
Design the data model
Attribute sets, store and website scope, price scope and inventory sources, decided against the business model rather than copied from the last project. These are close to irreversible once real orders exist, which is why they come before anything visual.
Sequence the work
What has to happen first because everything else depends on it, what can wait, and what should not be built at all. The output is an order of work with the reasoning attached, not a feature list.
Scope
Platform decisions
Magento against hosted platformsMagento 2 against Adobe CommerceBuild against buyHeadless against Luma
Data model
Attribute set designStore and website scopePrice and inventory scopeCategory and taxonomy structure
Review
Inherited build auditExtension and customisation reviewIntegration boundary reviewTechnical due diligence
Planning
Phasing and sequencingEffort and risk shapeTeam and ownership modelSecond opinion on a proposal
Proof
Both are Magento 2 builds where the scope and workflow decisions on this page were the ones that mattered.
Magento 2 · Marketplace
Multi-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Custom platform · B2B
Procurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Outcome
12+
Multi-store Magento 2 platforms delivered
Across catalogues reaching 500K+ SKUs and 1M+ monthly users. The scope and attribute decisions on this page are the ones those platforms were built on, and the ones that were expensive to get wrong.
Where this came from
From the employment record: multi-store Magento 2 delivery across B2B, B2C and marketplace models since 2016.
The decision not to build
Some of these conversations end with a recommendation against the project, or against Magento. That is a legitimate outcome and it is cheaper than the alternative, which is why the engagement is priced as advice rather than as a deposit against a build.
There is no measured outcome attached to advice on its own, and inventing one would be dishonest. The figure above is a delivery record, and it is here because it is what the advice is drawn from rather than a result the advice produced.
Questions
- What does a Magento consulting engagement actually produce?
- A written account of the current state, the decisions that need making with a recommendation on each, and an order of work. On an inherited platform the current-state document is usually the part with the most immediate value, because it is the first time the whole system has been described in one place.
- Is Magento worth it for a catalogue of a few hundred products?
- Usually not. Magento earns its operating cost when the catalogue, the pricing logic or the approval structure is genuinely complicated. A few hundred simple products on a single storefront will run better and cheaper on a hosted platform, and the honest recommendation is to say so.
- What is the difference between Magento 2 and Adobe Commerce?
- Magento 2 Open Source and Adobe Commerce share the same core. Adobe Commerce adds the commercial B2B module, page builder, customer segmentation and Adobe support, and it carries a licence fee scaled to revenue. The decision is rarely about features and almost always about whether the B2B module replaces work you would otherwise build and maintain yourself.
- Can you review a proposal from another agency?
- Yes, and it is a common reason people get in touch. The useful part is usually not the price. It is whether the proposal has an opinion about the data model, whether the phasing puts the irreversible decisions early, and what it is quietly leaving out.
- Do you take the build as well?
- The advice stands on its own and is not a route into a delivery contract. That independence is the reason a recommendation against Magento, or against the project, is possible at all.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.