Most platforms can display prices in several currencies. Far fewer handle genuinely different markets well.

What to evaluate

1. Catalog inheritance — can a market override price, availability and content without duplicating the product?
2. Tax — per-market tax rules and providers, including price display rules that differ by region.
3. Payments — market-specific providers, not just currency conversion at checkout.
4. Content and language — translation workflow and how much of it the merchandising team can do unaided.
5. Admin overhead — how long it takes to launch market number seven once six exist.

A practical test

During evaluation, ask the vendor or partner to add a new market in a sandbox while you watch. The time it takes and the number of screens involved will tell you what the next three years of operations look like.

Headless solves specific problems well and creates new ones in exchange. The decision should turn on whether you have those specific problems.

Good reasons

• Multiple front ends — web, native app, kiosk, marketplace — sharing one commerce backend.
• A content-led experience that the platform’s templating genuinely cannot express.
• A front-end team that needs to deploy without waiting on backend releases.

What you take on

You now own the storefront entirely: SEO, rendering strategy, caching, accessibility, analytics wiring, and every piece of functionality the platform used to provide for free. Budget for a permanent front-end team, not a one-off build.

The middle path

Many retailers get most of the benefit from selective decoupling — a headless approach for one high-value journey, the platform’s own storefront for the rest. It is less satisfying architecturally and usually the better commercial decision.

The standard optimisation playbook assumes high traffic and a same-session purchase. B2B has neither.

What works instead

• Session recordings and user interviews with actual buyers — a dozen well-chosen conversations usually beat an underpowered test.
• Funnel instrumentation so you can see where multi-session journeys break down.
• Friction removal in reorder, search by SKU, and account setup, which are where B2B revenue actually lives.
• Sequential testing or holdout groups where sample size will not support a clean split test.

Measure the right thing

Optimising for add-to-cart rate on a site where half the revenue comes from quote requests will make the numbers look better and change nothing. Agree the primary metric before any work starts, and make sure it connects to revenue.

The purpose of a B2B channel is usually to serve existing accounts more cheaply and more reliably, not to acquire new traffic. Measure that.

Metrics worth a dashboard

1. Self-service adoption — percentage of orders placed online rather than by phone or email.
2. Reorder rate — how often accounts come back without prompting.
3. AOV by account segment — whether the channel grows baskets or just moves them.
4. Quote-to-order conversion and the time between the two.
5. Cost to serve — support contacts per order, which is where the business case usually lives.

Metrics to stop reporting

Bounce rate, time on site and raw sessions. In a channel where a buyer logs in, reorders in ninety seconds and leaves, a low time on site is a success.

Performance work has a reliable order of operations, and skipping to a rebuild usually means the same problems reappear on new code.

Work in this order

1. Measure with field data — real user monitoring, not a single lab score on a fast connection.
2. Images — correct formats, correct dimensions, lazy loading below the fold. Usually the single biggest win.
3. Third-party scripts — audit every tag. Most sites carry several nobody can account for.
4. Render-blocking CSS and JS — defer what is not needed for first paint.
5. Server and cache — full-page caching, query optimisation, and a CDN configured for your catalog.

Set a target that means something

Pick a threshold tied to revenue rather than a score out of a hundred, and track it per template — category pages, product pages and checkout behave very differently and average badly.

Stalled projects usually share the same shape: scope was underestimated, communication degraded, and both sides stopped trusting the status reports.

Week one of a rescue

• Code review of what has been built, including test coverage and deployment setup.
• Requirements reconciliation — what was agreed versus what exists versus what is still needed.
• An honest completion estimate with assumptions stated.
• A recommendation with options: continue, hand over, or restart, each with a cost.

Handling the incumbent

Rescues go better when the outgoing team hands over cleanly. Preserve the relationship where you can — access to repositories, credentials and undocumented decisions is worth more than the satisfaction of a hard exit.

What to avoid

Do not sign a fixed-price completion before the assessment is done. Nobody can price the remaining work on a codebase they have not read, and a number given before that point is a guess you will pay to correct.

SEO migration work is unglamorous and entirely front-loaded. Almost all of the value comes from work done before the cutover.

Pre-launch checklist

1. Crawl the existing site and export every indexed URL with its traffic and rankings.
2. Map each URL to its new destination — one-to-one wherever possible, and never redirect everything to the homepage.
3. Preserve on-page elements — titles, meta descriptions, headings, canonical tags and structured data.
4. Match or beat performance on the templates that carry your organic traffic.
5. Prepare the redirect file and test it against the crawl export before launch day.

After launch

Submit the new sitemap, watch crawl errors and rankings daily for the first two weeks and weekly for two months. A dip in the first fortnight is normal. A dip that has not started recovering after six weeks means something in the mapping is wrong, and it is usually findable.

Nobody funds a project called “pay down technical debt”. They fund projects that make releases faster and outages rarer, which is the same work described honestly.

Make the debt visible

Produce an inventory: heavy core customisations, unsupported dependencies, missing tests, manual deployment steps, undocumented integrations. For each, record what it costs — hours per release, incidents per quarter, features it blocks.

Prioritise by cost, not by ugliness

Some of the worst-looking code is stable and untouched, and can safely be left alone for years. The debt worth paying is the debt you touch every sprint.

Fund it inside feature work

Attach remediation to the features that pass through that part of the codebase, and reserve a fixed share of each sprint for it. It is slower than a dedicated project and far more likely to actually happen.