One consultant, not a team to manage.

Direct answer

Before you ask

• No dedicated resources by the month

  Work is scoped by the problem, not sold as headcount. Where a team is genuinely needed, saying so is part of the advice rather than a service on offer.

• No proposal for a project you do not need

  A real share of these conversations end with a smaller piece of work, or none. That is only possible because nothing here depends on selling the build.

• No account layer

  You talk to the person doing the work. That is the main practical difference between this and the alternative, and it is the reason the first call is useful rather than exploratory.

Engagement

1. 01

   Advisory

   The deliverable is a decision, with the reasoning attached.

   Platform selection, architecture review, technical due diligence, or a second opinion on a proposal. Typically a short engagement producing 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 often the part with the most immediate value, because it is the first time the whole system has been described in one place.

   Fits when

   • The decision is expensive and hard to reverse
   • Nobody internally has made this call before
   • You are holding a proposal you cannot evaluate
   • A platform was inherited and nobody can explain it
2. 02

   A defined piece of work

   A scope, a shape and an end.

   A migration, a performance programme, an integration boundary, an upgrade, a build. Scoped after the problem is understood rather than before, because a scope written against a symptom is how projects end up delivering the wrong thing accurately. The service pages under each platform describe what these actually look like.

   Fits when

   • The decision is already made and the work is real
   • Something has to be delivered by a date
   • The internal team can hold it afterwards
   • You want the scope argued with before it is agreed
3. 03

   Ongoing

   Somebody owns the platform.

   Patch cadence, release discipline, monitoring, and the technical ownership most platforms are missing rather than the ticket queue most retainers sell. The stated goal is to hand it back: documentation and enough transfer that the internal team can hold it. An arrangement that makes itself indispensable is a commercial arrangement rather than a technical one.

   Fits when

   • Deploys depend on one person being available
   • Updates are deferred because the last one broke something
   • Failures are reported by customers first
   • There is no in-house owner and no plan to hire one

How it starts

1. 01

   Describe the problem

   Not the project. What is actually in front of you, what it is costing, and what has already been tried. The most useful first message is the one that describes a symptom rather than requests a technology.

2. 02

   A 30-minute conversation

   The constraint you are hitting, the decision behind it, and what would have to be true for each option to be right. Free, and it occasionally ends with a recommendation to do nothing.

3. 03

   A shape, in writing

   Which of the three models fits, what it would cover, and what it deliberately excludes. If none of them fits, that is said rather than worked around.

4. 04

   The work, with the reasoning visible

   Decisions documented as they are made, so the thinking survives the engagement. This is what makes it possible to hand the platform back rather than leaving a dependency behind.

The record

• Nine years

  Measured from the first Magento role in June 2016, which is where the professional record starts. Earlier websites are not counted.

• Remote, from IST

  Engagements run remotely with structured written communication. Time zone overlap is agreed at the start rather than assumed.

• Direct, always

  You work with the person doing the work. There is no account manager and nobody else to brief.

• Independent

  No platform partnership, no reseller margin and no incentive to recommend one technology over another. It is why a recommendation against a project is possible.

Platforms

• Hire Magento expertise

  On Magento this most often starts as a performance problem or an upgrade nobody wants to run, and turns out to be a data model or an extension decision underneath.

• Hire Shopify expertise

  On Shopify this usually begins as a speed or conversion problem and resolves into an app list nobody has owned and a theme nobody wants to touch.

• Hire WooCommerce expertise

  On WooCommerce this usually starts with a slow checkout or a scary update, and the answer is a plugin decision rather than a rebuild.

• Hire WordPress expertise

  On WordPress this usually arrives as a rebuild request and turns out to be a content model, a plugin cull and a caching fix, at a fraction of the cost.

• Hire headless commerce expertise

  On headless this usually starts as a performance brief and resolves into a question about whether your release cycle is genuinely the bottleneck.

• Hire AI commerce expertise

  This usually starts as an AI request and becomes a data quality question, because a model amplifies the catalogue it is given.

• Hire AI search expertise

  This usually starts as a search complaint and turns into a catalogue attribute problem, which is a merchandising decision rather than a search one.

• Hire AI automation expertise

  This usually starts as an automation request and begins with a process redesign, because the first version worth trusting is deterministic rather than generative.

• Hire digital transformation expertise

  This usually arrives as a replatform and becomes a phasing question, because trading has to continue while the system changes underneath it.

Questions

01

Can I hire you as a developer rather than a consultant?

The work often is development, so the distinction matters less than it sounds. What does not happen is being placed into a team as a resource against a specification somebody else wrote, because the value here is in arguing with the specification before it is built. If you need hands on a defined backlog, an agency or a contractor is a better fit and cheaper.

02

Do you work with agencies, or only direct?

Both. Agencies engage this most often for a second opinion on an architecture, a platform decision they want checked independently, or a specialist piece of Magento work. The arrangement is the same either way, and the advice does not change because of who is paying for it.

03

What does it cost?

It depends on which of the three shapes fits and what the work turns out to be, so a number before the first conversation would be a guess. What can be said is that advisory engagements are short and priced as advice rather than as a deposit against a build, which is what makes a recommendation against the build possible.

04

How quickly can you start?

Ask, because it depends on what is already running. What is worth knowing is that the first conversation does not wait on availability: if the timing does not work, it is better to say so after understanding the problem than to hold the slot and find out later it was the wrong problem.

05

Do you build the whole thing, or advise and hand over?

Either, and the honest answer depends on your team. Where there is an internal team, the better outcome is usually architecture and the difficult parts, with the rest handed over. Where there is not, a defined build makes more sense. The one arrangement deliberately avoided is becoming a permanent dependency nobody planned for.

06

What if the platform I am on is not one you work with?

Then that is said in the first conversation. The platforms on this site are the ones with a real delivery record behind them, and taking work on a platform outside that would mean charging you to learn it.