Published rates for hiring an ecommerce consultant run from roughly $25 to $300 per hour, according to BigCommerce’s guide to hiring one. A spread that wide is informative before any conversation starts, because the job title constrains very little about what eventually lands on the desk. One supplier delivers a written diagnosis and a prioritised list. Another delivers a similar list with the changes already live on the store.
Which of those a business needs depends less on the supplier market and more on which constraint is currently binding. Where a retailer genuinely cannot explain why conversion has flattened, or whether the current platform can carry the next two years, an ecommerce consultant is often the faster and cheaper route. Where the store already holds a backlog of agreed improvements and nobody with the time, skills or access to build them, a further diagnosis tends to lengthen the queue rather than shorten it.
What an Ecommerce Consultant Actually Delivers
BigCommerce describes the role plainly: an ecommerce consultant is “a professional that can offer firsthand knowledge and advice surrounding ecommerce”. The output of an ecommerce consultant’s work is judgment, expressed as an audit, a roadmap, a set of prioritised hypotheses or a platform recommendation. The engagement is complete when the thinking has been transferred, not when the store has changed.
That boundary is usually explicit in how advisory work is packaged. HubSpot’s technical consulting projects are described as work in which a dedicated consultant will “work with you to understand the scope of your technical project, design a solution, and leverage proven best practices to guide your team through the implementation”. The verb is guide. A team on the client side is assumed to exist, to be available, and to be capable of building what was designed.
Where that assumption holds, the advisory model has real advantages. BigCommerce lists three: it “offers unbiased feedback”, it “allows you to focus on core business needs”, and it “saves you time and money”. The first of those is the most underrated. A specialist with no stake in the resulting build has no commercial reason to recommend a rebuild over a fix, or a migration over a configuration change. When the decision on the table is large and mostly irreversible, that independence is worth paying for on its own.
The same page is candid about the limitations, which include less continuity than a full-time employee offers, fees that can be high relative to the hours involved, and reduced control over how the work is carried out. Those constraints matter differently depending on the engagement. For a two-week platform assessment, limited continuity is irrelevant. For an optimisation programme intended to run for a year, it becomes the main risk, because each new cycle of work starts by rebuilding context that nobody retained.
What Changes When the Same Team Implements the Recommendations
When advice and delivery sit with one supplier, the most visible difference is not speed. It is that the recommendation and the implementation constraint are discovered at the same time. A proposal to simplify the delivery step is written by people who already know how that step is built, which apps touch it, and what the theme will tolerate. Recommendations that cannot survive contact with the codebase tend not to reach the document in the first place.
The second difference is what accountability attaches to. An advisory engagement is judged on the quality of the reasoning. A combined engagement can be judged on whether the change went live, held up across devices and produced a measurable movement in the metric it was supposed to affect. That is a harder standard, and it is the reason some suppliers prefer to stop at the recommendation.
The trade-off is equally real. A partner that both advises and builds has a commercial interest in the volume of building it recommends. That interest does not make the advice dishonest, but it does mean the option of doing nothing, or of solving the problem through a process change rather than a development ticket, may receive less airtime than it deserves. The practical defence is to insist that every recommendation is accompanied by the smallest version of the change that would test it, and to ask explicitly what the cheapest alternative was and why it was rejected.
There is also a concentration risk. A single supplier holding the diagnosis, the roadmap, the codebase and the analytics configuration is efficient until the relationship ends. That risk is reduced by contract terms rather than by supplier type.
Ecommerce Consultant vs Implementation Team: A Side-by-Side View
| Criterion | Advisory-only ecommerce consultant | Team that advises and implements | Consultant plus separate build supplier |
|---|---|---|---|
| What is delivered | Diagnosis, roadmap, prioritised recommendations | Recommendations plus the changes deployed | Recommendations, then a second contract to build them |
| Independence of the advice | Strongest, no stake in the resulting build | Weaker, the adviser may benefit from the work recommended | Strong on advice, weaker on who verifies the build |
| Internal resource required | High, an internal owner and delivery capacity | Low to moderate, mainly decisions and approvals | Highest, someone must manage two suppliers |
| Time from finding to live change | Depends entirely on internal capacity | Usually shortest, one backlog and one queue | Longest, a handover and a re-scoping sit in between |
| Cost structure | Hourly or fixed fee, typically bounded | Retainer or programme fee, larger and ongoing | Two fees, often with duplicated discovery |
| Ownership of the outcome | Transfers to the client at handover | Shared, and measurable against agreed metrics | Divided, and easy to leave unassigned |
| Main failure mode | The report is read and never actioned | Work continues without anyone re-testing the direction | Each supplier attributes a poor result to the other |
| Best suited to | One-off, high-stakes decisions | Continuous improvement with thin internal capacity | Regulated or complex builds needing an independent check |
The table is a starting point rather than a verdict, because the rows are not equally weighted for every business. A retailer choosing between Adobe Commerce and a headless build is making a decision it will live with for years, and the independence row should dominate. A retailer with a stable platform and eighteen agreed improvements waiting on developer time should weight the third and fourth rows far more heavily, because in that situation the quality of the advice is not what is limiting the result.
The third column deserves more attention than it usually gets. Separating the adviser from the builder preserves independence while still getting the work done, and it is a sensible structure when the build is large or when an outside check on delivery quality has genuine value. Its weakness is coordination. Two suppliers means two discovery phases, two sets of assumptions, and a gap in the middle where responsibility for the outcome can go unclaimed.
Why Sound Recommendations Stall Before They Reach the Store
A recommendation that never ships is not usually blocked by disagreement. It is blocked by the unglamorous work sitting between a sentence in a document and a tested change in production. Part of that work is organisational, and part of it is set by the platform itself.
The Platform Decides How Much Can Be Done Without a Developer
How far a non-technical team can carry a recommendation varies significantly by platform, which is why the question of who implements is partly a technical question rather than a purely commercial one.
On Shopify, the boundary is stated in the documentation. Shopify’s guidance on editing theme code advises merchants to “Edit the code for a theme only if you know HTML and CSS, and have a basic understanding of Liquid”, and warns that “If changes that you’ve made to a theme’s code are incompatible with a theme update, then all your code changes are removed in the updated copy”. It also suggests considering a Shopify Partner for merchants who want custom features without web development experience. A recommendation that requires template changes therefore carries an ongoing maintenance cost, not only a one-off build cost.
WooCommerce documents a similar boundary from the other direction. Its template structure documentation warns that “Editing files directly in a plugin or a parent theme creates the risk of causing errors that could bring a site to a grinding halt”, and that such changes “will disappear when the plugin or theme updates itself”. The supported route is a child theme override, and the documentation is explicit about the consequence: “WooCommerce core templates will update, but your custom overrides will not”. A store with many overrides accumulates a quiet obligation to review them after updates, and that obligation needs an owner.
Not every change is developer work, and the platform can widen what a business team handles alone. Adobe’s documentation on content staging in Adobe Commerce states that the feature “gives your business team the ability to easily create, preview, and schedule a wide range of content updates for your store directly from the Admin”, and notes that it is not available in Magento Open Source. Two stores on related platforms can therefore need quite different amounts of external delivery support for the same list of recommendations.
Signs the Constraint Is Execution Rather Than Knowledge
Before commissioning more analysis, it is worth checking whether the business is short of answers or short of delivery. The following patterns often point to the second:
- A previous audit is still largely unimplemented. If the recommendations from an earlier engagement are recognisable and still open, a new document is unlikely to change the outcome. The question worth asking is what stopped the first set, because the same obstacle will usually stop the second.
- Agreed changes are repeatedly deferred by operational work. Growth improvements rarely feel as urgent as a payment failure or a campaign launch, so they lose the queue consistently rather than occasionally. This is a capacity and priority problem rather than a knowledge problem.
- Nobody can say who signs off a change to the buying journey. Where marketing, the developer and the platform owner each hold part of the decision, work can circulate without anyone being able to stop it or start it.
- Estimates for small changes keep growing after work begins. This often indicates that recommendations were written without visibility of the codebase, a symptom of the handover gap rather than of poor development.
- Test results are inconclusive because changes were only partly rolled out. A variant that reached desktop but not mobile can look like a failed hypothesis when it is really an incomplete implementation.
Where several of these apply, buying more advice may not address the actual cause. Where none of them apply and the team simply disagrees about direction, the opposite is true, and an independent view is likely to be the better purchase. A closely related question, whether one specialist or a broader group is the right answer, is handled in a separate article on choosing between a single CRO hire and a wider external team.
Both Models Should Start From the Same Evidence
The diagnostic method is not what separates the two arrangements, and it is a mistake to assume that an implementation partner works less analytically. Microsoft Clarity’s documentation on funnels describes them as “an ordered group of actions a user takes before converting or completing a goal”, useful because they “show how users progress through a specific flow and how many sessions convert or drop off between steps”, which “lets you identify specific pages or areas where users struggle the most”. Recordings and heatmaps can then be reviewed at each step for detail.
Both supplier types should be able to show that work. What differs is what happens once the priority list exists. An advisory engagement hands the list over. A delivery-capable engagement commits to a sequence, builds the first item, measures it and revises the rest of the list based on what the first change produced. The second pattern is only better when the first item actually gets built, which returns the decision to internal capacity rather than to analytical quality.
Key takeaway: the choice is rarely about who produces the better analysis. It is about where the work reliably stops. If a business can name the person who will build, test and release the next agreed change, advice alone may be sufficient. If it cannot, the engagement needs to include delivery or the recommendations will sit where the last ones did.
When Hiring an Ecommerce Consultant Is the Better Choice
Advisory-only work tends to be the stronger purchase in four situations.
Choose it when the decision is large, infrequent and expensive to reverse. Platform selection, replatforming scope, whether to separate B2B and B2C, and whether to rebuild or optimise all fall into this group. In each case the value sits in the judgment rather than in the hours, and independence from the eventual build is worth protecting. Our ecommerce strategy consulting work is structured this way for exactly that reason, covering business analysis, growth constraints, technology and a prioritised roadmap without assuming who will deliver it.
Choose it when internal delivery capacity already exists and is underused. A store with an in-house developer and a product owner may only be missing direction. Buying delivery it already has would be an expensive way to solve a planning problem.
Choose it when an existing supplier’s work needs an independent review. Asking the incumbent to assess its own architecture or its own testing programme rarely produces an uncomfortable answer, and an ecommerce consultant with no interest in the remediation budget is more likely to give one.
Choose it, finally, when the budget available is genuinely small. A bounded diagnostic such as an ecommerce technical audit produces a prioritised list of fixes for a fraction of the cost of an ongoing programme, and it leaves the business free to decide later who should act on it. Starting small is often the more rational first step, even when a longer engagement would eventually be justified.
When a Team That Implements Fits Better
The combined model earns its cost when the bottleneck sits after the decision rather than before it. The clearest case is a store with traffic, a stable platform and a list of agreed improvements that has not moved in several months. Nothing in that situation is improved by more analysis.
It also fits when the work is genuinely cross-disciplinary. A change to the delivery step can involve research, design, front-end development, a change to shipping configuration and an analytics update. Coordinating five specialists across two suppliers consumes internal management time that a smaller business may not have, and the coordination cost is frequently underestimated at the point of signing.
A third case is where learning needs to compound. Testing programmes and optimisation work produce most of their value over successive cycles, because each result informs the next hypothesis. That compounding depends on someone retaining context between cycles, which is precisely what an advisory engagement with limited continuity may struggle to provide. Where the store has no internal owner for growth at all, the more fundamental question of who owns ecommerce growth should be settled before either supplier type is engaged.
It is worth being clear about when the combined model is the weaker option. Where a business needs one honest answer to one question, an ongoing programme is an inefficient way to buy it. Where internal teams are capable but poorly directed, an implementation partner may quietly absorb work that would build more durable capability if kept in-house.
Five Practical Tests That Usually Settle the Question
- Count what is already agreed but unbuilt. List every improvement the business has accepted in principle and not shipped, with the date it was agreed. A long list with old dates points towards delivery; a short list with recent dates points towards advice. It measures the business rather than the pitch, which is why it is more reliable than any supplier’s discovery call.
- Name the person who would build the next change. Not the team, the person, with an estimate of the hours they could give it this month. If that question has no confident answer, an advisory engagement is being bought on an assumption the business cannot support.
- Write the scope before comparing suppliers. Shopify’s guidance on hiring an ecommerce expert recommends a scope covering the “Project objective and requirements”, the “Project deliverables or the final outputs”, “In-scope and out-of-scope tasks”, and “Project constraints like budget or time”. Drafting this first exposes whether the business is buying a document or a change, and it is common for that to become clear only once someone has to write the deliverable down.
- Ask each supplier what happens on the day after the report is delivered. An advisory supplier should describe a handover, a named internal owner and a review point. A delivery supplier should describe the first change it would build, how long it would take and how the result would be read. Vague answers on either side are the signal, not the model itself.
- Check the claims against the evidence offered. Shopify’s hiring guidance suggests reading “the two- and three-star reviews, not only the five-star ones”, and treats a supplier “guaranteeing you a 10 times ROI in two weeks” as a warning sign. Specific, qualified claims about past work are more informative than confident ones, and this test applies equally to consultants and to implementation partners.
These five tests cost very little and can be run before any proposal is requested. In most cases two or three of them will point consistently in one direction, and where they conflict, the conflict itself is usually the finding worth acting on.
Mistakes That Undermine Either Arrangement
- Buying analysis to avoid a decision. Where the direction is broadly known and contested internally, a report can become a way of postponing the argument. The consequence is a second engagement twelve months later addressing the same issue with a larger backlog behind it.
- Leaving out-of-scope work undefined. Both Shopify’s and HubSpot’s guidance on engaging external help stress writing down what is not included. Without that line, advisory engagements drift into unpaid delivery and delivery engagements drift into unpaid strategy, and the relationship sours over work nobody priced.
- Judging an implementation partner on output volume. Counting tickets closed rewards activity rather than effect. A better standard is whether the agreed measures moved, and whether the partner can explain the ones that did not.
- Handing over accounts and access instead of granting it. Transferring ownership of the store admin, analytics property or code repository to a supplier is convenient and creates an avoidable dependency. Access can be granted and revoked; ownership is harder to recover.
- Treating the roadmap as fixed once it is written. A prioritised list produced in January reflects what was known in January. Where an engagement continues for months without revisiting the order, later items may be built for reasons that no longer hold.
What Two Verified Projects Suggest
Our work with Profcentrs.lv is published under the heading of why a “pretty” website was not enough. The case study describes an omnichannel disconnect in which “Stock levels in physical stores didn’t match what customers saw online”, alongside “Manual inventory updates created delays and customer-facing errors”. Those are not problems a design recommendation resolves. The published outcome followed from merging stores, ERP, POS and WooCommerce into one system, and the page records “Zero inventory mismatches” and a returning customer rate increased by 71%. The lesson relevant here is about diagnosis depth: a surface-level review would have proposed a redesign, and the redesign would not have removed the cause.
The A.M.Ozoli project shows the combined shape more directly. The published solution list includes operational strategy consulting alongside a custom B2B pricing system and sales workflow automation, with the published result for time to produce a quote given as “~2h” before and “<30sec” after. Advice and build were the same engagement, which is what allowed the pricing logic to be designed and implemented as one piece of work rather than specified once and interpreted twice.
Internal expert input required: add a verified observation on how many recommendations from a typical WD Market audit reach production within six months when the client implements internally, compared with when delivery is included in the engagement.
Matching the Engagement to the Binding Constraint
The decision is not really a choice between two supplier categories. It is a judgment about where the work currently stops. Businesses that can name the person who will build the next agreed change, and the hours they have available, can buy advice on its own and expect it to be used. Businesses that cannot are buying a document, and the evidence for that is usually sitting in the previous audit.
Independence, cost and the platform’s own constraints all pull on the answer, which is why the five tests above are more useful than a general preference. Start by counting what has been agreed and not built. That single number tends to indicate whether the next purchase should be an ecommerce consultant, a delivery partner, or a bounded diagnostic that keeps the decision open a little longer.
Turning a Recommendation Into a Shipped Change
If the backlog is the problem rather than the diagnosis, the practical next step is a conversation about delivery capacity. Our external ecommerce growth team works as a monthly programme covering analytics review, an optimisation plan, testing, implementation and reporting, so that recommendations and the changes they describe belong to the same queue. Where the direction is the open question instead, the strategy engagement described earlier is the more sensible starting point, and a technical audit is the smallest useful version of either.
To discuss which of the three fits your situation, including a review of what has already been recommended and not built, get in touch with our team. Readers who would rather assess our thinking first can follow WD Market on LinkedIn, where these supplier and delivery questions come up regularly in shorter form.
Frequently Asked Questions
How much does an ecommerce consultant cost?
BigCommerce publishes a range of roughly $25 to $300 per hour, which reflects how much the title covers rather than a going rate. Pricing usually tracks the scope of the decision rather than the hours involved, so a short platform assessment by an experienced specialist can cost more per hour than a longer piece of routine analysis. Fixed-fee engagements are common for audits, where the deliverable is well defined in advance, and hourly arrangements are more usual for open-ended advisory support.
Can an ecommerce consultant implement changes as well?
Some can, and many do not. Advisory packages are frequently written around guiding an existing internal team through the build rather than performing it, which is how HubSpot describes its own technical consulting projects. The reliable way to establish this is to ask who writes and deploys the code, who tests it across devices, and who is responsible if a release causes a problem. If those three answers point at the client, the engagement is advisory regardless of what it is called.
Is it cheaper to hire an ecommerce consultant than an agency?
The invoice is usually smaller, but that is not the same as the total cost. An advisory fee buys a document; the cost of acting on it sits elsewhere, either in internal salaries or in a second supplier contract. A comparison is only meaningful once the delivery cost is included on both sides. Where internal capacity genuinely exists and is idle, the consultant route is often cheaper overall. Where it does not, the saving can be nominal.
What should be in the contract for either type of engagement?
At minimum: the objective, the specific deliverables, what is explicitly out of scope, the timeline with review points, and how the result will be judged. Both Shopify and HubSpot emphasise writing down the exclusions, because that is where disagreement tends to originate. For delivery engagements, add who holds ownership of accounts and code, and what happens to work in progress if the arrangement ends.
Does the platform affect which model we need?
It can change the balance noticeably. Adobe Commerce allows business teams to schedule and preview many content updates from the Admin without developer involvement, a capability its documentation notes is absent from Magento Open Source. Shopify and WooCommerce both document that theme and template changes require development skill and ongoing maintenance after updates. The more of the recommended work that requires code, the more likely an arrangement including delivery becomes the practical option.
We already have an audit that was never implemented. What now?
Begin by identifying what stopped it, because commissioning a replacement rarely changes the outcome on its own. Common causes include no named owner, no protected capacity, or recommendations written without knowledge of the codebase and therefore larger in practice than they appeared on paper. Once the cause is clear, the existing audit can often be revalidated and sequenced rather than repeated, which is usually faster and less expensive than starting the analysis again.
How do we keep an implementation partner honest about scope?
Require that each recommendation arrives with the smallest version that would test it, and ask which cheaper alternative was considered and why it was set aside. Keep ownership of analytics, the store admin and the repository so that the evidence is readable without the supplier. Agree in advance the handful of measures the work will be judged on, and review the order of the roadmap on a fixed cycle rather than only when something goes wrong.