Questions, answered.

Fast. On an emergency retainer, our first response target is under 15 minutes during cover hours — we acknowledge, triage, and tell you the plan. For a one-off emergency, we usually start within a couple of hours and aim to have a store-down incident (a 500, 503, or white screen) back up the same day. The single fastest thing you can do is paste the exact error string and tell us what changed last (a deploy, a plugin update, a traffic spike) in the report form.

Yes — 24/7 on a retainer. Store-down incidents don’t keep office hours, so neither do we for retainer clients: nights, weekends, public holidays, and through Black Friday / Cyber Monday peak. For one-off emergency tickets we cover extended hours and prioritise true outages, though a guaranteed round-the-clock SLA is what the Emergency Retainer is for.

Three clear options, all billed at our $25/hr rate:

• Quick Fix — $99 (~4h @ $25/hr): one well-defined bug, fixed in 24–48h.
• Bug-Fix Sprint — $499 (~20h @ $25/hr): a batch of bugs or one gnarly root-cause with regression tests.
• Emergency Retainer — custom: 24/7 on-call with a guaranteed first response. There’s also a one-off stabilization sprint at $2,499 (~100h @ $25/hr) for a store that needs a full clean-up.

You always get the scope and price agreed before work starts — no surprise invoices.

Yes, and we do it carefully. Our default is read-only diagnosis first, a backup before any change, and staging-first wherever a staging environment exists. When a fix has to go straight to live (a full outage with no staging), we take a database/code backup, make the smallest safe change, and keep a tested rollback ready. We never “cowboy” an untested change onto a production store.

For most emergencies, we agree the scope and price up front, then start. A Quick Fix or Sprint is typically paid on agreement so we can begin immediately — speed matters in an outage. Retainer clients are billed monthly and simply log the incident. We’ll always confirm the price with you before any work begins; there are no hidden hourly overruns because every tier is scoped to a fixed hours basis at $25/hr.

Magento / Adobe Commerce, Shopify, WooCommerce, and WordPress — plus BigCommerce, PrestaShop, and OpenCart. This page is the cross-platform hub; for platform-specific emergencies go straight to the right spoke: urgent Magento bug fixing, urgent Shopify bug fixing, urgent WooCommerce bug fixing, or urgent WordPress bug fixing.

Don’t make more changes — report it and we’ll bisect the bad change. Post-deploy breakage is the most common emergency we see: a Magento 503 from a stuck maintenance flag, Class … does not exist after di:compile, broken layout XML; a WordPress/WooCommerce white screen after a plugin update; a Shopify Liquid error after a theme push. We identify exactly which change broke it, roll it back cleanly, then ship a tested fix so you can re-deploy safely.

Yes — this is our top-priority queue, because every minute costs orders. We stabilise first (get checkout working again) and root-cause second. Common culprits: a payment gateway declining valid cards, a Magento place-order stuck on “Something went wrong”, cart AJAX returning 500, or PHP-FPM workers maxed out under load. See the dedicated Magento checkout bug fixing page for the deeper checkout playbook.

A 500 is a server-side crash; a 503 means the service is unavailable (often a stuck Magento maintenance flag after a failed deploy). Both are fixable, usually quickly. We read the server, PHP-FPM, and application logs to find the real cause — a fatal error, an out-of-memory, a bad config, or a half-finished deploy — then clear it and harden against a repeat. For the full diagnostic, see Magento 500 error fixing.

Ideally SSH/CLI access plus admin, and a staging environment if you have one — that lets us read logs, reproduce safely, and ship a tested fix. The minimum is admin access plus a way to view logs. If you can’t arrange access immediately, we can still start by working from the exact error string and your description while access is set up. We work through your hosting’s normal access controls and never ask you to disable security.

Yes. Every fix ships with a regression check, and if our fix breaks something else, we fix that at no extra charge. We target the root cause, not just the visible symptom, so the same bug can’t silently come back. On a Sprint or retainer you also get a short written incident report explaining what broke and what we changed, plus prevention recommendations so it doesn’t recur.

A white screen of death (WSOD) is almost always a fatal PHP error being hidden from the browser — we turn on safe logging, read the real error, and fix it. Common causes: a WooCommerce/WordPress Fatal error: Allowed memory size exhausted or a plugin conflict after an update; a Magento Class … does not exist or broken DI after compile. We isolate the offending code, roll it back or patch it, and verify the page renders. The deeper playbook lives on Magento white screen fix. If your store also needs ongoing performance hardening, our Magento performance optimization service picks up where the emergency fix ends.

May 12, 2026 — per Adobe’s official release schedule. Alongside 2.4.9, Adobe ships security patches for every supported line: 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, and 2.4.4-p18.

You don’t have to upgrade to 2.4.9 the day it ships, but you do need to be on a supported, patched line. If you’re on 2.4.4 or older, your version goes EOL in 2026 and stops receiving security patches — that’s the urgent case. For 2.4.5+, you can stay on your current line as long as you apply the May 12 security patch (2.4.x-pYY).

Typical timelines:

• Express (2.4.7 / 2.4.8 → 2.4.9): 5 – 7 business days
• Standard (2.4.5 / 2.4.6 → 2.4.9): 10 – 14 business days
• Major (2.4.3 or older → 2.4.9): 3 – 5 weeks
• Magento 1 → 2.4.9: 6 – 12 weeks (full re-platform)

Add 2 – 3 days for staging review, regression QA, and the production go-live window.

No. We use a blue-green deployment: the upgrade runs on a parallel staging environment, gets full QA, and then the DNS/load-balancer cuts over to the new version in under 30 seconds. Your live store keeps taking orders the entire time. We do schedule a 5-minute maintenance window for the final database sync, typically at 3 AM in your timezone.

Some will. The pre-upgrade audit (free with every booking) catalogues every extension + custom module on your store and flags incompatibilities before we touch production. For incompatible extensions we either: (1) upgrade to a 2.4.9-compatible version from the vendor, (2) patch the extension ourselves if the vendor is slow, or (3) rebuild the functionality natively. You get a full report before any work starts — no surprises.

Fixed-price tiers, no per-hour surprises:

• Express: $1,499 — minor-version jumps (2.4.7/2.4.8 → 2.4.9), Hyvä intact, < 5 custom modules
• Standard: $3,499 — multi-version jumps, theme migration, up to 20 extensions
• Enterprise: Custom quote — B2B, multi-store, 30+ extensions, ERP/POS integrations, M1 → M2

Every quote includes pre-upgrade audit, full QA, blue-green deploy, and 14 days of post-launch bug-fix coverage.

Adobe Commerce 2.4.9 supports PHP 8.3 and 8.4 (8.4 recommended). MariaDB 10.6 / 10.11, MySQL 8.0, OpenSearch 2.x, RabbitMQ 3.13, Redis 7.2. We handle the full stack — if your hosting needs upgrading we can either coordinate with your provider or migrate you to a more performant setup as part of the upgrade.

Two safety nets: (1) Blue-green means the old version stays warm for 72 hours — one DNS flip rolls back instantly. (2) Every upgrade includes 14 days of post-launch bug-fix support: anything that breaks because of the upgrade gets fixed at no extra charge. After day 14, you can move to a monthly retainer if you want continued cover.

No. Magento upgrades are schema-only — your products, customers, orders, reviews, CMS pages, configurations all stay intact. We snapshot the production database before every step, run the upgrade on a clone, validate counts (orders, customers, products) match before and after, and only then promote to production. Plus the blue-green setup means the original DB is preserved for 72 hours.

Not if it’s done right. We preserve every URL rewrite, canonical, hreflang, sitemap, and structured-data block. Pre/post crawls (Screaming Frog) compare the URL set; any 301 redirects you had stay 301s. Core Web Vitals typically improve on 2.4.9 because of the new caching + Hyvä performance fixes, which is good for rankings, not bad.

We typically run 3 – 4 upgrade cohorts per month with capacity for 2 stores per cohort. The May 12, 2026 launch cohort books out 4 – 6 weeks ahead, so reserve before April 1, 2026 for a Day-1 slot. After that we shift you to the next available cohort — usually within 2 – 3 weeks.

If your store has < 5 extensions, no custom modules, and you’re comfortable with composer + bin/magento, yes. Adobe’s own upgrade tool handles most of it. The cases where DIY usually goes wrong: extension conflicts, broken indexers post-upgrade, payment/checkout regressions you don’t catch in QA, missing data patches, and the dreaded composer.lock conflict between core modules and theme overrides. If your monthly orders have a comma in them, get help.

Hyvä is the modern frontend framework for Magento 2, built on Tailwind CSS + Alpine.js. It replaces Magento’s default Luma theme (which uses jQuery + KnockoutJS) and ships with 5–10× faster page loads, Lighthouse scores in the 90–100 range, and core-web-vitals green by default. Stores that switch typically see conversion lifts of 8–25% from speed alone.

Typical timelines:

• Express (lightly customised theme, < 5 extensions): 2 – 3 weeks
• Standard (custom theme, up to 20 extensions): 4 – 6 weeks
• Enterprise (heavy customisation, B2B, multi-store): 8 – 12 weeks

Add 1 week for staging review + regression QA + the production cutover window.

Some will, some won’t. Hyvä-Compatibility-Module is required for every Luma extension to render frontend HTML — most popular extensions (Mageplaza, Amasty, etc.) ship Hyvä compat modules officially or via the community. The pre-project audit catalogues every extension on your store and flags which need (a) the vendor’s compat module, (b) a custom rebuild, or (c) replacement with a Hyvä-native alternative. You see the report before any work starts.

Hyvä Checkout is a one-page Alpine.js-based checkout that replaces Magento’s slow KnockoutJS checkout. It loads in < 1 second, has a 50% lower bounce rate, and integrates with all major payment gateways (Adyen, Stripe, PayPal, Klarna, Mollie, Razorpay). Yes, you should use it — every Hyvä build we ship now includes Hyvä Checkout by default. Adobe Commerce 2.4.9 ships Hyvä Checkout natively as part of the Hyvä module.

Out of the box, a clean Hyvä install scores 95–100 on Performance, Accessibility, Best Practices, and SEO. With heavy customisation, third-party scripts (GTM, Hotjar, chat widgets), or large media-heavy product pages, expect 85–95. We commit to 90+ as the floor on every Hyvä project — if we ship something below that, we fix it for free.

Hyvä licence is paid per Magento store URL — €1,000 (one-time, perpetual) or €100/year (subscription) per production storefront. Staging environments are free. This is the licence fee paid to Hyvä Themes BV — separate from our development cost. We’ll handle the licence purchase & setup as part of the project (pass-through, no markup).

Hyvä is best for 95% of stores: faster build (4–6 weeks vs 4–6 months), much lower TCO (no separate Node.js infrastructure), works with all Magento extensions via compat modules, and ships green Core Web Vitals out of the box. PWA Studio only makes sense for headless / app-shell / offline-first use cases — and even then, most teams find Hyvä covers 90% of the wins at 20% of the cost.

No. Hyvä runs on the same Magento 2 stack — PHP 8.x, MySQL/MariaDB, Redis, Elasticsearch/OpenSearch. It actually uses fewer resources than Luma because the frontend doesn’t need RequireJS / KnockoutJS bundling. Many stores see hosting bills drop after migration. We can audit your current hosting as part of the project and recommend optimisations.

Fixed-price tiers, no per-hour surprises:

• Theme migration (Luma → Hyvä): $499 — minor design changes, < 5 custom modules
• Custom Hyvä build: $999 — bespoke design, up to 20 extensions, Hyvä Checkout
• Enterprise: Custom quote — B2B, multi-store, ERP/POS integration, headless

Every quote includes pre-project audit, regression QA, blue-green deploy, Lighthouse 90+ guarantee, and 14 days of post-launch bug-fix coverage. Hyvä licence (€1,000 one-time or €100/yr) is separate and paid directly to Hyvä Themes.

Yes — positively, if done right. URLs, redirects, canonicals, hreflang, structured data, and sitemaps all stay intact. Core Web Vitals typically improve dramatically (LCP from 4s → 1.5s, CLS from 0.3 → 0), which is a Google ranking factor. Lighthouse SEO score goes from ~80 (Luma) to ~95 (Hyvä) by default. We do pre/post crawls (Screaming Frog) and report any URL diffs before cutover — no surprise drops.

Two safety nets: (1) Blue-green deploy means your Luma theme stays warm for 72 hours — one DNS flip rolls back instantly. (2) Every project includes 14 days of post-launch bug-fix coverage: anything that breaks because of the migration gets fixed at no extra charge. After day 14, optional monthly retainer for continued cover.

The best time was last year. The second best is now. Specifically: migrate before (a) your next Magento upgrade — combine the two and save 30%, (b) a re-platform or major redesign — Hyvä is faster than re-skinning Luma, (c) Black Friday — if your Luma site is slow, you’re leaving conversion money on the table. Adobe’s 2.4.9 release on May 12, 2026 ships Hyvä Checkout natively, making this an ideal combine-with-upgrade window.

Magento Open Source is the free version — it ships with the core e-commerce engine but does not include the B2B module. To run B2B on Open Source you must build the B2B features yourself (custom companies, quote workflow, customer-specific pricing). That is doable but expensive — you’re reinventing what Adobe ships out-of-the-box.

Adobe Commerce (the paid edition, formerly Magento Enterprise) ships the official B2B module at no extra cost: companies + roles + permissions, request-for-quote workflow, requisition lists, shared catalogues, multi-tier pricing, and credit limits / payment-on-account. For 95% of B2B stores, Adobe Commerce + B2B module is the right starting point. Annual licence runs from ~$22,000 USD/year and scales with GMV.

The Adobe Commerce B2B module ships these out-of-the-box:

• Companies & roles — multi-buyer accounts under one company; admin / purchaser / approver / finance roles; org charts.
• Approval workflows — orders over $X route to an approver before submission.
• Request for Quote (RFQ) — buyers convert their cart to a quote; sales reps respond; quote → order conversion.
• Customer-specific pricing — tiered pricing per customer group, contract pricing, hidden prices behind login.
• Requisition lists — saved cart templates per buyer.
• Shared catalogues — SKUs visible only to designated companies.
• Payment on account — Net 30 / Net 60 with credit-limit enforcement at checkout.
• Quick order — SKU-based bulk add-to-cart (paste a list, attach a CSV).

Everything else (ERP integration, custom approval matrices, sales-rep dashboards) is layered on top.

Typical phased timelines:

• B2B Audit: 1 – 3 days — discovery + written report.
• Standard B2B Build: 8 – 10 weeks — B2B module setup, companies/roles, quote workflow, multi-tier pricing, requisition lists, 1 ERP connector, Net-30 + credit limits, sales-rep dashboard, blue-green deploy.
• Enterprise B2B: 12 – 16 weeks — everything above plus multi-region orchestration, headless GraphQL B2B, multiple ERP integrations, custom sales-rep CRM, ABM integration.

Add 2 weeks for UAT with your real B2B buyers, regression QA, and the production cutover. We work daily on staging with review access from week 2.

Fixed-price tiers, no per-hour surprises:

• B2B Audit: $999 USD — written scope, integration plan, risk register.
• Standard B2B Build: $4,999 USD — full B2B build on Adobe Commerce, 1 ERP connector, sales-rep dashboard.
• Enterprise B2B: Custom quote — multi-region, headless, multiple ERPs, custom CRM.

Adobe Commerce licence (~$22,000 – $100,000+/year depending on GMV tier) is paid directly to Adobe. We can supply pricing letters for procurement. Adobe Commerce B2B module is included free with the licence.

Yes, but expect a significant build cost. Open Source ships the core e-commerce engine but no B2B features — so you’re building (or buying) custom modules for companies + roles, quote workflow, customer-specific pricing, requisition lists, payment on account, and shared catalogues. Community modules exist (Mageplaza, Amasty, MGS) but they patchwork rather than integrate as one cohesive B2B model.

Our recommendation: if your annual B2B GMV is > $1M, Adobe Commerce pays for itself in fewer custom modules, faster build, fewer integration bugs, and Adobe support. Below $1M, an Open Source + 3–4 well-chosen B2B modules can work — we audit both routes in the discovery call.

The Adobe Commerce B2B quote workflow:

1. Buyer adds products to cart, hits "Request a quote" instead of "Checkout".
2. Buyer adds notes (volume, custom terms, project deadline).
3. Quote routes to assigned sales rep in the admin.
4. Sales rep adjusts prices, adds discounts, attaches PDF, replies in-thread.
5. Buyer reviews — accepts, counter-proposes, or declines.
6. On accept, quote converts to a regular order with the negotiated prices.
7. Custom email templates fire at each stage (request received, quote sent, accepted, expired).

We customise the routing matrix, approval logic, expiry rules, and PDF templates to match your sales process. Account-rep dashboards (custom built) give sales managers a pipeline view.

Yes — ERP integration is the single most common Magento B2B project. We’ve shipped connectors to:

• SAP (S/4HANA, ECC, Business One)
• NetSuite (SuiteCloud, RESTlets)
• Microsoft Dynamics (365 Business Central, NAV, AX)
• Sage (50, 100, 200, X3, Intacct)
• Acumatica
• Odoo
• Pimcore (PIM)

Sync points typically: products + stock + customer-specific prices (ERP → Magento, real-time or every 15 min), customers + companies (bidirectional), orders + invoices (Magento → ERP). Protocols: REST, SOAP, EDI (X12, EDIFACT), SFTP. We use queue-backed connectors so a slow ERP doesn’t take down the storefront.

Adobe Commerce B2B supports four overlapping pricing strategies:

• Customer groups — e.g. "Tier-A Distributors" get 30% off list across all SKUs.
• Tier prices — volume breaks (buy 10+ for $9.50, buy 100+ for $8.75).
• Contract pricing — customer-specific or company-specific overrides per SKU (Acme Corp buys SKU-123 at exactly $7.20, regardless of group/tier).
• Catalogue rules — conditional discounts ("15% off if customer is in Texas and SKU is in category X").

Prices can be hidden behind login (visitors see "Login for price"), and synced from ERP in real-time. We build the rule matrix in the discovery call so it matches your existing pricing logic without surprises.

Yes — this is the Companies feature in Adobe Commerce B2B. One company account contains many buyer users with role-based permissions:

• Company admin — manages buyers, sees all orders, edits company info.
• Purchaser — can place orders up to a limit; orders above route to approver.
• Approver — reviews and approves pending orders.
• Finance — sees invoices, statements, credit balance only.
• Custom roles — you define new roles with granular permissions (view-only, view-and-quote, view-and-order, view-and-approve, etc.).

Approval workflows trigger by order value, SKU, category, payment method, or any combination. We’ve built 5-step approval chains for enterprise procurement and simple 1-step approvals for small distributors.

Adobe Commerce B2B ships Payment on Account with built-in credit-limit enforcement:

• Each company gets a credit limit ($X) and current balance (running total of unpaid invoices).
• At checkout, the order total is checked against (credit limit − current balance). If over, the order is blocked or routed to an approver.
• Buyers see their account statement (open invoices, due dates, balance) in their dashboard.
• Net 30 / Net 60 / Net 90 terms are configurable per company.

For dunning + payment collection we integrate with Stripe Invoicing, Authorize.net Recurring, GoCardless, or your existing AR system. Auto-invoice + auto-statement generation runs nightly. We’ve also built custom workflows for lockbox + ACH + wire reconciliation against open invoices.

It depends on what you’re building. Magento ships a full GraphQL B2B API covering companies, quotes, requisition lists, shared catalogues, and customer-specific prices. Use cases that justify headless:

• Sales-rep mobile app — reps quote, order, and track orders on the road.
• Buyer portal app — large customers want a branded ordering app.
• Dealer / distributor portals — embedded in their existing systems.
• Composable commerce — Magento as commerce engine, separate frontend (Next.js, Nuxt, Hyvä).

Headless adds complexity (separate frontend deploy, GraphQL caching, auth flows). For 70% of B2B stores, the Hyvä theme on top of Adobe Commerce hits the same speed targets without the headless overhead. We assess both routes in the audit.

Honest comparison:

• Magento / Adobe Commerce B2B — the most flexible. Companies, multi-tier pricing, quote workflow, ERP integration, custom approval matrices, headless GraphQL. Best for $1M+ GMV B2B with custom workflows or ERP-heavy stacks.
• Shopify Plus B2B — fastest to launch, B2B added in 2023 (companies, catalogue access, payment terms). Limited customisation — you live within Shopify’s data model. Best for < $5M GMV B2B with simple workflows and no heavy ERP.
• BigCommerce B2B Edition (powered by B2B Ninja / BundleB2B) — mid-ground. Quote workflow, customer groups, price lists. Less mature than Magento for complex flows.

If your B2B has 5+ approval roles, custom pricing logic, an ERP, or 5,000+ SKUs, Magento wins on TCO and capability. If you’re a small distributor wanting to launch in 30 days, Shopify Plus B2B is faster. We’re happy to recommend the route that actually fits your business — even if it isn’t Magento.

Buy when an existing Marketplace extension covers 80%+ of your need with reasonable config — it’s nearly always cheaper than custom and someone else maintains the upgrade path. Build custom when (a) no extension solves the problem, (b) you need it to integrate tightly with proprietary systems (ERP, PIM, custom checkout flows), (c) you’re selling the extension itself, or (d) the closest off-the-shelf extension would need so much customisation it’s cheaper to start clean. Our spec audit ($499) gives you the buy-vs-build call in writing before you commit.

Three fixed-price tiers, no per-hour surprises:

• Spec Audit: $499 — 1–2 days, just the spec, you can take it to any developer
• Standard Extension: $2,999 — 3–6 weeks, single-purpose extension with Hyvä + Luma support, MFTF tests, docs, GitHub repo
• Marketplace-Ready: $9,999 — 6–10 weeks, includes Adobe Marketplace submission package, EQP compliance, listing copy, screenshots, demo video, customer-support runbook

If your extension is unusually complex (multi-store ERP integration, custom payment gateway, headless GraphQL surface), we’ll quote per spec. No surprise invoices.

Typical timelines:

• Spec Audit: 1–2 days from kick-off call to delivered spec doc
• Standard Extension: 3–6 weeks — week 1 spec sign-off, weeks 2–5 build + tests, week 6 docs + handover
• Marketplace-Ready: 6–10 weeks — standard build plus Marketplace submission, EQP fixes, listing assets, demo video

Add 1–2 weeks if you want a UAT cycle with real users before sign-off.

Yes — every extension we ship includes a Hyvä-compat module by default. We use the standard Hyvä compatibility module pattern (separate view/frontend directories under Hyva_*Compat) so the extension renders correctly on both Luma stores and Hyvä storefronts without code duplication. If you only need one frontend, we’ll happily skip the other and discount accordingly — tell us in the booking form.

Yes, by design. We use data:patch over InstallSchema, di.xml over class rewrites, plugins / observers over preference, and declarative schema for any DB changes. None of those rely on internal Magento implementation details — they’re the documented extensibility surface. The Standard Extension tier includes 14 days of bug-fix coverage; Marketplace-Ready includes 12 months of upgrade compatibility (we test on each minor + patch release and ship a compat patch if anything breaks).

Yes — that’s the Marketplace-Ready tier ($9,999). It includes: full submission package (technical + marketing), Mage Extension Quality Program (EQP) compliance audit, listing copy, screenshots (admin + frontend), 60–90 second demo video, support runbook, and the actual submission to Adobe’s portal. 100% pass rate to date — every extension we’ve submitted has cleared Adobe’s code review on the first attempt because we run the EQP checks ourselves before submission.

You do, fully. When you pay us to build an extension, the source code is yours under a written assignment-of-IP clause in the contract. You can put it on your own GitHub, sell it, modify it, take it to another developer, open-source it — anything. We retain the right to reuse generic patterns (e.g. our boilerplate module skeleton, our PHPUnit test scaffolding) but never anything specific to your business logic, data, or branding.

Yes. Every extension ships with:

• MFTF (Magento Functional Testing Framework) tests for admin + frontend user flows
• PHPUnit unit tests for business logic, with fixtures for test data
• phpcs --standard=Magento2 + PHPStan level 6 linting on every commit
• GitHub Actions CI running the full suite on every push

We commit to green CI before any merge. The next developer picking up the extension can refactor with confidence because the tests catch regressions.

Yes, two docs per extension:

• User guide (admin-facing) — how a store admin installs, configures, uses the extension. Screenshots, troubleshooting tips, common pitfalls.
• Dev guide (engineer-facing) — architecture, extension points, how to override, how to add custom logic on top, API reference.

Both are markdown in the repo (so version-controlled), plus a rendered HTML version. We write docs the way we wish vendors did when we’re consuming their extensions — thorough, honest, and answering the questions you’d actually ask.

Yes, hugely. Quick rule of thumb:

• Plugin — intercepts a public method (before/around/after). Magento’s preferred extensibility mechanism. Multiple plugins can stack cleanly. Use this first.
• Observer — reacts to dispatched events. Use when Magento explicitly fires an event for what you need.
• Preference (rewrite) — replaces a class entirely. Last resort: only one preference per class wins, breaks other modules trying to do the same. We avoid this unless absolutely necessary.

Bad extensions abuse rewrites; good ones use plugins + observers. We default to plugins because they survive Magento upgrades.

Yes — 60+ open-source Magento 2 extensions on GitHub at github.com/mage2sk and github.com/mage2kishan. Real working code for SEO modules, B2B helpers, admin UX improvements, payment integrations, frontend widgets, and more. Browse the source, run the tests, read the docs — that’s the standard you can expect on your custom build. Several have been adopted by the Magento community and run on production stores.

All tiers include 14 days of bug-fix coverage after handover — anything broken because of our build gets fixed at no extra charge. After that, two options: (1) per-incident support at our standard hourly rate (handy for one-off questions), or (2) maintenance retainer ($299–$999/month depending on extension complexity) covering Magento minor + major version compat updates, security patch verification, and minor feature requests. Marketplace-Ready tier includes 12 months of upgrade compatibility built-in.

My standard hourly rate is $25–$45 USD/hr depending on engagement type:

• Hourly retainer (10+ hrs/week): $25/hr
• Ad-hoc hourly: $35/hr
• Emergency / fire-fighting: $45/hr
• Consulting / advisory call: $75/hr (90-min minimum)

Most clients prefer fixed-price projects ($499–$50k+ depending on scope) where I commit to an outcome rather than billing time. Quotes always include the scope, deliverables, and milestones in writing — you don’t pay until we both sign.

Fixed-price when scope is clear: a Magento upgrade, a Hyvä migration, a specific extension build, a performance audit. You know exactly what you’ll get and pay. I take the risk on time overruns.

Hourly retainer when scope is fluid: ongoing maintenance, exploratory R&D, integrations where requirements shift weekly, multi-month builds where priorities re-shuffle. Lower rate, you keep flexibility, no per-task quoting friction.

If unsure, start with a fixed-price audit ($299–$999) — that gives me the data to recommend the right structure.

Typical lead time is 1–3 weeks. Booked-out slots show on the page hero. For emergencies (broken checkout, security incident, post-deploy regression), I can usually start same-day on a 4-hour fire-fighting block at the emergency rate.

I run my calendar in 2-week sprint cycles. If your project needs continuous attention, the hourly retainer model gives you guaranteed weekly hours rather than queuing behind fixed-price work.

Based in Ahmedabad, India (IST, UTC+5:30). My core hours are 9 AM – 7 PM IST, but I shift 2–4 hrs/day for clients in EU/UK/US timezones. Calls are scheduled in your timezone, never mine.

Time-zone overlap with the major paying-client regions: UK 4–6 hrs/day, EU 4–6 hrs/day, US East Coast 2–3 hrs/day, US West Coast 1–2 hrs/day, AU 5–6 hrs/day. For US-only async work I lean on Loom + written briefs — works better than 6 AM standups.

Yes — I sign your NDA as standard, before any commercial discussion. I also have a short mutual NDA template if you don’t have one.

Contracts are simple: a one-page Statement of Work with scope, deliverables, milestones, payment schedule, IP ownership (yours), and a 14-day post-launch bug-fix clause. Everything in writing, signed digitally (DocuSign or PandaDoc). For projects > $25k I use a 30/40/30 milestone payment split: 30% upfront, 40% mid-build, 30% on launch.

You do. 100%, no exceptions. Every line of code I write under contract is your property — full IP transfer in the SoW. You get the GitHub repo, the deploy keys, the documentation, the database, the CI/CD config. I don’t hold infrastructure hostage.

The only exception: any open-source extension I publish under mage2sk/* or mage2kishan/* stays open-source (MIT or AGPL). If you commission custom work that I think the community would benefit from, I’ll ask permission before open-sourcing — never assume.

Honesty: I turn down ~30% of incoming briefs. Common reasons:

• Magento 1.x maintenance. The platform is EOL since 2020. I’ll happily migrate you to M2.4.9, but I won’t patch M1 indefinitely.
• "Just clone Shopify" briefs. If the right answer is Shopify, I’ll tell you so — but I won’t pretend Magento is the right tool when it isn’t.
• Pure design work. I write code, not Figma files. I’ll partner with your designer or recommend one.
• Adult / gambling / regulated grey-area. Personal preference, no judgment.
• Sub-$500 budgets for non-trivial work. The math doesn’t work and I can’t do good work at that price.

I’m the founder of Panth Infotech — a 24-person team in Ahmedabad. For most engagements I’m your direct point of contact and lead engineer. For larger builds (B2B, multi-store, M1→M2 migrations) I bring in 1–3 senior team members under my management. You always have one person to email.

This is the hybrid model: solo-developer accountability with team-grade delivery capacity. Smaller projects ($499–$5k) are usually 100% me; bigger builds ($5k+) flex to 2–4 hands as needed. The SoW always names who’s on the project.

Multiple options:

• Wire transfer / SWIFT — preferred for > $5k
• Stripe / PayPal — credit card / direct debit, 3–4% fee passed through
• Wise (Transferwise) — best FX for EU/UK clients, no markup
• Razorpay — for Indian clients, GST invoice provided
• USDC / crypto — for international clients who prefer it

Invoices in USD by default, but I can quote in GBP / EUR / AUD / INR if you prefer. Net-15 payment terms standard.

Yes — happy to put you in touch with 2–3 past clients in your industry / similar project size. Send your brief through the form, I’ll match you with the most relevant references at the proposal stage.

Public references already on the site: 42 testimonials (5.0 average), Upwork profile (Top Rated Plus, 100% job success), Magento Stack Exchange (Top 3% contributor), GitHub (60+ open-source extensions).

Magento 1 hit End of Life on June 30, 2020. Adobe stopped releasing security patches, bug fixes, and PCI compliance updates from that date. Every day a store stays on M1, it accumulates unpatched CVEs — and most card processors (Stripe, Braintree, Authorize.net) now flag M1 stores as non-compliant during PCI audits. Beyond security: Magento 2 is faster (PHP 8, Varnish, full-page cache native), has a modern admin, ships with B2B and PWA-ready features, and runs on actively-maintained extensions. Migration isn’t optional anymore — it’s the only safe path forward for serious commerce.

Typical timelines depend on store complexity:

• Small store (< 10k SKUs, < 10 extensions, light customisation): 6 – 8 weeks
• Standard store (up to 50k SKUs, up to 20 extensions, custom theme): 8 – 10 weeks
• Enterprise (B2B, multi-store, ERP/POS/PIM integrations, 100k+ SKUs): 12 – 16 weeks

Add 1 – 2 weeks for staging review + final delta-data migration + the production cutover window. We give a fixed timeline up front and won’t move the goalposts mid-project.

Fixed-price tiers, no per-hour surprises:

• Free Audit: $0 — 30-min call + written report on scope, risks, and timeline
• Standard Migration: $4,999 — up to 50k products, up to 20 extensions, full data + SEO carry-over, 14 days post-launch coverage
• Enterprise: custom quote — B2B, multi-store, ERP/POS integrations, 100k+ SKUs, dedicated PM

Hosting, SSL, payment gateway re-application fees, and any third-party extension licences (e.g. Amasty, Mageplaza) are pass-through with no markup. You always see the line items before signing.

Yes — 100% of standard data migrates: customers (with addresses, groups, store credit, gift cards, password hashes where compatible), orders (open + completed + invoices + shipments + credit memos), products (simple, configurable, bundled, virtual, downloadable), categories, reviews, ratings, CMS pages, CMS blocks, URL rewrites, and store config. We use Adobe’s Data Migration Tool as the foundation, plus custom scripts for any non-standard tables (custom modules, third-party schemas). Three test runs on staging confirm row counts match before the live delta-migration during cutover. Audited reports show before/after counts on every table — nothing slips through silently.

Done right, zero ranking loss — and usually a small lift from M2’s better Core Web Vitals. Our SEO continuity protocol: (1) Pre-migration Screaming Frog crawl captures every indexed URL + status code + title + meta + canonical + hreflang. (2) Every legacy URL gets a 301 redirect to its M2 equivalent (auto-mapped where slugs match, manual where they don’t). (3) Schema.org JSON-LD, hreflang, canonicals, meta robots, and XML sitemaps all carried over. (4) Post-launch crawl compares against pre-launch — any 4xx/5xx flagged and fixed within 24 hours. (5) Search Console resubmission of new sitemap. Most stores see ranking improve within 60 days from speed alone.

No — M1 and M2 have completely different architectures. Every M1 extension needs an M2 equivalent. Three paths:

• Vendor M2 version — Mageplaza, Amasty, Magefan, Aheadworks, Webkul all rebuilt for M2. Often free upgrade with proof of M1 licence.
• Community / Marketplace alternative — if the original vendor disappeared, there’s usually a competitor with feature-parity.
• Custom rebuild — for niche / proprietary extensions, we rebuild on M2’s API + UI components.

The free audit catalogues every extension on your M1 store and maps each to one of the three paths — with cost & risk — before any work starts.

Depends on your store:

• Stay on Magento (migrate to M2): if you have B2B flows, multi-store, custom checkout, ERP/POS integrations, 10k+ SKUs, or international tax requirements. Magento 2 is the cheaper path long-term and you keep the data + URL history.
• Move to Shopify: if you have < 5k SKUs, simple B2C, no custom checkout, and value low operational overhead more than control. Shopify Plus starts at $2,300/month vs Magento OS being free + hosting.
• Move to WooCommerce: rarely makes sense from M1 — you lose the commerce-grade catalog model.

The free audit includes a platform-fit assessment — we’ll tell you honestly if M2 isn’t the right answer.

Both options work — we recommend based on store maturity:

• Like-for-like rebuild (default): pixel-perfect M2 theme matching the M1 design. Lowest risk for SEO + UX continuity. No A/B variable to confuse migration metrics. Choose this if your M1 design still converts well.
• Migrate + redesign: combine the migration with a fresh design (or move to Hyvä for the perf bonus). Only ~20% more time and cost than like-for-like, and you get a 2-for-1 project. Choose this if your M1 design is dated, mobile-weak, or pre-Core-Web-Vitals.

Pre-migration A/B testing on staging proves the new design converts at least as well before cutover — we won’t ship a redesign that hurts revenue.

Every legacy M1 URL gets a 301 redirect to its M2 equivalent. Three layers:

• (1) Slug-match auto-mapping — Magento’s URL rewrite migration handles 80–90% of product, category, and CMS URLs automatically (slugs unchanged).
• (2) Manual mapping — for URLs that changed (e.g. M1 .html suffix dropped, custom routes restructured), we generate a CSV of old→new and load it into M2’s url_rewrite table.
• (3) Web-server fallback — nginx / Apache rules catch anything missed at the URL-rewrite level (e.g. legacy .php paths).

Pre/post Screaming Frog crawls compare every URL — any 404s on legacy URLs get patched within 24 hours of cutover. Zero permanent 404s guarantee.

M2 has a completely different checkout (KnockoutJS-based, multi-step or 1-page via Hyvä Checkout) so a custom M1 checkout flow needs to be rebuilt. Process:

• Document the M1 flow — every step, validation rule, payment gateway, business rule.
• Map to M2 checkout architecture — vanilla M2, Hyvä Checkout, or custom UI components. Hyvä is usually cheaper and faster.
• Gateway re-integration — Stripe, Adyen, Braintree, PayPal, Authorize.net, Razorpay, Klarna, Mollie all have native M2 modules. Stored payment tokens carry over where the gateway supports it (most do).

Recurring subscriptions, gift-card balances, and store credit all preserved. Three test transactions per gateway in staging before cutover.

Two safety nets, both built in:

• (1) Blue-green cutover: M1 stays warm and reachable for 72 hours after cutover. DNS / load-balancer can flip back in under 30 seconds if anything breaks. Customer-facing impact during rollback: zero — we cache-bust both ways.
• (2) 30 days post-launch coverage: anything that breaks because of the migration (data inconsistency, redirect miss, payment hiccup, missing email template) gets fixed at no extra charge for 30 days. After that, optional monthly retainer for continued cover.

We also keep the final M1 database snapshot for 90 days — if a customer reports a missing 2017 order on day 60, we can reconstruct it from the snapshot.

Yesterday. Magento 1 has been EOL since June 2020 — every additional day is a CVE exposure and a PCI-compliance risk. Practical timing:

• If your last PCI audit failed or is upcoming: start now. Most processors (Stripe, Braintree, Adyen) flag M1 as non-compliant in 2026.
• If you’re re-platforming anyway: M2 + Hyvä is the cheapest combined upgrade path.
• If you’re > 6 months from Black Friday: you have time for a comfortable migration with two months of post-launch stabilisation.
• If you’re < 3 months from a peak season: book the audit now, schedule the migration for January.

The longer you wait, the more your M1 stack drifts from anything modern. Book the free audit — we’ll tell you honestly when to start.

Yes — measurably and in writing. Every Full Optimization project ships with a Lighthouse 90+ guarantee and a target of 50%+ TTFB reduction. We capture before/after metrics on staging every day during the project (Lighthouse, WebPageTest, RUM if you have it) so you can see the curve flatten in real time. If we miss the agreed targets at go-live, we keep tuning at no extra charge until we hit them. The audit-only tier doesn’t include the fix — it’s a diagnose-and-prioritise report you can hand to any developer to execute.

Three quick checks: (1) Run your homepage through PageSpeed Insights — if the mobile score is below 70, you’re leaving conversion money on the table. (2) Check Search Console > Core Web Vitals — any URL flagged as “Poor” is a Google ranking liability. (3) Time-to-first-byte — if your TTFB is over 800ms on a warm cache, your stack is misconfigured. The free 30-min audit covers all three plus a slow-query log review — you get a written report whether or not you go ahead with the fix.

Mobile: 90+ is the floor we target on every project. 95+ is achievable on Hyvä-based stores with disciplined image strategy and minimal third-party scripts. Below 70 mobile means real revenue impact — Google research and our own client data both show conversion drops sharply once mobile Lighthouse falls under 70. Desktop typically lands 5–10 points higher than mobile because the Lighthouse network throttle is more punishing on mobile. Don’t obsess over the desktop score — mobile is what Google ranks and what most of your customers see.

Yes — checkout is one of the most common Full Optimization scopes. Typical wins: (1) defer all non-essential third-party scripts (chat, analytics, A/B test tools) until after the order is placed, (2) tune the shipping-method and tax-calculation API calls (parallelise where possible, cache where allowed), (3) trim the KnockoutJS view-models that ship with Luma checkout, (4) if you’re open to it, drop in Hyvä Checkout — one-page Alpine.js checkout that loads in < 1s and ships natively in 2.4.9. Checkout-only Lighthouse scores typically jump from 40–60 to 85–95 after this work.

No — that’s the whole reason we use blue-green deploy. The optimised configuration is built and warmed up next to production, then we cut over in < 30 seconds. The old config stays warm for 72 hours, so if anything regresses we flip back instantly. We also do a regression QA pass on staging covering: critical extension flows (search, faceted nav, custom checkout steps, payment gateways), the admin panel, and any custom REST/GraphQL endpoints. The audit catalogues every extension on your store and flags risky ones before any work starts — you sign off the scope, not us.

Core Web Vitals signals start flowing into Search Console within 28 days — that’s the rolling window Google uses for the field-data dataset (CrUX). Visible ranking movement typically takes 6–12 weeks as Googlebot re-crawls and CWV updates feed into the page-experience signal. Stores in competitive SERPs (fashion, electronics, B2B supply) usually see the biggest lift — speed is a tie-breaker against equally-relevant competitors. We do a Screaming Frog crawl pre and post launch and share the URL diff so you can spot any Core-Web-Vital regressions early.

Three categories. (1) Best value: Hetzner dedicated (CCX or AX line) — obscene CPU per dollar, fixed cost, you own the box. Pair with our managed config. (2) Fully managed: Hyvä Cloud, Cloudways, or Sonassi — pricier per month but no DevOps load on your team. (3) Enterprise: Adobe Commerce Cloud if you need the SLA & support contract; AWS behind a custom Terraform stack if you have an in-house DevOps team. We’re hosting-agnostic — the optimisation is portable across all of these. The audit includes a hosting recommendation specific to your traffic shape and budget.

If your Luma frontend is your bottleneck (slow LCP, big JS bundle, KnockoutJS-heavy checkout), yes — Hyvä gets you to Lighthouse 90+ for less effort than re-tuning Luma to the same level. If your bottleneck is backend (slow DB queries, OpenSearch misconfigured, Varnish not in front, third-party-script-heavy theme on a fast CDN), Hyvä won’t fix that — backend tuning will. The audit tells you where your time is actually being spent. If it turns out Hyvä is the answer, we have a separate Hyvä migration service — this performance project would be a stepping-stone or a bundle.

Three layers, each handling different traffic. Varnish sits in front of Magento — it caches full HTML for cacheable pages (category, PDP, CMS) and serves them in < 50ms without ever waking up PHP. FPC (Full Page Cache) is Magento’s own page cache, used as a fallback when Varnish misses. Redis handles two separate jobs: (a) the default-cache for config, layout, blocks, and (b) PHP session storage. We tune all three: Varnish VCL with hole-punching for cart/customer state, FPC tag invalidation, Redis maxmemory + eviction policy, separate Redis databases for cache vs sessions. Done right, your origin only sees logged-in / cart traffic — everything else is served from cache.

Yes — admin tuning is part of every Full Optimization. Common culprits: (1) the indexer running on schedule but not actually completing between runs, (2) bloat in quote, quote_address, and sales_order_grid tables (we run cleanup with a safety-net backup), (3) the admin grid loading the entire product collection because of a missing index, (4) third-party admin extensions running expensive observers on every page load. After tuning, admin pages typically load in 1–2s instead of 8–15s, and the indexers actually keep up with catalogue changes.

Two compounding revenue effects. (1) Conversion lift: stores typically see 8–25% uplift within 90 days post-optimisation, before any UX changes. Google’s own research shows every 100ms of LCP improvement = ~1% conversion gain in retail. (2) SEO lift: rankings improve over 6–12 weeks, which compounds the conversion gain because you’re also getting more traffic. Plus a one-off cost saving: most stores can downgrade hosting after the optimisation (CPU/RAM headroom that was masking the inefficiency is no longer needed) — we’ve seen 30% hosting bill drops. On a $1M/yr store, even a conservative 8% conversion lift covers the Full Optimization fee in under a month.

Yes — Lighthouse 90+ on mobile and desktop on the agreed key pages (homepage, top category, top PDP, checkout step 1) at go-live. It’s in the contract. If we miss it, we keep tuning at no extra charge until we hit it. The audit-only tier doesn’t carry the guarantee — it’s a diagnostic report. The Express Audit + Full Optimization combo does. The Lighthouse target is measured on the staging environment with the production traffic profile (no GTM blocking, no ad-blockers, throttled to Lighthouse’s mobile network) — the same way Google measures it. We won’t cheat the score by removing necessary scripts — we’ll defer / tree-shake / replace them with lighter alternatives.

Magento ships with the building blocks for great SEO — canonicals, sitemaps, meta-tag editing, URL rewrites — but those defaults are incomplete and aimed at developers, not search engines. Out of the box, Magento has no structured data on category or product pages, no hreflang for multi-store setups, no llms.txt, weak default meta-templates, layered-nav URLs that bloat the index, and a Luma frontend that drags Core Web Vitals. Most stores never go past the defaults — which is why “Magento SEO” is a paid specialism. The good news: every gap is a fixable engineering problem, not a platform limitation.

An SEO consultant tells you what’s wrong — runs Screaming Frog, looks at GSC, writes a 40-page report, hands it to your dev team. The dev team then has to translate “add Product schema to PDP” into actual Magento layout XML, blocks, and ViewModels.

An SEO developer does both. Audits the site, then ships the fix in code. No translation lag. No “we’ll get to it next sprint.” For Magento specifically this matters — structured data, hreflang, canonicals, llms.txt all live in the codebase, not in a CMS field. Hire the developer.

Three things make it different: (1) URL bloat — layered nav, search results, sort/order params can balloon the index by 10× if not handled. (2) Multi-store / multi-language — hreflang, canonicals across store views, and per-locale URL rewrites are non-trivial. (3) The product/category split — you have category pages competing with product pages competing with CMS pages for the same keywords. Generic SEO advice (“publish blog posts”) doesn’t cover any of this. Magento SEO is mostly a technical problem before it’s a content problem.

Yes — indirectly but measurably. Hyvä gives you Lighthouse 95+ and green Core Web Vitals out of the box, which Google has confirmed as ranking signals. Stores migrating from Luma to Hyvä typically see LCP drop from 4s to under 1.5s, CLS from 0.3 to 0, and Lighthouse SEO score jump from ~80 to ~95. That moves rankings on competitive keywords by 1–3 positions on average. But Hyvä alone doesn’t add structured data, fix hreflang, or generate llms.txt — those are separate work. Hyvä is necessary; not sufficient.

Structured data (JSON-LD) tells search engines what each page is — a Product, an Article, a FAQ, a BreadcrumbList. Google uses it to render rich results (star ratings, prices, availability, FAQ accordions) directly in search, which can double or triple click-through rate on the same ranking position.

Out of the box, Magento ships no structured data. Adding it correctly — Product on PDP, ItemList on category, FAQPage on FAQ pages, Organization site-wide, Person on author bios — is one of the highest-ROI SEO interventions you can make. We ship it via the Panth_StructuredData module on every project.

llms.txt is the robots.txt for AI engines — a structured page index at /llms.txt that tells ChatGPT, Claude, Perplexity, and Google AI Overviews which pages on your site are worth citing. It lists your CMS pages, top categories, blog posts, services, with one-line summaries.

Yes, your Magento store should have one. AI-engine traffic is a fast-growing 2026 channel — Perplexity is sending real e-commerce referrals already. Most Magento stores don’t even know llms.txt exists. Our open-source module auto-generates it on every cron, alongside robots.txt and sitemap.xml. Free win.

Four things: (1) ship /llms.txt — the AI page index. (2) whitelist GPTBot, ClaudeBot, PerplexityBot, and Google-Extended in robots.txt (most templates accidentally block them). (3) use rich, factual content on key pages — AI engines cite pages with clear claims, dates, prices, and structured data. (4) publish content that answers questions directly — FAQ-style headings (“What is X?”, “How do I Y?”) get cited far more often than marketing copy. We do all four as part of the SEO Project tier.

No — and anyone who guarantees first-page rankings is lying. Search results depend on competition, content quality, backlinks, brand authority — none of which are fully under our control. What we do guarantee in writing: Lighthouse 95+, structured data on every page type, hreflang validity, zero index loss vs. baseline, and llms.txt shipping. Those are the technical floors that enable ranking. The actual ranking moves come from the combination of clean technical SEO + content + time. We’re honest about the difference.

Three timeframes: (1) Technical fixes (structured data, Core Web Vitals, hreflang) — 2–6 weeks to show in GSC impressions / position. (2) On-page changes (titles, metas, internal links) — 4–8 weeks for Google to recrawl + reindex + rerank. (3) Content + link-building — 3–6 months for a new pillar page to land on page 1 for competitive terms. Anyone telling you faster is selling snake oil. We send a 30-day position-tracking report after launch so you can see the curve as it bends.

Technical SEO is everything that affects how search engines crawl, render, and index your site — sitemap, robots, structured data, canonicals, hreflang, page speed, mobile-friendliness, redirects, internal linking architecture. It’s the floor. If technical SEO is broken, no amount of content fixes it.

On-page SEO is what’s on each individual page — title tag, H1, meta description, headings, body copy, image alt text, internal links to / from. It’s how you rank for a specific keyword once technical SEO has unlocked indexing.

Magento needs technical SEO first. Doing on-page work on a site with broken hreflang or no structured data is rearranging deck chairs.

Both — and the order matters.

• Before migration: baseline crawl (Screaming Frog), full GSC export, current Lighthouse scores, ranking snapshot for top 100 keywords. This is your “don’t-break-it” reference.
• During migration: preserve URLs, set up 301s for any URL changes, port hreflang and canonicals, port structured data.
• After migration: immediate post-launch crawl, diff against baseline, fix any 404s / redirect chains, resubmit sitemaps to GSC, monitor for index drops over 30 days.

Migrations done without an SEO playbook routinely cause 20–60% organic-traffic drops. Done with one, the loss is zero or near-zero.

Hreflang tells Google which version of a page to serve to users in different countries / languages — e.g. en-GB for UK shoppers, de-DE for German shoppers. Done right, it routes the right user to the right store view and prevents duplicate-content penalties.

It’s almost always broken because of three foot-guns: (1) missing reciprocal tags — if page A links to page B with hreflang, B must link back to A. (2) hreflang loops — A points to B, B points to C, C never points back. (3) wrong locale codes — en_UK instead of en-GB. Magento’s default multi-store setup ships hreflang in the page header but doesn’t validate it. Our audit catches all three on every project.

Fixed-price, no per-hour billing:

• Hyvä Audit — $499. Written compatibility report + migration plan. 3–5 days.
• Hyvä Migration — from $4,999. Full Luma→Hyvä port with up to 20 extension bridges + Hyvä Checkout. 2–6 weeks.
• Enterprise — custom quote. Multi-store, B2B, ERP integration, headless options. 6–12 weeks.

Hyvä licence (€1,000 one-time or €100/yr) is paid directly to Hyvä Themes — pass-through, no markup.

Typical timelines from kick-off to live:

• Lightly customised theme, < 10 extensions: 2–3 weeks
• Custom design, up to 20 extensions: 4–6 weeks
• Heavy customisation, B2B, multi-store: 8–12 weeks

Add 1 week for staging review + regression QA + the production cutover window. The compatibility audit (step 1) is always 3–5 business days.

Some yes, some need work. Hyvä needs a compat module for each Luma extension to render frontend HTML. Three outcomes per extension:

1. Vendor ships Hyvä compat — install, done. (Mageplaza, Amasty, Magefan, Mirasvit usually fall here.)
2. Community compat module exists — install + test.
3. Custom bridge needed — I rebuild the frontend layer (Tailwind + Alpine partial).

The pre-project audit catalogues every extension on your store and tells you which bucket it’s in. You see the full report before any work starts — no surprises mid-build.

Yes. Roughly 40% of my Hyvä work is new builds — bespoke design from your Figma or brand book, mapped to Tailwind tokens, with a custom child theme that doesn’t fork Hyvä parent. You get a Hyvä storefront that looks nothing like the default and stays upgrade-safe when Hyvä ships new parent releases. Same pricing model as migration: fixed-price quote, blue-green deploy, Lighthouse 90+ guarantee in writing.

Yes — three real cases:

• UK fashion retailer (15K SKUs): Lighthouse mobile 38 → 96. LCP 6.2s → 1.4s. +11% AOV, +18% mobile conversion in Q1 post-launch.
• B2B industrial supplier (DE): Lighthouse desktop 52 → 98. TTFB 1.8s → 280ms. −47% quote-request drop-off.
• US D2C home-goods brand: Lighthouse mobile 41 → 94. INP 612ms → 148ms. +15% checkout conversion, $40K/yr saved by staying on Magento+Hyvä vs. moving to Shopify Plus.

I can share full case studies under NDA on request.

Yes — every audit is run by me personally, not handed to a junior. I review each extension on your store against the Hyvä compatibility registry, the vendor’s release notes, and (where needed) the actual module source. You get a written PDF + spreadsheet flagging each extension as compat-ready, bridge-needed, or replace-with-Hyvä-native, with effort estimates per bucket. The audit is yours to keep regardless of who builds the migration — no lock-in.

Yes to both:

• Adobe Certified Expert — Magento Commerce Developer (current, renewed 2023).
• Hyvä specialist — active in the Hyvä community since 2022, shipped 25+ production Hyvä builds.
• Top Rated Plus on Upwork (5.0 score, 100+ Magento reviews).

Hyvä Themes BV doesn’t (yet) have a formal “certified Hyvä developer” programme, but I’m on the Hyvä partner directory and have direct contact with the Hyvä core team for edge cases.

I prefer fixed-price projects over hourly — you get a predictable number, I keep the velocity. But for hourly engagements:

• Standard hourly: $25/hr
• Retainer (10+ hrs/month): $22/hr
• Urgent / weekend / overnight: $45/hr

Fixed-price tiers: $499 audit, $4,999 standard migration, custom Enterprise quotes. NDA work is at the same rate — no “NDA tax”.

Yes. Roughly 30% of my Hyvä clients are under NDA — B2B suppliers, healthcare, fintech, brands not wanting competitors to know they’re re-platforming. I’ll sign your NDA before the discovery call. If you don’t have one, I have a standard mutual NDA I can send. NDA work is at the same rate as non-NDA — no premium. Logos / quotes stay out of my portfolio until you say otherwise (or forever).

The $499 Hyvä Audit is the entry point. Below that, I’ll point you to community resources — not because I’m too good for small work, but because the audit is genuinely the highest-ROI first step. Once you have the audit report, you can either book the migration with me, take the plan to another developer (no lock-in), or DIY it. For ad-hoc small tasks on an existing Hyvä build (bug fix, single-page customisation, performance tweak) I bill hourly with a 2-hour minimum.

An SSL/TLS certificate encrypts the connection between your visitor’s browser and your server, turning http:// into https:// with the padlock icon. You need one because: (1) browsers now flag any HTTP site as “Not secure”, scaring off customers; (2) Google uses HTTPS as a ranking signal; and (3) payment, login, and contact forms are unsafe without it. For an e-commerce store it’s effectively mandatory — card processors require it.

For 95% of sites, free Let’s Encrypt is perfect — it offers the exact same encryption strength as a paid cert, browsers trust it equally, and it auto-renews. You only need a commercial cert when you want: a financial warranty, an OV/EV certificate that shows your verified company name, a longer validity term, or vendor support guarantees (some enterprises and banks mandate this). We’ll recommend the right one for your situation — no upsell.

Done correctly, it helps — HTTPS is a confirmed Google ranking signal. The risk is in a sloppy migration: if you don’t add proper 301 redirects from HTTP to HTTPS, update canonical tags, sitemap and internal links, you can temporarily lose rankings. Our HTTPS migration always includes server-level 301s, canonical and sitemap updates, and a base-URL change, so search engines treat it as the same site — no ranking drop.

Mixed content means your page loads over HTTPS but still pulls some assets (images, scripts, fonts, iframes) over insecure HTTP. The browser then refuses to show the full padlock and may block those assets. The usual culprits are hardcoded http:// URLs in your theme, page content, or database. We sweep your pages and run a safe database find-and-replace to rewrite every offending URL to HTTPS, so the padlock is clean site-wide.

A wildcard certificate secures a domain and all of its subdomains with one cert — e.g. *.yourdomain.com covers www, shop, blog, api, staging, and any future subdomain. It’s ideal for multi-store, multi-app, or microservice setups. If you only have one or two fixed subdomains, a standard or multi-domain (SAN) cert is cheaper. We’ll advise based on how your subdomains are likely to grow.

Let’s Encrypt certs last 90 days, so we automate renewal rather than relying on memory. We install certbot or acme.sh with a scheduled cron that checks daily and renews ~30 days before expiry, plus a reload hook that restarts the web server so the new cert goes live with zero downtime. Once it’s set up correctly, you should never see an “expired certificate” error again. We test the renewal with a dry-run before handing over.

Yes. We’ve installed SSL on Nginx, Apache, LiteSpeed/OpenLiteSpeed, cPanel/Plesk, and cloud VMs (AWS, GCP, Azure), as well as managed hosts like Cloudways and Kinsta. We work with any stack — Magento, WordPress, Laravel, Node, or a static site. The only thing we need is either SSH/panel access or, for some setups, DNS access at your registrar. If you’re on fully-managed hosting that handles SSL itself, we’ll tell you so you don’t pay for work you don’t need.

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to always use HTTPS for your domain, even if someone types http://. It blocks downgrade attacks and is required for an A+ SSL Labs grade. It’s safe once your HTTPS is fully working — but you should only enable HSTS preload after you’re confident every subdomain has a valid cert, because it’s hard to reverse quickly. We enable it as the final hardening step, in the right order.

A single-domain install with a force-HTTPS redirect and a quick mixed-content fix is usually live the same day — often within a couple of hours once we have access. A full HTTPS migration with a complete mixed-content sweep, database rewrite, and A+ hardening typically takes 1 – 2 days. Multi-server, load-balanced, or CDN setups are scoped individually. If your cert has expired and the site is down, we fast-track it.

Fixed-price, billed at $25/hr so the math is transparent:

• Essential SSL Setup — $99 (~4h): one domain, install + force-HTTPS + auto-renewal + quick padlock fix
• Pro SSL & Hardening — $299 (~12h): wildcard / multi-domain, full mixed-content sweep, HSTS, A+ hardening
• Multi-Site / Enterprise — custom quote: multi-server, CDN, OV/EV, mTLS, internal CA

Free Let’s Encrypt certs cost nothing. If you choose a commercial / OV / EV / wildcard cert, that authority fee is paid to the CA and passed through with no markup.

Yes. Cloudflare (and CDNs like Fastly) add a second SSL layer: the cert at the edge between the visitor and the CDN, and the cert at the origin between the CDN and your server. The common mistake is using Cloudflare’s “Flexible” mode, which leaves origin traffic unencrypted and can cause redirect loops. We configure Full (Strict) mode with a valid origin certificate, so the connection is encrypted end-to-end and there are no loops.

If we set up auto-renewal, expiry shouldn’t happen — but things change (server migrations, DNS edits, hosting moves). Every setup includes a short period of post-setup support to fix anything related to our work at no extra charge. Beyond that, we offer an optional low-cost monitoring + renewal retainer that watches your cert’s expiry date and alerts (or fixes) before it ever lapses. You’re never locked in — the renewal automation we install keeps working whether or not you take the retainer.

Three fixed-price tiers, no per-hour surprises: Quick Fix $99 (~4h @ $25/hr) for one well-defined Cloud bug fixed in 24–48h; Bug-Fix Sprint $499 (~20h @ $25/hr) for a batch of bugs or one deep root-cause with regression tests; and Emergency / Retainer (custom) for 24/7 on-call cover, including an optional $2,499 stabilization sprint (~100h @ $25/hr). You get the price before any work starts.

Yes. A failed Cloud deploy almost always shows up as an ece-tools error in var/log/cloud.log or deploy.log — a bad .magento.env.yaml setting, a config-import mismatch, or a patch that won’t apply (“Unable to apply patch”). We read the logs, reproduce on your Integration branch, fix the root cause, and get the pipeline green again. Most single deploy failures are a Quick Fix.

On Adobe Commerce Cloud, Fastly is the full-page cache. If edits don’t show, the usual causes are: surrogate keys not being purged, a stale-while-revalidate window, a broken custom VCL snippet (often throwing a 503), or the Fastly module not being configured for soft-purge. We audit your Fastly setup, fix the VCL or purge logic, and confirm that price, stock and CMS changes invalidate correctly.

Yes — that’s the whole point of staging-first. On Adobe Commerce Cloud we reproduce and fix on your Integration or Staging branch, never debugging Production directly. You review the diff and the green pipeline, then we promote Staging → Production through the standard Cloud deploy. Every fix ships with 14 days of free regression cover if anything regresses from our change.

Staging first, always. Adobe Commerce Cloud gives every project an Integration, Staging and Production environment, and we use that workflow exactly as Adobe intends: reproduce on Integration/Staging, fix on a feature branch, verify the pipeline, then promote to Production. For true emergencies where the bug only manifests on Production, we work on a clone or behind maintenance mode with your sign-off — never blind changes on live.

Emergency Production incidents are triaged within 4 business hours (under 1 hour on a retainer). A single, reproducible bug is typically fixed and deployed in 24–48 hours. A deeper root-cause spanning deploy, Fastly, B2B and config-management usually lands inside a Bug-Fix Sprint of a few working days, including the regression tests.

Ideally: a user added to your Adobe Commerce Cloud project (Integration/Staging at minimum), read access to cloud.log / deploy.log, and a New Relic APM link if you have one. For Fastly issues we need the Fastly service ID and API token (or admin access to configure it through the Cloud admin). If you can’t grant project access immediately, we can start from logs and a screen-share and arrange access in parallel.

Yes — post-patch regressions are one of the most common Adobe Commerce tickets. After a quarterly security patch or version bump, you might see a PHP Fatal error, a New Relic error-rate spike, or a third-party extension that no longer applies cleanly. We diff the patch against your customizations, pin the conflict, and ship a verified fix that survives the next patch cycle. A backlog of post-patch issues fits a Bug-Fix Sprint.

Yes. B2B is where Adobe Commerce earns its licence and where bugs hide: shared-catalog prices not applying to a company, the requisition-list or negotiable-quote workflow stalling, or company-account credit limits miscalculating. We trace the issue through the B2B module, the shared-catalog indexer and the relevant price scopes to a clean root-cause fix — not a workaround.

That’s configuration drift. On Adobe Commerce Cloud, config lives in three places: app/etc/config.php (committed), environment variables (per-environment), and the database. When they fall out of sync, a setting applies on Staging but not Production. We diff the two environments, identify which layer drifted, and bring everything back under bin/magento config:dump / config-management control so it deploys deterministically.

Yes. A long deploy phase means real downtime on each release. The usual fixes: move static-content deployment into the build phase, tune SCD_THREADS and SCD_MATRIX in .magento.env.yaml, trim unused locales, and enable the post-deploy warm-up hook. We typically cut multi-minute maintenance windows down to seconds while keeping the pipeline reproducible.

Yes. Every fix ships with 14 days of free regression cover — if anything regresses because of our change, we fix it at no extra charge. We also commit an automated regression test to your repo for each substantive bug so it can’t silently come back on the next deploy. For ongoing peace of mind, a retainer adds reserved hours and a tighter SLA. Read more on the emergency bug-fixing hub.

Most single, well-defined Magento bugs are fixed for a flat $99 (~4h @ $25/hr) on the Quick Fix tier, turned around in 24–48 hours. A batch of bugs, or one deep root-cause like stuck indexers or a DI mess after an upgrade, runs $499 (~20h @ $25/hr) on the Bug-Fix Sprint. Store-down emergencies and ongoing on-call are scoped on the Emergency / Retainer tier, including a $2,499 stabilization sprint (~100h @ $25/hr). You get a fixed price before any work starts — never an open-ended hourly bill.

Emergency tickets — store down or checkout broken — are triaged within the hour and usually fixed the same day. A standard, reproducible bug ships in 24–48 hours. The honest variable is reproduction: a bug with a clear error string (like Area code is not set) and staging access moves fastest. The more of the error log and steps you send up front, the sooner it’s live.

Yes — that’s the whole point of the process. Every fix is reproduced and tested on staging or a clone first, lands on a Git branch, and only then deploys to production. Because it’s in version control, one command rolls the change back if anything looks wrong. We watch var/log during and after deploy. We never edit live files directly or guess on production.

Staging-first, always, when one exists. If you don’t have a staging environment we’ll spin up a clone or set one up — it pays for itself the first time a fix would have taken down checkout. For genuine store-down emergencies with no staging, we work carefully on production with a full backup and a tested rollback ready, and we tell you exactly what we’re changing before we touch anything.

Ideally three things: (1) SSH or deploy access (or your DevOps contact), (2) an admin login, and (3) Git repo access so fixes are version-controlled. For a quick diagnosis we can start with just the error string and a screenshot. We sign an NDA on request and access is removed the moment the job is done. We never ask for card or payment-gateway secret keys.

That error means code touched a frontend or adminhtml resource before Magento set an area — almost always in a custom CLI command, a cron job, or a setup/data patch. We trace the offending class, set the correct area with State::setAreaCode() or the right DI emulation, and confirm the command, cron and any related API all resolve cleanly. Then we add a check so it can’t silently reappear after the next deploy.

Yes. An indexer wedged on processing, or stuck invalid after indexer:reindex, usually means a fatal in a custom indexer, a corrupted changelog / _cl table, or a dead cron that never finishes the job. We find which indexer is failing and why, clear the wedge, repair the changelog, and confirm prices, stock and catalog rebuild green — then make sure cron actually runs so it stays that way. See our Magento cron & indexer bug fixing page for the deep dive.

That’s a dependency-injection / generated-code problem. The usual causes are a stale generated/ directory, a bad preference or type in a di.xml, a proxy or interceptor that never compiled, or autoloader cache pointing at a deleted class. We do a clean rebuild — remove generated/, recompile, redeploy — identify the module that introduced the bad wiring, and fix the config rather than just clearing caches until it works by luck.

Yes, and it’s one of the most common Magento emergencies. That generic message hides a real exception in var/log/exception.log — often a payment-method plugin throwing, a quote/address mismatch, a broken shipping rate, or a JS error stalling the Knockout checkout. We pull the real stack trace, reproduce it on staging, and fix the actual failure point so orders place again. Our dedicated Magento checkout bug fixing page covers it in detail.

A 503 or white screen straight after setup:upgrade / setup:deploy:mode:set production is usually a missing or stale generated/ directory, an uncompiled DI, a failed static-content deploy, or wrong file permissions. We read the real error from var/log / PHP-FPM logs, rebuild generated code, redeploy static content, fix ownership, and bring the store back — then document what failed so the next deploy is clean. See Magento 500 error fixing and Magento white screen fix.

Yes. When order confirmations, invoices or password resets silently vanish, the cause is almost always a stuck or disabled cron (Magento queues mail and sends it via cron), a broken SMTP / Sendgrid / Mailgun config, a sender-domain SPF/DKIM problem, or a template syntax error throwing on render. We check the email queue, fix the cron and the transport config, validate the templates, and send live test orders to confirm mail flows again. Details on the Magento email not sending fix page.

Absolutely — post-upgrade breakage is one of our most common tickets. After a 2.4.x upgrade you often see DI compile errors, deprecated extensions throwing fatals, layout XML that no longer matches the new templates, or checkout regressions. We diff what changed, fix the incompatible code or extension, and add regression checks. While we’re in there we can also flag performance wins — see Magento 2 performance optimization. For multi-store or larger fixes we coordinate with the broader emergency e-commerce bug fixing service.

It depends on the consumer and the data shape. Magento REST API is the right call for most server-to-server integrations (ERP, CRM, marketplace sync) — it’s stable, well-documented, and covers nearly the whole admin surface. Magento GraphQL shines for storefront / headless consumers that need lean, typed payloads and want to fetch exactly the fields they use in one round-trip. We design each flow against whichever fits the latency budget and payload shape, and frequently use both in the same project.

Yes. Magento ERP integration with NetSuite, SAP, and Microsoft Dynamics is one of our most common builds. We sync orders, invoices, inventory, pricing, and customer records — usually two-way — with explicit field mappings you can audit. We connect either directly via the ERP’s REST/SOAP API or through an iPaaS layer (Celigo, Boomi, MuleSoft) when one is already in place. Every record carries an idempotency key so a retried call never creates a duplicate.

Instead of nightly CSV exports that drift out of date, we use event-driven sync. Magento fires a webhook (or pushes a message onto a RabbitMQ queue) the moment an order is placed, stock changes, or a customer is created. A worker consumes the event, transforms the payload, and calls the target system’s API. Queues smooth out spikes, decouple the two systems, and let us retry on failure without blocking the storefront.

Nothing gets lost. Every outbound call uses an idempotency key, so if a message is delivered twice you still get exactly one record downstream. Transient failures (timeouts, 5xx, rate limits) are retried with exponential backoff. Anything that still fails after the retry budget lands in a dead-letter queue and fires an alert, so a human fixes it — the order is never silently dropped.

Yes. When the native Magento REST API or GraphQL schema doesn’t expose what you need, we build custom endpoints the proper Magento way — service contracts, webapi.xml routes for REST, and resolvers + schema.graphqls for GraphQL. They’re versioned, secured with the same ACL/token model as core, and documented so your other teams can consume them.

Webhooks are almost always better: the source system pushes an event the instant something changes, so data stays fresh and you don’t hammer the API. Polling is the fallback when a third-party platform doesn’t emit webhooks — we then poll on a sensible schedule with a cursor so we only fetch what changed. For high-volume two-way flows we layer RabbitMQ queues on top so neither side is overwhelmed.

We never expose admin credentials. Server-to-server integrations use integration tokens or OAuth 1.0a scoped to the minimum ACL resources the integration actually needs. Secrets live in environment config or a secrets manager — never in code or the repo. Inbound webhooks are verified by signature/HMAC, traffic is TLS-only, and middleware sits behind allow-lists where appropriate. Every integration gets its own credentials so access can be revoked independently.

Yes — marketplace sync is a core part of what we do. We integrate Amazon (SP-API) and eBay so listings, inventory, and orders stay consistent across channels. Stock is decremented centrally so you never oversell, and marketplace orders flow back into Magento for unified fulfilment and reporting. We can build this directly or bridge an existing multichannel tool (ChannelEngine, Linnworks) into your Magento data.

Rough timelines:

• Single integration (one system, one direction): 1 – 2 weeks
• Multi-system integration (ERP + CRM + marketplace, two-way): 3 – 6 weeks
• Custom platform / middleware (high volume, 4+ systems): 6 – 12 weeks

Discovery and sandbox testing are included — we don’t cut a go-live until you’ve signed off the data flowing correctly in a sandbox.

Yes — rate limiting is designed in, not patched on. We respect each platform’s quota with token-bucket throttling, batch requests where the API supports it, and queue-based backpressure so a burst of orders doesn’t trip the limit. When a 429 does come back, we honour the Retry-After header and back off automatically. This matters most for marketplace APIs (Amazon SP-API) and ERPs with strict concurrency caps.

Yes. Every build ships with 14 days of post-launch coverage and a monitoring dashboard + dead-letter alerting so issues surface fast. Beyond that, we offer an optional monthly retainer that covers API version bumps (vendors deprecate endpoints regularly), monitoring, and small mapping changes as your catalog or processes evolve. Custom Platform engagements include 30 days of coverage by default.

Transparent pricing at ~$25/hr:

• Single Integration: $499 (~20h) — one system, one direction
• Multi-System Integration: $1,499 (~60h) — up to 3 systems, two-way real-time sync
• Custom Platform: custom quote — middleware/iPaaS, high volume, 4+ systems

Every quote includes discovery, field-mapping, sandbox testing, go-live, and post-launch coverage. Any third-party platform licence or API fees are paid directly to the vendor — no markup from us.

A spam redirect almost always means your store has been hacked and an attacker injected malicious code. On Magento 2 the redirect usually hides in injected JavaScript, a poisoned CMS block or layout-XML update, a rogue config row in the database, or a modified core file. It often only triggers for visitors arriving from Google or on mobile, so it looks fine to you while it’s costing you traffic and trust. Magento malware removal finds the injection at the source and closes the backdoor that allowed it.

We compare every core file against Magento’s known-good checksums to surface modified or added files, then scan the full filesystem for PHP web-shells, obfuscated uploaders and suspicious recently-changed files. We review access logs to pin down the entry point and timeline, and audit the database for rogue admin users, malicious cron jobs and injected rows. The goal isn’t just to remove the visible symptom — it’s to find and close every backdoor so the attacker can’t walk straight back in.

Magecart is the most common card-stealing attack on Magento. The attacker injects a small piece of JavaScript into your checkout that silently copies customers’ credit-card details as they type, then sends them to a server the attacker controls. It can hide in checkout JS, a CMS block, layout XML, a third-party script, or directly in the database. Because it doesn’t change how the page looks, stores often run infected for months. Magecart removal is a core part of every cleanup we do.

Yes. Once your store passes a clean rescan, we file a review through Google Safe Browsing / Search Console and track it until the warning is removed. Google typically clears a confirmed-clean site within 24–72 hours of the review request. The key is that the store must genuinely be clean first — submitting a delisting request while malware is still present just resets the clock, which is why we verify before we file.

Most single-site cleanups complete within 1–2 business days. Emergency triage usually starts within 12 hours of your request. A straightforward infection (single skimmer, one backdoor) can be cleaned same-day; a store that’s been compromised for months, has multiple backdoors, or runs across several servers takes longer. Google blacklist delisting then adds 24–72 hours on Google’s side after the store is verified clean.

Reinfection happens when the cleanup removed the malware but left the hole open. We close it: apply all outstanding Adobe APSB security patches, tighten file permissions, change the admin URL, enforce 2FA, rotate every admin and API credential, and set up a file-integrity baseline with monitoring. Our Full Cleanup + Harden tier includes a 6-month reinfection guard — if the same hole is re-exploited in that window, we re-clean at no charge.

For a thorough cleanup, yes — ideally SSH (or hosting-panel) access plus a Magento admin account. SSH lets us scan the full filesystem, compare core checksums and review logs; admin access lets us clean CMS blocks, layout updates and rogue users. If you can only provide admin access, we can still do a partial cleanup, but we’ll be upfront about what we can’t reach. Everything we touch is documented in the final report, and credentials are rotated when we’re done.

No one can promise 100% — but the right hardening dramatically lowers the risk. After cleanup we apply security patches promptly, lock down the admin (custom URL, 2FA, IP allow-listing), tighten permissions, remove unused extensions, and add file-integrity monitoring so any new change is flagged before it becomes a breach. For stores that want this maintained continuously, the Security Retainer keeps patches current and monitoring live year-round.

Fixed-price tiers, billed at $25/hr, no per-hour surprises:

• Emergency Cleanup — $299 (~12h): scan, backdoor + skimmer removal, patches, Google delisting filed
• Full Cleanup + Harden — $599 (~24h): everything above, plus forensic entry-point analysis, full hardening, credential rotation, file-integrity baseline and a 6-month reinfection guard
• Security Retainer — Custom: ongoing monitoring, same-day patching and priority incident response for multi-store or high-traffic stores

Out-of-scope work found during triage is always quoted before it starts.

Yes. Every Full Cleanup + Harden includes a file-integrity baseline and 6 months of monitoring — if a core file changes or a new admin user appears, we get pinged before it becomes a breach. For continuous coverage, the Security Retainer adds same-day Adobe APSB patch application, quarterly security reviews, and a priority incident-response SLA across all your stores and servers.

We clean and harden Magento 2.4.4 through 2.4.9 (Open Source and Adobe Commerce), and we can triage end-of-life 2.3.x and legacy Magento 1 stores too. End-of-life versions no longer receive security patches, so for those we’ll clean the current infection and then strongly recommend an upgrade path — staying on an unpatched version means the next exploit is only a matter of time.

If a Magecart skimmer or database compromise exposed customer or payment data, you may have legal disclosure obligations under GDPR, PCI-DSS or state breach-notification laws — and your payment processor may need to be notified. During cleanup we determine what data was likely exposed and for how long, and we preserve the forensic evidence you’d need. We’re not lawyers, so we won’t give legal advice, but we’ll give you a clear technical breach summary so you and your counsel can decide what to disclose.

A full Magento security audit covers four layers: (1) the application — OWASP Top 10 testing of the storefront, admin and APIs (XSS, SQL injection, CSRF, broken access control); (2) patches — an APSB security patch gap analysis against your exact version; (3) dependencies — a CVE audit of every third-party extension and Composer package; and (4) infrastructure — HTTP headers, server config and admin exposure. You get a single prioritised report at the end.

Most stores aren’t — and the gap is invisible until something breaks. Adobe ships security patches on a rolling schedule (APSB bulletins), and applying a patch is separate from upgrading the platform. Our audit runs a security patch gap analysis that compares your installed version and applied hotfixes against the full APSB list, then flags every missing fix by severity so you can see your exposure window at a glance.

APSB stands for Adobe Product Security Bulletin — the official advisories Adobe publishes for Magento / Adobe Commerce vulnerabilities (for example APSB26-49). Each bulletin lists the affected versions, severity, CVE IDs and the patch or version that fixes it. A Magento security patch closes one or more of these CVEs. Keeping current with APSB releases is the single most important thing you can do to stay safe; our hardening service applies every missing one.

Yes. Our audit includes Magento penetration testing built on the OWASP methodology — we actively probe the storefront, admin and REST/GraphQL APIs for injection, broken authentication, access-control flaws and misconfigurations, not just run an automated scanner. Testing is scoped and authorised in writing first (rules of engagement), and runs against staging where possible to avoid disrupting live traffic.

It depends on how you handle card data. Stores using a hosted/off-site gateway (Stripe, Adyen, PayPal redirect) have a smaller PCI-DSS scope than those capturing card details on-site. Our PCI-DSS v4.0 readiness review maps your setup to the relevant requirements — secure configuration, access control, logging, patching, encryption — and gives you a clear list of what passes today and what needs remediation before your next assessment.

The admin panel is the most-attacked surface on any store. We harden it with: two-factor authentication (2FA) enforced for all users, a custom admin path (no default /admin), brute-force lockout and rate-limiting, IP allow-listing where practical, removal of stale accounts, and least-privilege role review. Combined, these close the credential-stuffing and brute-force routes that account for most admin compromises.

No — done right, hardening is performance-neutral and often a net win. Security headers (CSP, HSTS), 2FA and a custom admin path add no measurable front-end cost. A well-tuned WAF and bot protection actually reduce server load by filtering malicious traffic before it hits PHP. We benchmark Core Web Vitals before and after so you can see there’s no regression.

Yes — third-party extensions are one of the most common entry points. Our extension & dependency CVE audit inventories every installed module and Composer package, cross-checks them against known CVEs and abandoned-package databases, and flags anything outdated, unmaintained or exploitable. We then patch, replace or sandbox the risky ones as part of the hardening engagement.

A standard audit (~20 hours) typically runs over 3 – 4 business days: scope on day one, scanning and manual OWASP testing over days one to three, and the written report on day four. Audit + hardening (~40 hours) adds roughly four to five more days for applying patches, admin hardening and the verification re-scan. Emergency engagements for suspected compromises can start same-day on the Managed Security retainer.

Always. Every audit ends with a prioritised written report: each finding rated by severity and exploitability, with reproduction notes, the affected component, and a clear, costed remediation step. Hardening engagements also include a before/after report from the verification re-scan, so you have documented proof every finding was closed — useful for stakeholders, insurers and PCI assessors.

Yes — the Managed Security retainer provides continuous cover: we monitor every new APSB bulletin and apply patches as they land, run scheduled quarterly re-audits, maintain your PCI-DSS readiness documentation, and give you an emergency-fix fast lane for zero-day patches. You also get a dedicated security contact and a monthly status report. Pricing is custom, scoped to your stack and traffic.

Fixed-price tiers, billed at $25/hr:

• Security Audit: $499 (~20h) — OWASP-based audit, CVE scan, APSB gap analysis and a prioritised written report
• Audit + Hardening: $999 (~40h) — everything in the audit, plus all missing patches applied, admin hardening, header/server hardening, WAF + bot protection and a re-scan
• Managed Security: custom retainer — continuous patch monitoring, quarterly re-audits and an emergency fast lane

Anything out of scope after the audit is quoted upfront — never billed silently.

It depends on your team and traffic profile. ACC is worth it when (a) you don’t want to manage servers, Fastly, New Relic, deploy pipelines, and Adobe-tier patching, (b) your traffic is variable and elastic scaling matters, or (c) you need the bundled support & SLA. It’s not worth it when (a) your team already runs DevOps fluently, (b) traffic is small and steady so a $50/mo VPS would do, or (c) you want full control over kernel-level optimisations. Most stores in $1k-$15k/mo MRR profit from ACC; below that, self-hosted on Hetzner/AWS is cheaper.

The four biggest wins, in order:

• Right-size your environments — most ACC stores are 2-3× oversized on RAM & CPU. Adobe doesn’t volunteer this analysis.
• Fix Fastly cache-hit rate — moving from 60% to 90%+ cache-hit rate cuts origin bandwidth 10× and origin compute alongside.
• Audit add-ons — paid add-ons (extra environments, BlackHat, B2B, etc.) often carry beyond their useful life.
• Optimise asset storage — old media library, unused product images, orphaned PDFs — all billed monthly.

A 90-day audit typically uncovers 30-50% potential savings on the monthly invoice.

Common culprits:

• Static content compilation runs on every deploy — fix with SCD_ON_DEMAND_IN_PRODUCTION or skip-static-content build hooks.
• Composer install fetches from scratch — fix with cached composer + COMPOSER_AUTH proper setup.
• Deploy hooks run sequentially when they could parallelise.
• Database upgrade scripts on every deploy — fix with skip patches that haven’t changed.

Tuned correctly, ACC deploys go from 25-40 minutes to 3-5 minutes. We do this on every Standard Cloud Migration project.

ECE-Tools (Magento\CloudPatches + magento/ece-tools composer package) is the deploy/build orchestrator for ACC. It runs your .magento.app.yaml + .magento.env.yaml hooks, generates static content, applies Adobe’s cloud patches, and configures redis/varnish/fastly. Tuning ECE-Tools is the difference between a 5-minute and a 40-minute deploy. Most stores never look at it. We do.

The default Fastly config that ships with ACC is generic — it’s a starting point, not the destination. Real tuning involves:

• Custom VCL for query-param normalisation, geo-routing, A/B-test splitting
• Image optimisation edge rules (WebP/AVIF on the fly)
• ESI fragments for personalised blocks (cart, customer name)
• Proper Surrogate-Key tagging so cache-purge is targeted not nuclear
• Bot-protection rules + rate limits

Done right, you go from 60% to 90%+ cache-hit rate, which cuts origin compute by 10× and bandwidth costs alongside.

Yes, with proper planning. The pattern: (1) spin up ACC Integration with a full database dump from your current production, (2) validate functionality on Integration + Staging, (3) set up real-time DB replication from old → new for the cutover window, (4) off-peak DNS swap with TTL pre-lowered to 60s, (5) keep old system warm for 72 hours as roll-back. Total downtime: typically 0-30 seconds during the DNS flip. Order data flows to new system immediately.

ACC Starter: Single AWS region, shared infrastructure, no Fastly Image Optimizer, max 4 envs, minimal SLA. Best for stores under $1M GMV. ACC Pro: Dedicated 3-node AWS cluster, Fastly Image Optimizer included, unlimited envs, 99.99% SLA, dedicated support. Best for stores over $1M GMV or with B2B / multi-region needs. Pro is roughly 4-6× Starter pricing but the SLA + Image Optimizer alone often justify it for serious stores.

ACC enforces a 3-tier git branch strategy by design:

• Integration: ephemeral feature branches per developer/PR. Each push triggers a deploy. Used for PR review.
• Staging: mirrors Production data (sanitised) and infrastructure. UAT happens here.
• Production: live store. Only promotions from Staging are allowed.

Done right, each branch has its own data-bridge so a Staging deploy can be tested against real-shape data without touching Production. We set this up properly on every project.

Yes, fully — ACC is just Magento 2 on AWS with managed orchestration. You ship custom modules via composer + git just like self-hosted. The constraints: (a) no kernel-level access (can’t install OS packages), (b) PHP extensions are restricted to Adobe’s supported list, (c) cron jobs run on Adobe’s schedule infrastructure. For 95% of stores, none of this matters. The remaining 5% are typically B2B with custom payment processors or ERP middleware — those need careful pre-project audit to confirm fit.

ACC backs up your DB + media every 6 hours and retains 7 days by default (longer on Pro). However, vendor backups are necessary but not sufficient — for real DR you also want: (a) off-cloud backup copies (S3 to a different account), (b) tested restore runbooks (most teams have backups but never tested restore), (c) point-in-time recovery for transactional data, (d) annual DR drill. Standard Cloud Migration includes setting all of this up; Enterprise includes the DR drill.

Less than you think. ACC is just Magento 2 + AWS + Fastly + New Relic. Your codebase is portable — same composer.json works on a self-hosted server. The only ACC-specific bits are .magento.app.yaml + .magento.env.yaml + ECE-Tools dependency, all of which are open-source. Realistic exit time: 4-6 weeks to migrate from ACC back to self-hosted, vs 8-12 weeks the other way (because you’d need to set up the hosting from scratch). So lock-in is real but recoverable — much less sticky than e.g. Shopify.

Adobe doesn’t publish list prices, but the formula is roughly: base licence (tied to your GMV tier — typically $40k-$200k/year) + infrastructure (compute, bandwidth, storage — typically $1k-$15k/month) + add-ons (extra environments, B2B module, AI services, etc.). Real total: Starter stores pay $5k-$30k/year all-in, Pro stores pay $50k-$300k/year+. The bill grows quickly with traffic and bad caching — which is why our cost-optimisation pass typically pays for itself within 2-3 months from invoice savings alone.

Contract / freelance only at the moment. I run Panth Infotech and a 12-module mage2kishan SEO suite alongside client work, so a full-time W-2 / FTE seat doesn’t make sense for either side.

What I can offer that is “close to full-time”: a 30-hr/week dedicated retainer (4-month minimum) where I’m embedded in your team’s Slack and stand-ups, attend your sprint planning, and cap external work to keep your roadmap unblocked. Several CTOs have used that as a bridge while they hire a permanent senior dev.

Yes — standard practice. I sign your NDA template before any commercial discussion or repo access. I also have a short mutual NDA template (PandaDoc, takes ~2 minutes to sign) if you don’t have one drafted.

For larger engagements ($25k+) I’ll also sign a separate data processing addendum if your store handles PCI / GDPR / HIPAA-adjacent data — happy to use yours or supply mine.

Standard rates:

• Hourly retainer (10+ hrs/week): $25/hr
• Ad-hoc hourly: $35/hr
• Emergency / fire-fighting: $45/hr
• Consulting / advisory call: $75/hr (90-min minimum)
• AI-paired-dev workshop (your team, half-day): $600 flat

Most clients prefer fixed-price projects ($499 – $50k+) where I commit to an outcome rather than billing time. Quotes always include the scope, deliverables, and milestones in writing — you don’t pay until we both sign the SoW.

Based in Ahmedabad, India (IST, UTC+5:30). Core hours are 9 AM – 7 PM IST, but I shift 2–4 hrs/day for clients in EU / UK / US timezones. Calls scheduled in your timezone, never mine.

Practical overlap: UK 4–6 hrs/day, EU 4–6 hrs/day, US East 2–3 hrs/day, US West 1–2 hrs/day, Australia 5–6 hrs/day. For US-only async work I lean on Loom + written briefs — works better than 6 AM standups.

Yes — this is a growing part of what I do. Three formats:

• Half-day workshop ($600 flat): live Zoom, 4 hours, your team brings their actual Magento / Hyvä codebase. We set up CLAUDE.md, MCP servers, slash-commands, hooks. Recorded.
• 4-week embedded coaching ($6,000 flat): I’m in your Slack, review every Claude-Code-built PR, do weekly 60-min sessions, leave behind a written playbook.
• Async written playbook ($499 flat): custom CLAUDE.md, slash-commands, MCP config, written runbook delivered as a PR to your repo. No live time.

Generally no, but case-by-case. I’ve done two equity-only builds in 10 years — both were for friends with strong product-market fit and existing revenue. Default answer for a cold inbound is "cash up front."

What I will consider: 50/50 cash + equity for a series-A or series-B startup with a credible CTO already in seat, where I’m a temporary specialist plug-in (e.g. Hyvä migration, Claude Code rollout). Vesting cliff and acceleration clauses apply.

Yes — two ways:

• 30-min discovery call (free): book a free Zoom and I’ll screen-share my actual setup — CLAUDE.md, slash-commands, MCP servers, hooks, sub-agents — and answer questions about your project.
• $150 paid pilot: 90-min consulting call where I run Claude Code live against a sample of your codebase, output a written report on what would and wouldn’t work for your project.

Also see the public prompts library for the same configs I use on client work.

Honest answer: AI is replacing the type of work juniors used to do (boilerplate, scaffolding, glue code) faster than companies are training juniors to do harder work. That gap is going to bite.

What I tell clients: don’t fire your juniors, retrain them. Pair every junior with Claude Code, change their KPI from "lines of code" to "PR review quality + system understanding," and they outpace mid-levels who refuse the tooling within 6 months. The ones who can’t adapt get replaced — but that was true of every previous tooling shift (IDE, compiler, ORM, framework). My workshops focus on the retraining angle, not the replacement angle.

You do. 100%, no exceptions. Every line of code I write under contract — whether typed by me or generated by Claude Code on my prompts — is your property. Full IP transfer in the SoW. You get the GitHub repo, deploy keys, documentation, database, CI/CD config.

The specific question on AI-generated code: I follow Anthropic’s commercial-use terms (output is yours), I never paste your proprietary code into a third-party LLM other than Anthropic’s API, and I keep audit logs of every Claude Code session for the duration of the engagement. If you have a specific clause you need (e.g. "no AI-generated code in this module"), I’ll respect it — just put it in the SoW.

Three-step path that minimises wasted time on both sides:

1. Send a brief through the form on this page (or email kishansavaliyakb@gmail.com). 6–10 lines is enough — what you need, by when, rough budget if you have one.
2. 30-min free discovery call (Zoom). I read your brief beforehand and come with questions. By the end of the call you’ll know whether I’m the right fit and whether Claude-Code-paired-dev makes sense for your project.
3. Written quote & SoW within 48 hours of the call. Scope, deliverables, milestones, payment schedule, IP terms, NDA. Sign digitally, 30% deposit, we start.

Average time from first email to first commit: 5–10 business days.

Most single Shopify bugs are fixed for a flat $99 Quick Fix (about 4 hours at $25/hr) — one well-defined issue like a Liquid error, a broken section, or a cart drawer that won’t open. A $499 Bug-Fix Sprint (~20h @ $25/hr) covers a batch of bugs or one gnarly root-cause such as an app-conflict slowdown or a checkout.liquid migration, with regression tests. Emergencies and ongoing cover are quoted as a custom retainer.

Yes — we never edit your published theme. We duplicate your live theme, reproduce the bug on the copy, fix and regression-test it there, then send you a preview link. Only after you approve do we publish the duplicate as the live theme. Your original stays in the theme library, so a one-click publish reverts everything instantly if anything looks off.

Yes, we fix it. Liquid error: undefined method means a snippet is calling a property or object that no longer exists — commonly after a theme update, a removed metafield, or a renamed variable. We trace the exact {{ }} or {% render %} that throws, restore the missing data source (or guard it with a sensible default like {{ value | default: '' }}), and confirm the page renders cleanly across templates.

That’s usually a broken section reference or schema. Liquid error (sections/...): Could not find asset means a {% render %} points at a snippet or asset that was deleted or renamed. A section that vanishes in the theme editor often has invalid {% schema %} JSON that won’t save. We repair the asset paths, fix the schema JSON, and restore the section settings so it appears and saves normally.

Almost certainly. Shopify has retired checkout.liquid, so legacy checkout edits, additional scripts and order.status customizations stop running. The fix is to migrate to Checkout Extensibility — UI extensions, Shopify Functions, web pixels and the new branding API. We audit what you relied on, rebuild it the supported way, and verify the checkout end-to-end. For a deep dive see our Shopify checkout bug fixing page.

Yes. App embed conflicts are one of the most common Shopify performance killers: two apps inject the same library, or a leftover app block keeps loading after the app was removed. We audit every embed in theme.liquid and your app embeds in Theme settings → App embeds, remove duplicates, defer the heavy scripts, and clean out orphaned blocks. See our dedicated Shopify app conflict bug fixing page.

This is a JavaScript or AJAX failure. “Add to cart” that does nothing usually means the /cart/add.js request is failing, a console error is swallowing the click handler, or a stale cart bundle is out of sync after an app or theme update. We open the browser console, find the failing request or error, and patch the cart events so the drawer opens, quantities update, and the cart count refreshes correctly.

Yes. Blank metafields or Liquid error: undefined on a connected field usually come from a wrong namespace/key, a type mismatch, or a dynamic source that won’t bind in the editor. We check the metafield definition, correct the metafields.namespace.key reference in Liquid, handle the type (list, rich text, reference) properly, and confirm the value renders on the storefront.

Yes. Many apps leave behind orphaned theme code — snippets, app blocks, and lines injected into theme.liquid or product.liquid — that throw Liquid error: Could not find asset or break layout once the app is gone. We find every leftover reference the app added, remove it safely on a duplicate theme, and verify the affected pages render cleanly again.

A single, well-defined bug is typically reproduced, fixed and verified within 24–48 hours. On the emergency tier — store down or checkout broken — we start triage in under 4 hours and can roll your theme back immediately to stop the bleeding while we work the root cause. Larger batches go into a Bug-Fix Sprint with a scheduled timeline you approve upfront.

The cleanest option is a Collaborator request (we send it, you approve it from Settings → Users and permissions) scoped to Themes and the relevant apps — no password sharing. A limited staff account also works. If you prefer, duplicate your theme and give us access to the copy only. We always work on a duplicate theme regardless, so your live storefront is never touched until you approve the fix.

Yes. If the exact bug we fixed comes back under the same conditions, we re-fix it at no charge. We root-cause the real problem rather than patching the symptom, regression-test cart, checkout, search and product pages before publishing, and hand you a short write-up of what changed. This is the Shopify hub in a wider emergency e-commerce bug fixing service — for theme-specific work see Shopify theme & Liquid bug fixing.

Honest answer: about 10% of Magento stores benefit from headless. The shortlist:

• Mobile traffic > 60% AND mobile conversion lagging desktop by 30%+
• You want a real PWA (offline / add-to-homescreen / push notifications) or native iOS/Android app sharing the storefront codebase
• Multi-region with 4+ storefronts and the marketing team wants per-region content control on the frontend
• You have an in-house Node/React/Vue team already — the infra burden is acceptable

For everyone else — speed problems, conversion lifts, Lighthouse scores — Hyvä gets you 90% of the wins at 20% of the cost. We turn down 9 in 10 headless inquiries on this basis.

Hyvä is the right answer for ~90% of Magento stores. It ships Lighthouse 95+, Core Web Vitals green by default, conversion lifts of 8–25%, and uses your existing Magento infrastructure. Project cost: $499–$999. Timeline: 2–6 weeks.

Headless is the right answer when you specifically need: real PWA (offline, install-to-homescreen, push), native iOS/Android sharing storefront code, or a frontend team that wants to ship 10x faster than Magento’s release cadence allows. Project cost: $7,999–$50k+. Timeline: 8–24 weeks. Plus ongoing Node infra ($100–$500/month).

Our headless audit ($999) gives you a written go / no-go answer. Often the recommendation is “just do Hyvä”.

Each shines in a specific situation:

• PWA Studio (React) — Adobe’s official path. Best if you’re on Adobe Commerce + want vendor support + already have React expertise. Heaviest infra burden: separate Node deployment, build pipeline, separate CDN.
• Vue Storefront (Vue 3 / Nuxt 3) — Best if your team already writes Vue. Strong plugin ecosystem (Algolia, Stripe, Klarna). Cleaner DX than PWA Studio. Still needs Node infra.
• Hyvä-headless (Astro / Next.js + Hyvä Storefront API) — The pragmatic middle path. Get Hyvä speed, headless flexibility, but with edge-rendered HTML so SEO is bulletproof. Lower infra burden than PWA Studio. Best for content-heavy stores.

The audit picks the right one for your specific stack.

Real-world ranges (we publish honest pricing):

• Headless audit — $999 fixed. 60-min call + GraphQL coverage assessment + written report + infra cost estimate.
• Standard headless build — $7,999 fixed. 8–12 weeks. Frontend, GraphQL Mesh, up to 10 custom resolvers, payment gateways, service worker, blue-green deploy.
• Enterprise headless — Custom (typically $25k–$80k). 12–24 weeks. Multi-region, B2B, native iOS/Android via React Native or Capacitor, custom checkout.

Plus ongoing infra: Vercel/Netlify $20–$500/month + Magento backend hosting (unchanged). Be wary of agencies quoting $150k+ — that’s usually scope creep, not value.

Yes — if you SSR (server-side render) the storefront. Static-site generation (SSG) or SSR via Next.js / Nuxt 3 / Astro produces fully-rendered HTML at the edge. Googlebot sees the same HTML a user does. Lighthouse scores typically improve (LCP from 2.5s → 0.8s on a good edge deploy).

The dangers:

• Pure CSR (client-side rendering only) is a SEO death warrant. Don’t.
• URL drift — if the new frontend changes URL structure, you lose rankings. We do a pre-migration crawl + 301 redirect map.
• Hreflang / canonicals must be re-implemented on the frontend. Magento’s built-in tags don’t carry over.

Every headless build we ship includes a Screaming Frog pre/post crawl + URL parity report.

For 80% of storefront features — yes. Adobe’s GraphQL covers products, categories, cart, checkout, customer, orders, search, CMS pages, URL rewrites, store config. The 20% gap typically:

• Custom EAV attributes (we add resolvers)
• B2B queries (companies, quotes, requisition lists — partial in Adobe Commerce)
• Custom checkout fields / extension data
• Third-party extension data (loyalty, reviews from non-native sources, custom recommendations)

Our audit catalogues every gap on your store and quotes the resolver work. GraphQL Mesh stitches Magento’s GraphQL with Algolia / contentful / your ERP into one schema. We document the full schema as part of every build.

You have three options:

• Build native headless checkout — Most expensive ($3k–$15k extra). Full UX control. Required for B2B / multi-step / saved-quote flows.
• Hand off to Magento checkout via SSO — Cheapest. Cart on headless, “Checkout” button redirects to Magento Hyvä Checkout (or Luma). Ugly URL transition but works in days, not weeks.
• Embed Magento checkout in iframe — Don’t. SEO mess, payment-gateway PCI complications.

For most $7,999 builds we recommend hand-off to Hyvä Checkout — it’s already 1-page and <1s, which beats most custom headless checkouts. Build native only if you’re in the Enterprise tier.

Yes, the frontend lives separately:

• Vercel — $20/month Pro tier covers most stores. Best DX. Edge runtime + automatic SSG.
• Netlify — Similar pricing. Good if you want Netlify Functions for edge resolvers.
• Self-host Node — If you have an internal ops team. Add ~$50–$200/month per region for the Node app + CDN.

Your Magento backend stays where it is. No changes needed. Magento becomes a GraphQL API + admin panel + checkout endpoint — nothing else changes server-side. We can warm-up edge caches and pre-render top-200 pages so your origin server load actually drops after going headless.

Yes — this is the strongest case for going headless.

PWA: We ship service worker + manifest + push notifications + offline support on every headless build. Users can install your store to their home screen with one tap. Looks like a native app, no app-store review.

Native iOS / Android: Two paths in our Enterprise tier:

• React Native — Share GraphQL queries + business logic with the web frontend. Separate UI components. ~30% code reuse.
• Capacitor — Wrap the PWA into a native shell. ~80% code reuse. Push notifications, deep linking, app-store distribution. Cheapest path to “real” iOS/Android.

Both ship to Apple App Store + Google Play. Apple takes ~7 business days for first review.

Headless makes multi-store easier in some ways, harder in others. The frontend can:

• Route per locale via Next.js / Nuxt i18n routing (`/en-gb`, `/de-de` etc.)
• Pull Magento store_view_id per route — clean separation
• Mix CMS content from a headless CMS (Contentful / Sanity) per region

The complications:

• Hreflang on the frontend (we handle)
• Multi-currency display needs per-route price formatting
• Per-region payment methods need conditional checkout logic (Klarna in DE, Razorpay in IN, etc.)
• Per-region inventory requires Magento MSI configured + GraphQL queries that respect source-stock per region

Our Enterprise tier ships full multi-region orchestration. 8–12 weeks typical for 4–6 stores.

Yes — this is one of the strongest cases for headless. Adobe Commerce B2B exposes most features via GraphQL: companies, company users, quote workflow (with limits), requisition lists, customer-specific pricing, shared catalogues.

The gaps you’ll fill with custom resolvers:

• Some quote-state transitions (approve / decline / counter)
• Net-30 / credit-limit balance display
• ERP-pulled tier-pricing
• Bulk CSV order upload

We’ve shipped 4 headless B2B builds (Adobe Commerce + Vue Storefront / Next.js). Typical timeline 12–16 weeks. The biggest win clients see: B2B buyers love a clean modern UX vs Magento’s default Luma B2B experience, which feels distinctly 2010s. Conversion uplift on quote-to-order conversion: typically 15–30%.

Real talk — this is where most agencies undersell the cost. Going headless adds:

• Two codebases to maintain — Magento backend AND headless frontend. Each has its own dependency tree, security patches, deployment pipeline.
• Frontend developer skillset — You need a React / Vue / Astro engineer on retainer. Magento PHP devs can’t do this work.
• GraphQL schema drift — Each Magento upgrade may change GraphQL responses. We document a regression-test suite as part of the build.
• Service worker bugs — Stale-while-revalidate logic gets tricky for cart / checkout. Plan for ~2–4 hours/month of frontend tuning.

Our retainer (~$999–$2,499/month depending on size) covers all of this. If you don’t have a frontend dev on staff and don’t want a retainer, headless is the wrong call — stay on Hyvä.

Genuinely free. No catch, no upsell, no “book a call to unlock the rest”.

The reason I do it: I’ve been on Upwork since 2018, hit Top Rated Plus, and I see a lot of strong freelancers leaving money on the table because of fixable profile mistakes (weak hero headlines, generic overview copy, mis-tagged niches). Helping a few each month is enjoyable, costs me an hour, and occasionally turns into a referral or a collab — that’s the only ROI I’m optimising for.

What I won’t do: rewrite your entire profile for you, ghostwrite proposals, or run your account. The audit is opinionated guidance you implement yourself.

A written report (Google Doc or Notion link, your pick) covering:

• Hero headline rewrite — the 70-char headline above your photo. I draft 2–3 alternatives in the niche+outcome+proof pattern.
• Overview opening — the first 2 paragraphs that show in search previews. Restructured for skim-reading.
• Portfolio order + gaps — which items to demote, which titles to rewrite, what missing case studies would help.
• Skills + Specialised Profile — which 5–8 skill tags actually move search ranking for your niche, and whether you should add a Specialised Profile.
• Hourly rate — whether to raise, hold, add a project minimum, or bracket your services.
• One sample proposal — my current proposal template, customised to your niche.

~1,500 words. Reads in 10 minutes, takes ~2 hours to apply.

24 business hours from when you submit. Sometimes faster — if you submit Tuesday morning India time, you’ll usually have it by Tuesday evening. If you submit Friday evening, it lands Monday.

I cap intake at ~5 reviews per week so I can keep that promise. If the queue is full, the form will say so and you can choose to be notified for the next slot.

The audit framework (hero / overview / portfolio / skills / rate / proposals) applies to every niche on Upwork. The patterns I’ve seen working in 2025: niche-specific hero, proof-driven overview, results-as-titles portfolio, narrow Specialised Profile, premium-anchored rate.

What changes by niche is the specifics. For design / UX I’ll talk about case-study cover images and Figma links; for writing I’ll talk about portfolio gating and sample variety; for AI / ML I’ll talk about LLM-stack tags and recency signals. I’ve audited ~80 profiles across web dev, design, writing, marketing, data, AI, and admin — happy to share niche-specific examples in the audit.

Especially useful. New freelancers usually struggle with two things: a hero/overview that doesn’t convert because it sounds like every other beginner, and applying to wrong-fit jobs that hurt JSS once they win.

For new profiles I focus on: positioning narrow enough to win the first 3 jobs, hero/overview that signals expertise without inflating it, portfolio fillers (spec work / pro-bono / personal projects) that outperform "I’m new" disclaimers, and the proposal pattern that beats the “I have 5 years of experience” openers most beginners use.

Partially. JSS is driven by client outcomes (private feedback, contract closure mode, dispute history) more than profile copy — so I can’t directly raise it. But the audit can stop the bleeding by:

• Identifying which job categories you’re winning that you shouldn’t (wrong-fit jobs are the #1 JSS killer)
• Tightening niche so the next 5 contracts are higher-fit
• Adjusting rate so you attract clients who close contracts cleanly (very-low-rate clients dispute more)
• Cleaning up portfolio so the right clients self-select in

If your JSS dropped from a single bad client, JSS will drift back up over 6 contracts even without changes. The audit is for systemic fixes, not bandage on a one-off.

Yes. I won’t suggest anything that violates Upwork’s ToS — no fake reviews, no off-platform poaching language, no rate-undercutting tactics, no “suspended-account workaround”. The advice is everything you can do within the platform: better positioning, sharper copy, smarter proposal allocation, sustainable rate growth.

I’ve been on the platform for 8 years without a single ToS warning, so the framework is built around what works long-term, not what’s trending in shady Telegram groups.

I draft example rewrites for the hero headline (2–3 alternatives) and the overview opening paragraph — enough that you can copy/adapt directly. Full overview rewrites, portfolio item rewrites, and per-niche specialised-profile copy are out of scope for the free tier (otherwise I’d burn 6 hours per audit).

If you want a hands-on rewrite of the whole profile + 3 proposal templates, that’s a paid engagement (~$299 fixed price). But ~80% of freelancers who get the free audit can implement the changes themselves with what’s in the report.

No. I read it, write the audit, send it back. Nothing is published, screenshot, shared with third parties, or fed into any LLM. The form data lives on this site (encrypted at rest), the audit doc is private to your link, and I delete the working notes after sending.

If you’d like to be quoted later as a "this audit helped me" testimonial, that’s opt-in via a separate email — never automatic.

Realistic timeline:

• Search visibility: 7–14 days for skill / niche changes to re-index in Upwork search
• Invite volume: 2–3 weeks once the algorithm catches up
• Proposal reply rate: immediate (next batch of proposals already uses the new template)
• Rate raises: 1–2 contracts to hold the new rate without losing close-rate
• JSS recovery: 4–6 closed contracts

Most freelancers see invite volume change within 30 days. Send me a screenshot at the 30-day mark — I genuinely like seeing the data.

The framework (positioning, hero, overview, portfolio, niche, rate) is platform-agnostic. The specifics are Upwork-specific: skill tags, Specialised Profiles, Top Rated mechanics, Connect spend, JSS, Boost-Profile.

For Toptal the audit pattern shifts to interview-prep + portfolio-presentation. For Fiverr it’s gigs + packages + tags. For Contra it’s services + spotlight project. I focus the free audit on Upwork specifically because that’s where I have first-hand sustained data — sticking to one platform makes the advice load-bearing instead of generic.

Skip if any of these apply:

• You’re looking for someone to run your account (apply on your behalf, ghost-interview, bid spam) — that’s a ToS violation and I won’t do it.
• You want a guarantee of N invites or X% rate raise — the audit gives you mechanics, not guarantees. Outcomes depend on your skill, market timing, and execution.
• You want to be told your profile is great without changes. The audit is opinionated and direct — if I think the hero is broken, I’ll say so.
• You’re on Upwork casually with no income goal — the audit assumes you want to be selected for higher-paying work.

I focus exclusively on Magento 2 (Open Source) and Adobe Commerce, paired with the Hyvä frontend theme. Services include custom module development, Hyvä theme builds and migrations, performance and Core Web Vitals optimization, third-party integrations (ERP, PIM, payment, shipping), B2B implementations, headless / PWA storefronts, and ongoing maintenance retainers. I am an Adobe Certified Magento Commerce Developer (certified 2023) and have shipped 200+ Magento stores and 60+ open-source extensions.

Project timelines vary based on complexity and scope. A simple theme customization might take 1-2 weeks, while a complex custom e-commerce solution could take 2-3 months. We provide detailed timelines during the project planning phase.

Yes! We work with clients worldwide. Our team is experienced in remote collaboration and uses modern communication tools to ensure smooth project execution regardless of timezone differences.

At $5M GMV, Magento Open Source is usually cheaper, but the gap isn’t as wide as Magento marketers claim.

Shopify Plus 3-year TCO at $5M: ~$2,300/mo licence floor (or 0.4% of GMV, whichever is greater) → ~$240k licence over 3 years. Add ~0.15% per-tx fee on Shopify Payments (or ~2% if using a 3rd-party gateway) → another $22k–$300k. App stack typically $400–$1,200/mo → $14k–$43k. Plus dev work — assume $30k–$80k. Total: ~$310k–$660k.

Magento Open Source 3-year TCO at $5M: $0 licence. Hosting (Cloudways / dedicated) $400–$1,500/mo → $14k–$54k. Initial build $25k–$80k. Ongoing dev $1.5k–$5k/mo retainer → $54k–$180k. Search / monitoring add-ons $200–$600/mo → $7k–$22k. Total: ~$100k–$340k.

Adobe Commerce changes the calculus — its licence at $5M is roughly $40k–$80k/yr, putting it in Shopify Plus territory. So if you’d need Adobe Commerce features anyway, Shopify Plus is competitive on price and wins on operational cost.

Yes — Shopify → Magento is a well-trodden path. Realistic numbers:

• Timeline: 8–16 weeks for a typical mid-market store. Faster (6 weeks) if catalog is small and design is preserved; longer (24+ weeks) if you’re also re-platforming PIM/ERP.
• Cost: $15k–$60k for a clean rebuild on Hyvä-themed Magento. Add $10k–$25k for ERP / OMS / loyalty re-integration.
• Risk: the three things that go wrong: (1) URL redirects miss long-tail product pages, dropping SEO 20–40% for ~6 weeks; (2) customer passwords don’t migrate (Shopify won’t expose hashes), so you have to force a reset email; (3) saved payment methods at the gateway need re-tokenisation.

Mitigation: run both stores in parallel for 30 days behind a feature flag, only flip DNS once the redirects map ≥98% of traffic and the new store has 30 successful test orders. The risk is real but quantifiable.

The key Shopify Plus features that move the comparison vs Magento:

• Shopify Functions / Scripts — server-side custom logic for checkout, discounts, payments, shipping. Plus-only. Replaces a lot of what apps used to do; competes with Magento’s native sales-rule + observer model.
• B2B on Shopify — companies, customer-specific catalogs, Net-30 — Plus-only and still has gaps (more on that in the next FAQ).
• Multiple expansion stores — Plus includes 9 expansion stores (extra orgs for different regions/brands) at no extra cost.
• Launchpad / Bulk Editor / Flow — automation for sales, inventory, fraud — closes the gap on Magento’s admin power.
• Higher API limits, dedicated support, Avalanche checkout

Plus pricing starts at $2,300/mo or 0.4% of GMV (whichever’s greater), with a hard floor and per-tx fees on top. The gap to regular Shopify Advanced ($399/mo) is significant — most of the Magento-vs-Shopify discussion at the upper-mid market is really Magento vs Shopify Plus.

Shopify Plus B2B has improved a lot since 2023 but still has real gaps vs Magento Adobe Commerce B2B:

• Quote workflow — Magento native (request-quote, negotiate, convert to order). Shopify B2B requires Plus + a third-party app (Sparklayer, B2B Wave) with limits on multi-step approvals.
• Requisition lists — Magento native, including "share with company" and recurring orders. Shopify can fake it with draft orders but no native UI.
• Tiered customer-specific pricing — Magento handles unlimited price tiers per customer + per SKU. Shopify B2B handles company-level price lists but tiered-by-quantity pricing per customer is awkward.
• Net-30 / payment terms — both support, but Magento allows custom terms per customer (Net-15, Net-45, Net-60); Shopify B2B has fixed buckets.
• Approval workflows — Magento allows multi-level (e.g. requester → manager → finance) approvals; Shopify B2B is single-level.

Verdict: if B2B is >30% of revenue with complex workflows, Magento wins. If B2B is <30% with standard "wholesale price + Net-30" mechanics, Shopify Plus B2B is now genuinely good enough.

Different architectures, different tradeoffs.

Shopify Markets (built into all plans, expanded on Plus): one storefront serving multiple regions with currency conversion, market-specific pricing, regional tax, geolocation, language toggling. Excellent for B2C brands selling the same catalog with regional pricing variants. Limitation: catalog is shared — you can’t hide products in one market without scripting.

Magento multi-store: one backend → N websites → N stores → N store views. Each axis can override catalog, pricing, tax, currency, language, payment methods, shipping. Truly independent storefronts sharing a single admin. Excellent for retailers selling different catalogs or running different brands; overkill for a single-brand 3-region store.

If you want Shopify Markets’ simplicity but with full per-region catalog control, Shopify Plus expansion stores cover that — but each is a separate org so you maintain N catalogs. Magento avoids that with a shared catalog and per-store overrides.

Rule of thumb: same catalog, different prices/languages → Shopify Markets. Different catalogs / brands / B2B-or-B2C-per-region → Magento.

Out-of-the-box: Shopify wins.

• Shopify (Dawn theme, no apps): LCP ~1.8s, CLS ~0.03, INP ~150ms. Lighthouse mobile ~85.
• Magento Luma (default): LCP ~3.8s, CLS ~0.12, INP ~280ms. Lighthouse mobile ~45.

But with proper engineering, Magento beats Shopify:

• Magento + Hyvä theme (Tailwind + Alpine.js, no jQuery, ~95% less JS): LCP ~1.2s, CLS ~0.02, INP ~80ms. Lighthouse mobile ~95+.
• Shopify with 8+ apps installed (typical): LCP drifts to 2.5–3.2s as third-party scripts accumulate. Lighthouse drops to 60–70.

So the real comparison is: Shopify defaults are fast but degrade as you add apps; Magento+Hyvä takes 4–8 weeks to stand up but holds 95+ Lighthouse indefinitely because customization happens in your codebase, not in third-party scripts.

For Core Web Vitals as a SEO ranking factor in 2026, Magento+Hyvä is the better long-term bet for stores that will accumulate features over time.

Both can rank well. Different shapes of problem:

Shopify SEO strengths: fast defaults, automatic image lazy-loading, built-in sitemap, clean URL structure, automatic structured-data (Product, BreadcrumbList) on most themes. Weaknesses: forced /collections/ and /products/ URL prefixes, limited control over canonicalization, no native hreflang for multi-region (Shopify Markets sets it, but customization is awkward).

Magento SEO strengths: full control over URL structure, robust hreflang via store views or custom modules, custom canonical rules, JSON-LD structured data per page (with the right modules), built-in XML sitemap with priority/changefreq controls. Weaknesses: defaults need tuning (duplicate-content from layered nav, slow LCP on Luma) — out-of-box, Magento ranks worse than Shopify on technical SEO until you fix it.

In practice: a well-engineered Magento store outranks Shopify because you have more levers (URL structure, canonicalization, structured data, programmatic SEO at scale via category landing pages). A poorly-engineered Magento store loses to a default Shopify store. SEO advantage goes to whichever team puts in the work — neither platform wins this fight by default.

It cuts both ways.

Pro-Shopify: for ~80% of common features (loyalty, reviews, upsell, subscriptions, ERP sync, email capture), there’s a vetted app you can install in 10 minutes. Magento has ~5k extensions on the Adobe Marketplace + Github but quality varies wildly and most need a developer to integrate.

Pro-Magento: Shopify apps are a recurring tax — typical mid-market store runs 8–15 apps at $20–$200/mo each → $300–$2,000/mo in app fees, indefinitely. Magento extensions are usually one-time licence fees. Over 3 years, Shopify app spend often exceeds Magento dev cost.

The hidden cost on Shopify: apps inject JS that compounds. By the time a store has 12 apps, page-load is 30%+ slower than vanilla. Removing apps to fix performance breaks features. This is the most common reason Shopify Plus stores migrate to Magento at $10M+.

Verdict: app marketplace is a feature for the first 1–3 years. After that it becomes a liability if you’re not disciplined.

Honest framing:

Shopify (managed SaaS): 99.99% uptime SLA, auto-scaling for Black-Friday traffic, no DevOps work. Risk: if Shopify de-prioritises a feature you depend on (e.g. Audiences, Linkpop) it disappears with little notice. You can’t pin versions. Major checkout changes are pushed to all stores simultaneously.

Magento Open Source self-hosted: you own the stack — pick hosting (Cloudways, AWS, Hetzner), pick PHP version, pin Magento version, schedule upgrades when you want. Risk: you own incidents (DDoS, hosting outage, bot attacks, OS upgrades). Need either a competent dev or a $1.5k–$5k/mo retainer to keep it patched. Magento security patches must be applied within 30 days or you risk the Magecart-class breaches.

Adobe Commerce Cloud sits between: managed but pricey ($60k+/yr), with the platform-control of Magento but offloaded ops.

Pick Shopify if you don’t want to think about ops. Pick Magento Open Source if you have a dev team or retainer and value control. Pick ACC if you want managed Magento and have $60k/yr to spare.

Different scopes.

Shopify: handles PCI-DSS Level 1 compliance for you. Card data never touches your servers — it’s tokenised at Shopify Checkout. Your PCI scope is SAQ A (the easiest tier — basically a self-attestation that you don’t store/process/transmit card data).

Magento Open Source self-hosted: if you use a hosted gateway (Stripe Elements, Braintree Hosted Fields, Adyen drop-in), card data also never touches your servers — you stay in SAQ A territory. Cost: $0 extra.

Magento with on-server payment forms (rare these days, but Authorize.Net AIM and some legacy gateways): card data touches your server briefly. PCI scope jumps to SAQ A-EP or SAQ D, requiring quarterly ASV scans, annual penetration tests, and full PCI documentation. Cost: $5k–$25k/yr.

Verdict: as long as Magento store uses tokenized payment forms (which any modern build does), PCI burden is roughly equivalent to Shopify. PCI is not a real differentiator in 2026.

Both can — different paths.

Shopify ERP integration: mostly through middleware (Celigo, Workato, Boomi, MuleSoft) or app-store connectors (e.g. Alumio, Patchworks for NetSuite). Pros: connector vendor handles the schema diffs and auth refreshes. Cons: middleware costs $400–$2,500/mo indefinitely, and custom field mappings often require a service-desk ticket. Real-time sync is rare; most are 5-min batches.

Magento ERP integration: direct API integration is the norm. Magento’s REST + GraphQL APIs cover orders, customers, inventory, products. Custom modules can expose ERP-specific webhooks. Pros: no middleware tax (one-time $20k–$80k dev cost), real-time sync is achievable, full control over data shape. Cons: you own the integration — when SAP changes its IDoc format you’re the one fixing it.

Rule of thumb: under $5M GMV with standard ERP setups → Shopify + middleware is faster. Above $5M with complex SKU master data, multi-warehouse inventory, or IDoc-based SAP → Magento direct integration is more reliable and 3-year-cheaper.

Both punt to specialised services for serious multi-jurisdiction tax. The differences are in how easy that integration is.

Shopify: built-in tax engine handles US sales tax (with Shopify Tax — $0.99 per US order on top of standard fees), EU VAT (manual config), UK VAT, Canadian GST/PST. For more complex setups (marketplace facilitator rules, tax-exempt B2B customers, multiple US states), the standard path is Avalara or TaxJar — both have first-party Shopify apps.

Magento: built-in tax-rate / tax-rule engine is more flexible (per-region, per-customer-group, per-product) but requires more configuration. For automated rate updates and economic-nexus tracking, integrate Avalara, TaxJar, or Vertex via the official Adobe-Marketplace extensions. Magento also natively supports tax-exempt customer groups (rare in Shopify B2C, native in Shopify B2B).

EU VAT specifically: Magento handles distance-selling thresholds, OSS reporting, and B2B reverse-charge natively. Shopify needs a 3rd-party (Vatify, Quaderno) for OSS / reverse-charge.

Verdict: for US-only retailers, Shopify Tax + Avalara is the fastest path. For EU + cross-border B2B, Magento + Avalara is more flexible.

Closer than the brochures suggest. Real numbers from 8 enterprise migrations in this band:

Shopify Plus 3-year TCO at $50M: Plus baseline $2,300/mo OR 0.4% × $50M = $200k/yr (whichever is greater — at $50M the GMV-based fee bites) → $600k+ over 3 years. Per-tx fees ~$75k/yr on Shopify Payments (0.15%) → $225k. 8–12 Plus apps at $1–5k/mo each (Klaviyo, Gorgias, Yotpo, Rebuy, Loop, Postscript, Shipstation, Avalara, Sparklayer for B2B) → $300k–$1.8M. Plus dev / agency $200–500k. Total: $1.3M–$2.9M.

Adobe Commerce 3-year TCO at $50M: AC license tier at $50M GMV is roughly $80–150k/yr (revenue-banded) → $240–450k. Adobe Commerce Cloud infra $50–80k/yr → $150–240k. In-house dev team (3–5 engineers) or agency on retainer over 3 years → $400–900k. Plus extension licenses + monitoring + search add-ons $50–100k. Total: $840k–$1.7M.

AC usually wins TCO by ~$200–800k once you account for Plus app multipliers — but the Plus number is more predictable. AC is cheaper if you run lean; more expensive if you don’t. The TCO winner is whichever platform fits your org without forcing it to grow into the cost.

Both have "Companies" but they solve different procurement realities.

Shopify Plus B2B Companies (released 2023, mature in 2024-25):

• Wholesale-account abstraction — one Company has many buyers
• Tag-based catalog visibility (which products show to which Company)
• Custom price lists per Company
• Draft Orders as quote workflow (single-step approval)
• Net-30 / Net-60 buckets on payment terms
• B2B account hub for self-service reorders

Best for D2C-flavored B2B — wholesale tier where the buyer experience mirrors retail. Strong fit for beauty / apparel / CPG brands selling wholesale to boutiques.

Adobe Commerce B2B Companies (mature since 2018, deepened in 2024):

• Multi-buyer roles per Company (Admin / Buyer / Approver / Junior Buyer)
• Multi-level approval chains (requester → manager → CFO, with $-threshold routing)
• Negotiable Quotes — full RFQ workflow with line-item negotiation, PDF export, version history
• Requisition Lists — recurring orders shared across the Company team
• Customer-segment catalogs — different SKU sets per Company segment
• Per-buyer credit limits + per-buyer payment terms (Net-15 / Net-45 / Net-60 mixed)
• Punchout (OCI / cXML) integration to Coupa / Ariba / SAP SRM

Best for procurement-style B2B — industrial distribution, food-service, MRO, B2B SaaS reseller channels.

Verdict: if your buyer journey involves a quote-to-order cycle longer than 24 hours, multi-buyer roles per company, or punchout integration to procurement systems, AC wins by a wide margin. If your B2B is wholesale-with-self-service, Plus B2B is now genuinely good.

This is the deepest architectural difference. It bites brands with non-standard checkout flows.

Shopify Plus checkout = Shopify Functions:

• Three function types: cart-and-checkout-validation, discount, delivery / payment customization
• Written in Rust or JavaScript, sandboxed, deployed via Shopify CLI
• Sub-50ms execution budget, runs on Shopify infra
• Powerful for: tiered discounts, conditional shipping rates, fraud blocks, B2B PO entry, custom payment routing
• Bounded: can’t add a custom field beyond what Checkout Editor exposes, can’t add a step, can’t reorder steps, can’t change checkout layout beyond Editor blocks, can’t hold-and-resume across sessions, can’t do server-side data lookups longer than 5ms

Adobe Commerce checkout = full Magento module:

• Override Knockout or Hyvä checkout entirely
• Add steps, add custom fields with validators, route based on cart contents
• Integrate ERP-driven shipping rates (live SAP query)
• Surface customer-credit balance live, hold-and-resume checkout across days
• Multi-warehouse split shipping with per-warehouse stock allocation
• Sample-cart workflows (free sample + paid item in same cart with separate fulfillment)
• No execution time limit — anything PHP can do

The Plus ceiling is real. Brands with subscription + one-time-buy mixed, B2B PO entry, multi-warehouse split-shipping, or sample-cart workflows hit it within 6 months. If checkout is your competitive advantage (or part of your B2B procurement integration), Adobe Commerce. If checkout fits the Shopify-Editor-plus-Functions model, Plus is faster to ship.

Different architectures for different problems.

Shopify Plus Markets: single storefront serving multiple regions. Currency conversion, market-specific pricing tweaks, regional tax, geolocation, language toggling. Best for: same brand, same catalog, different pricing/language per region. Tradeoff: catalog is shared — hiding products per market requires Markets-aware tagging or scripting. Works great for D2C brands with one catalog and 4-region pricing.

Plus multi-org / expansion stores: Plus includes 9 separate orgs, each its own admin / catalog / theme / staff accounts. Closer to true multi-store but at the cost of maintaining N catalogs in parallel (a SKU change has to propagate across orgs). PIM (Akeneo / Shopify Pro Sync) helps but adds tooling.

Adobe Commerce native multi-store: 1 codebase / 1 admin → N websites → N stores → N store views. Each level can independently override catalog (selective), pricing, tax rules, currency, language, payment methods, shipping methods, customer groups, even product attributes. Best for: retailers running different brands per region, B2B-and-B2C-per-region, fundamentally-different catalogs per market.

Real-world rule: 1 brand, same catalog, 4+ regions, region-specific pricing → Plus Markets is faster (3-month build vs 6-month). 1 brand, different catalogs per region OR B2B-and-B2C-per-region → AC saves the catalog-duplication tax indefinitely. Multi-brand parent company with 3+ brands → AC wins on shared infra. Hybrid — Plus Markets for the consumer brand + AC for B2B catalogs — is real at $100M+ but operationally heavy.

Both directions are well-trodden. Realistic enterprise numbers:

Shopify Plus → Adobe Commerce (most common at the $25M+ B2B band):

• Timeline: 9–15 months from contract to DNS flip. Catalog migration 4–6 weeks, B2B re-architecture 6–10 weeks, ERP / OMS / PIM re-integration 8–12 weeks, theme + checkout build 12–20 weeks, parallel-run + redirects 4–8 weeks.
• Cost: $300k–$1M for the build + $100–250k for ERP / OMS re-integration + $50–150k for first-year ops retainer. Total Year-1 outlay: $450k–$1.4M.
• Risk: URL redirects miss long-tail pages (drop SEO 15–30% for 6–8 weeks if redirects are sloppy); Shopify customer passwords don’t migrate (force reset); Shopify-app data (Klaviyo events, Yotpo reviews, Loop subscriptions) needs a separate migration plan. Subscription customers often need re-tokenization at the gateway.

Adobe Commerce → Shopify Plus (common when an AC store has outgrown its dev capacity):

• Timeline: 6–10 months. Faster than the reverse because Plus is more opinionated — less custom architecture to rebuild.
• Cost: $150k–$500k for the build + $50–150k for ERP re-integration via middleware + Plus license year-1.
• Risk: AC custom logic (Magento_Sales overrides, complex price rules, custom B2B workflow) often doesn’t fit Functions — re-scope or accept reduced functionality. Multi-store catalogs collapse to a single Markets store or expansion-store cluster.

Run both stores in parallel for 30–60 days behind a feature flag. Flip DNS only when the redirect map covers ≥98% of traffic, 50+ test orders pass on the new platform, and the support team has handled 5+ real customer issues on the new stack.

For non-Adobe shops: not really. For Adobe shops: significantly.

If you’re already running Adobe Analytics + Target (or AEM, or Real-Time CDP), Adobe Commerce’s native integration is a 3–6-month head start:

• Shared identity layer — no separate ID stitching
• Shared data layer — Analytics events fire from AC without a Tealium/GTM-style mapping layer
• Server-side personalization via Adobe Target on category / product / cart pages, native (not via 3rd-party connector)
• AEM Assets as the DAM for product imagery — no separate sync job
• Adobe Sensei AI for product recommendations + search + customer segmentation, native
• Real-Time CDP unified profile across web / app / email / paid media, native

This saves $200–500k in middleware / integration work + $30–80k/yr in ongoing connector / sync-tool fees.

If you’re NOT in the Adobe stack: the integration depth doesn’t matter — you’d be paying for Adobe Experience Cloud licenses you wouldn’t use. Shopify Plus integrates the Shopify ecosystem natively (Shopify Audiences for Meta/Google ads optimization, Flow for automation, Inbox for chat, Shop App for retention, Shop Pay) which is increasingly comparable in breadth to Adobe’s for D2C use cases.

Verdict: if you’re already an Adobe shop, AC’s integration is a quiet but expensive-to-replicate advantage. If not, this row is neutral — pick on B2B / customization / TCO instead.

Plus Academy is genuinely good. The app ecosystem is the bigger story.

Plus Academy = curated playbooks, certified-partner directory, dedicated Merchant Success Manager, quarterly business reviews, peer cohort access. For marketing-led ops teams, the playbooks (BFCM prep, growth experiments, replatform checklists) are 6–12 months of pattern-matching condensed into reference docs. Worth ~$30–80k/yr of consulting equivalent.

Plus apps are more nuanced:

• Pro: for ~80% of common features (loyalty, reviews, upsell, subscriptions, ERP sync, email, SMS, helpdesk), there’s a vetted app installable in 10 minutes. AC has ~5k extensions on the Adobe Marketplace + GitHub but quality varies wildly and most need a developer.
• Con: Plus apps are a recurring tax. A typical $50M Plus brand runs 8–12 apps at $1–5k/mo each → $100–600k/yr in app fees, indefinitely. Top of stack: Klaviyo $1k+/mo, Gorgias $500–2k/mo, Yotpo $500–2k/mo, Avalara $300–1k/mo, Sparklayer (B2B) $500–2k/mo, Loop / Recharge $300–1k/mo, Rebuy $500–2k/mo. Add custom Plus dev on top for things not covered.
• Hidden cost: apps inject JS that compounds. By 12 apps, page-load is 30%+ slower than vanilla. Removing apps to fix performance breaks features. This is the most common reason Plus stores migrate to AC at $100M+.

Verdict: Plus Academy alone is worth the Plus license at $50M+. The app ecosystem is a feature for years 1–3, a liability after that if you’re not disciplined about app curation.

Both can hit Lighthouse 90+ at $50M scale. Different paths.

Shopify Plus performance characteristics:

• Out of box (Dawn or Plus theme, vanilla): LCP ~1.8s, CLS ~0.03, INP ~150ms, Lighthouse ~85 mobile
• With 8–12 Plus apps installed (typical $50M brand): LCP drifts to 2.5–3.5s, CLS 0.08–0.15, Lighthouse 60–75 mobile — third-party scripts compound
• Hydrogen (Shopify’s React-based headless): LCP ~1.3s if engineered well, but adds an entire ops team to maintain
• Built-in CDN, image lazy-loading, automatic Brotli compression — all defaults are good

Adobe Commerce performance characteristics:

• Out of box (Luma theme): LCP ~3.8s, CLS ~0.12, INP ~280ms, Lighthouse ~45 mobile — bad
• AC + Hyvä theme (Tailwind + Alpine.js, ~95% less JS than Luma): LCP ~1.2s, CLS ~0.02, INP ~80ms, Lighthouse 95+ mobile — beats Plus defaults
• AC + PWA Studio (headless): comparable to Hydrogen, similar ops overhead
• Performance depends on dev discipline: a $50M AC store with poorly-tuned cache hits Lighthouse 60. A well-tuned one hits 95.

Verdict for $50M+ brands: AC + Hyvä is the long-term performance winner because customization happens in your codebase, not in installable scripts. Plus is faster to start but degrades as the app stack accumulates. If Core Web Vitals is a top-3 SEO ranking factor for your category (apparel, beauty, electronics), AC + Hyvä is the safer 5-year bet.

Plus Launchpad is the velocity advantage marketing teams cite most often.

Shopify Plus Launchpad: schedule a launch event (BFCM, product drop, flash sale, brand collab) that flips theme + price rules + collection visibility + script tags + email sequences at a chosen moment, then reverts at end-time. Marketing schedules it via the admin UI, no engineering ticket. The countdown / activation / rollback is atomic — either everything flips or nothing does. For a marketing-led ops team, Launchpad turns Black Friday from "dev sprint" into "calendar entry".

Plus Bulk Editor: mass-update SKUs / prices / inventory across markets. Plus Flow: visual automation builder for ops (fraud-flag → manual review, low-stock → reorder, repeat-buyer → loyalty tag). Together these eat 60% of what an engineering team would otherwise be ticketed for.

Adobe Commerce Content Staging (AC-only feature, not in Magento Open Source): preview / schedule / launch content + price changes by date range, similar to Launchpad in concept but with sharper scheduling controls (per-store-view, per-customer-group, conditional). Combined with Page Builder, B2B Rule Engine, Magento Cron, and (with engineering) Adobe Target rules, AC can do everything Launchpad does. The activation curve is steeper — Content Staging is more powerful but less marketer-friendly out of the box.

Verdict: if your bottleneck is "marketing wants to ship a campaign and engineering can’t turn around fast enough", Plus wins on velocity. If you have a strong engineering team that can wire Content Staging + B2B rules + Target rules into Adobe Workfront, AC is at parity but with steeper org investment.

Both are managed, but with very different control profiles.

Shopify Plus (managed SaaS):

• 99.99% uptime SLA, contractually backed
• Auto-scaling for Black Friday / Cyber Monday peaks — handled by Shopify, no capacity planning needed
• Zero DevOps work — no patch schedule, no PHP version pinning, no infra monitoring
• Trade: you can’t pin versions. Major checkout / admin changes are pushed to all stores simultaneously. If Shopify deprecates a feature you depend on (Linkpop, parts of Audiences, etc.) it disappears with limited notice.
• Status page transparency, dedicated Plus SRE escalation

Adobe Commerce Cloud:

• 99.9% standard SLA, 99.99% on the Pro infrastructure tier
• Managed but configurable — pin Magento version, schedule upgrades, choose PHP version within supported window
• Three-tier infra: integration / staging / production, all auto-deployed via Git
• Built on AWS (East / West / EU regions), Fastly CDN included, ECE-Tools for orchestration
• Trade: ~$50–80k/yr for the infra alone (separate from the Adobe Commerce license tier). Managed but you still own deployment-time issues — bad code goes live, you debug it.
• Cloudflare Magento Edge + on-edge B2B caching available as add-ons

If you self-host AC (skip Adobe Commerce Cloud): hosting on AWS / Hetzner / Cloudways runs $400–3k/mo for $50M-scale infra. You own all DevOps. Need either a competent in-house team or a $3–10k/mo managed-Magento retainer. Magento security patches must apply within 30 days or you risk Magecart-class breaches.

Verdict: Plus wins on operational simplicity. Adobe Commerce Cloud wins on configurability (pin versions, control rollouts) but at higher cost. Self-hosted AC wins on cost flexibility but trades operational responsibility.

It bites earlier than most enterprise teams expect, and it compounds with the GMV-based license fee.

How the Plus fee structure stacks:

• License floor: $2,300/mo OR 0.4% of monthly GMV — whichever is greater. This kicks in above ~$575k/mo GMV ($6.9M/yr) where 0.4% × monthly-GMV exceeds the $2,300 floor.
• Per-transaction fee on Shopify Payments: 0.15% of GMV. This is on top of the standard interchange rate (~2.4% + 30¢), not instead of.
• Per-transaction fee on third-party payment gateways: 0.20–0.25% of GMV — even higher. Most enterprise stores use Shopify Payments to avoid this hit.

The math at $50M GMV: license = max($2,300/mo, 0.4% × $4.17M/mo) = $16.7k/mo = $200k/yr just for license. Per-tx fee 0.15% × $50M = $75k/yr extra. Combined Plus platform cost: ~$275k/yr, before apps + dev + Plus Academy.

The math at $100M GMV: license $33k/mo = $400k/yr. Per-tx $150k/yr. Combined: $550k/yr.

The math at $500M GMV: license $1.67M/mo... wait, no — the Plus 0.4% fee caps at $40k/mo (= $480k/yr) by negotiation in most enterprise deals. Per-tx 0.15% × $500M = $750k/yr. Combined post-cap: ~$1.2M/yr. AC license at $500M GMV is ~$300–500k/yr — usually cheaper at this band, but the gap narrows once you account for AC’s ops cost.

Negotiation tip: at $50M+ Plus contracts, the 0.4% GMV-based fee is usually the negotiation lever. Plus reps will cap it (typically at the equivalent of 12 months prepay) and bundle Plus Academy / dedicated Merchant Success. Push for the cap before signing.

Yes — usually a few dozen brands at any time, almost all $100M+. The pattern works but operationally it’s not for the faint-hearted.

The pattern (real, not aspirational):

• Shopify Plus powers the D2C consumer brand — fast campaigns, Launchpad, Plus apps for marketing tools, mobile-first checkout
• Adobe Commerce powers the B2B / wholesale operation — companies, negotiable quotes, requisition lists, multi-buyer roles, custom approval chains, ERP-driven pricing
• Shared backbone: ERP (NetSuite / SAP / Microsoft Dynamics) is the system of record for inventory + customers + orders. PIM (Akeneo / Pimcore) feeds product data to both platforms. Identity service (Okta / Auth0 / custom) for unified login if needed.
• Customer experience: usually visibly two stores. Some brands keep them on subdomains (shop.brand.com for D2C, b2b.brand.com for wholesale); others on entirely separate domains. SSO between them is rare — buyers usually treat them as separate channels.

What goes wrong:

• Two ops teams, two release cycles, two sets of integrations to maintain — operationally heavy
• Promotions / pricing / inventory consistency between the two platforms requires real engineering (PIM is necessary, not nice-to-have)
• Customer service teams need training on both UIs
• Reporting consolidation requires a separate BI layer (Looker / Tableau / Mode) — neither platform’s native reporting handles cross-platform views
• Total cost is roughly platform-A + platform-B + 30% integration overhead

When it’s justified: $100M+ GMV with a hard split between B2C (consumer brand requiring marketing velocity) and B2B (procurement-style with deep workflow needs). Below $100M, picking one platform and paying for engineering on the gaps usually beats hybrid TCO.

Examples: several large beauty / apparel / supplement brands run this pattern; rare in industrial / distribution where AC alone serves both motions adequately.

Both reach roughly the same destination — the path is different.

Adobe Commerce B2B (native): ships a Companies module with a parent → child → buyer hierarchy, role-based purchase thresholds (e.g. Buyer can place orders up to $5k, Approver up to $50k, Company Admin unlimited), and an approval workflow that routes a pending order through the right approver before it’s placed. Cost: rolled into the Adobe Commerce license at $30k+/yr.

Magento Open Source: covered by extensions — Mageworx Companies ($299 + 12mo support), Aitoc B2B Suite (~$899), or BSS Companies (free + paid tiers). Combine with Aitoc Quote Workflow ($299–$799) to fill the approval gap. Total: $1–3k one-time vs $30k+/yr for AC.

The honest trade-off: AC ships a more polished UI, vendor-supported upgrades, and 24/7 SLA. OS extensions cover ~85% of the feature set at 5% of the cost — the remaining 15% is mostly "nice-to-have" admin polish. For most wholesale stores under $10M GMV, OS + extensions is the right call.

The shipped pattern across 40+ B2B builds:

• Buyer side: add items to a cart → click "Request a quote" instead of checkout → quote enters "Submitted" state. Buyer can attach notes ("we need this delivered split across 3 warehouses").
• Sales-rep side: internal admin queue shows new quotes. Rep opens the quote, can edit line-item prices, add discount %, override shipping, attach payment terms (Net-30 / Net-45 / Net-60), set expiry (default 14 days). Quote moves to "Counter-offered".
• Buyer review: email link → sees revised quote with line-by-line price changes highlighted → accepts or counter-counters (limit 2 rounds typically).
• Conversion: "Accept" converts the quote to a placed order with the agreed price + payment terms locked in.

PDF generation: auto-generated on every quote save, with company logo, customer billing/shipping address, line items + per-line pricing, tax breakdown, payment terms in the footer, expiry date in red. Library: Dompdf or mPDF for Open Source; native module for Adobe Commerce.

Expiry rules: stale quotes (past expiry) flip to read-only; buyer can request re-quote which spawns a new draft pre-filled with the old line items at current pricing.

Net-30 isn’t a payment method — it’s a credit-extension contract. The Magento mechanics:

1. Customer-segment configuration: "Verified Wholesale" customer group has Net-30 payment method enabled; new buyers default to "Card-only" until verified by AR.
2. Order placement: buyer chooses "Net-30 / Invoice me" at checkout. Order is placed in "Pending Payment" state — no card charge.
3. ERP push: order webhook fires to NetSuite / SAP / Tally / Odoo as a Sales Order with terms = Net-30. Invoice is generated in the ERP at fulfillment, not in Magento.
4. Invoice tracking: ERP pushes back invoice number + due date to Magento (so the buyer dashboard shows "Invoice #INV-1234, due Dec 15"). AR aging stays in the ERP.
5. Payment received: ACH / wire / cheque hits the bank → AR marks paid in ERP → ERP webhook marks Magento order "Paid" → auto-emails buyer the receipt.
6. Dunning: ERP sends 7-day, 14-day, 30-day-overdue emails. If 60+ days overdue, customer-group moves back to "Card-only" until cleared.

Critical: the source of truth for AR is the ERP, not Magento. Magento just shows the buyer their invoice status — the finance team operates entirely in the ERP.

Surprisingly granular. Magento’s native pricing stack lets you layer:

• Customer-group prices: per SKU, per group (Bronze / Silver / Gold / Platinum). 4 prices for 1 SKU is trivial; we’ve done 24 groups on a paint distributor.
• Tier prices: per group, per quantity-bucket. e.g. Gold tier: $10 at 1–99, $9 at 100–499, $8 at 500+.
• Special prices: per SKU, per customer (not just group), with start/end dates. Useful for "this one big buyer gets $7.50 forever".
• Cart price rules: conditional discounts ("any 100 SKUs from category X = 10% off") layered on top.
• Shared-catalog pricing (Adobe Commerce only): a complete alternate price-list per company-account. Open Source approximation: customer-segment + cart rules.

The wholesale reality — a single SKU might have 12 different prices across your buyer base. Magento handles that; Shopify B2B price lists hit limits around 4–5 tiers.

Performance note: with >500 active customer-group prices per SKU, indexing slows. Mitigation: keep group count under 30, push customer-specific overrides to "special prices" instead of new groups.

Different problems, different tools.

Requisition lists are for SKU lineups buyers reorder manually but frequently. The classic example: a hospital procurement officer maintains a "Monthly cleaning supplies" list with 47 SKUs. They open the list, click "Add all to cart", review quantities, place the order. Native Magento feature (Adobe Commerce); via Wyomind or Mirasvit on Open Source.

• Buyer is in the loop on every order
• Quantities can vary each cycle
• Lineup itself can be edited / shared with co-workers ("share with Procurement team")
• Multiple lists per buyer is normal (one for cleaning, one for office supplies, one for janitorial)

Recurring subscriptions are for SKUs that auto-replenish without buyer involvement. Example: a cleaning-services company auto-receives 20 cases of paper towels every Monday. No order placement, no buyer action — just a charge + ship event.

• Fully automated — buyer is not involved per-cycle
• Quantities are fixed (or fixed with skip-this-month buttons)
• Cadence is fixed: weekly / monthly / quarterly
• Best for fast-moving consumables with predictable burn

Stack: Magesterix Subscriptions, Aheadworks Subscriptions, or custom (built on Stripe Subscriptions or Razorpay for India). Avoid building from scratch — subscription billing has 30 corner cases (failed cards, prorated upgrades, paused subscriptions, regional tax).

Rule of thumb: ~70% of wholesale stores need only requisition lists. ~20% need both. ~10% (heavy MRO consumables) lean subscriptions.

The honest list of what works in 2026:

• NetSuite: direct integration via SuiteScript + REST API. Connectors: Patchworks (mid-market, $400–$800/mo), Celigo Integrator.io ($600–$1,200/mo), Folio3 NetSuite-Magento connector (one-time + support). Custom-built: $20–$40k for a clean implementation. Real-time stock + price; near-real-time order push.
• SAP (S/4HANA, Business One): IDoc-based (legacy) or OData (modern). Connectors: Pixafy SAP-Magento, Boltic SAP, Alumio. Custom: $30–$60k due to schema complexity. Batch sync (every 5–15 min) is the norm; real-time is achievable but pricey.
• Tally: XML-over-HTTP integration (Tally’s native pattern). Connectors: tdlexpert.com Tally-Magento bridge, custom modules from Indian dev shops ($3–$8k). Strong India-market choice; pairs with Razorpay for NEFT/IMPS payment.
• Odoo: XML-RPC API. Connectors: Magemodule Odoo bridge, EmiproTech Odoo-Magento. Custom: $10–$20k. Good for SMB wholesalers who run Odoo ERP + Magento commerce.
• Microsoft Dynamics 365: OData / Dataverse APIs. Connectors: Sana Commerce (built specifically for Dynamics), e-bridge by CData. Custom: $25–$50k.
• Zoho Inventory / Books: direct REST. Connectors: SkyVia, Zapier (small scale). Custom: $5–$15k. Good for SMB.

Decision rule: if you’re under $5M GMV with standard SKU master, a connector + middleware is faster (4–6 weeks). Above $5M with complex multi-warehouse / multi-currency / IDoc-based SAP, custom direct integration is more reliable and 3-year-cheaper despite the higher upfront cost.

5,000 lines is the high end of normal; 12,000 lines is doable with care; 50,000 lines needs a bulk-order asynchronous queue.

• 0–500 lines: synchronous. Submit → validate → cart → checkout in <5 seconds. No special handling needed.
• 500–5,000 lines: still synchronous but with a progress bar. Validation runs in chunks of 200 SKUs at a time to avoid PHP timeout. Total time: 10–30 seconds. Stock + price checks happen before cart insertion.
• 5,000–12,000 lines: asynchronous. CSV uploads → queue job → user gets an email with a "review your prepared cart" link in 1–3 minutes. SKU validation, price-snapshot, and stock-availability happen in the background. Buyer reviews + submits.
• 12,000+ lines: custom queue + multi-batch order (split into 2–3 separate orders to keep the order_items table sane). Often combined with multi-warehouse splitting.

Validation pre-submit: always show buyers (a) which SKUs aren’t found, (b) which are out of stock, (c) which have price differences from their list. Letting them edit / remove problem rows pre-submit cuts post-order disputes 80%.

Anti-pattern: never run a 5,000-line CSV through Magento’s standard add-to-cart events — you’ll trigger the catalog-rule indexer 5,000 times. Use direct quote-item insertion bypassing event observers.

Region-specific. Each has a clear preferred path.

ACH (United States): via Stripe Payments (offers ACH Direct Debit + Plaid micro-deposit verification), Authorize.Net eCheck, or NACHA-compliant gateways like Forte. Stripe is easiest to integrate (official Magento module + 2-day verification). Authorize.Net is cheapest at scale (~$0.10 per transaction vs Stripe’s 0.8% capped at $5).

SEPA Direct Debit (EU): via Stripe SEPA, Mollie SEPA, GoCardless. Mollie has the strongest Magento module + SEPA mandate management. GoCardless is purpose-built for B2B recurring debits and has the best webhook reliability for failed-payment retries.

NEFT / IMPS / RTGS (India): via Razorpay, PayU, or HDFC FirstData. Razorpay has the most mature B2B flow — supports NEFT, IMPS, RTGS, and UPI for sub-500k INR transactions. Direct bank transfers for >500k INR with reconciliation via virtual account numbers.

Bacs (UK): via GoCardless or Modulr. GoCardless dominates here.

Reconciliation pattern: all bulk-payment methods are async — the order is placed in "Payment Pending" state, buyer sees the bank-transfer instructions or initiates the debit, payment confirmation comes back via webhook 1–3 days later, order moves to "Paid" and fulfillment kicks off. Build the UX around this delay — pretending it’s instant breaks trust.

Different shapes of business, not "Magento better" or "Shopify better".

Shopify Plus B2B wins when:

• B2B is <30% of revenue and you’re primarily D2C
• One buyer per company (no role hierarchy)
• Quote workflow is single-level approval at most
• Customer pricing is "wholesale price + Net-30" with no per-SKU complexity
• You don’t need real-time ERP integration (5-min Celigo batches are fine)
• Time-to-launch matters more than long-term flexibility

Magento wins when:

• B2B is >40% of revenue (or pure-B2B)
• Companies with multi-buyer roles + multi-step approval are common
• Customer-segment pricing has 5+ tiers or per-SKU per-customer overrides
• ERP integration is real-time-critical (NetSuite / SAP / Tally / Odoo)
• Bulk-order CSV (5,000+ rows) is a frequent buyer flow
• Requisition lists + recurring orders are core to retention
• You need ACH (US) + SEPA (EU) + NEFT (India) on the same store

The Shopify Plus B2B 2025 update narrowed the gap: companies, customer-specific catalogs, Net-30, draft orders all shipped. But the gaps that remain — multi-step approval, 24+ pricing tiers per SKU, real-time IDoc-based SAP integration, 5,000-row CSV with pre-submit validation — are the gaps that matter for serious wholesale.

Wholesale stores often need products that exist only for specific buyer-segments — restricted-use SKUs, OEM-only items, exclusive bulk packs, or trade-channel pricing that shouldn’t be visible to anyone else.

Magento Open Source mechanics:

• Customer-group product visibility: via Aitoc Customer-Segment Catalog or BSS Hidden Categories ($199–$499). Each product has a "visible to groups" flag — logged-out users + non-matching groups see a 404 or redirect to login.
• Category-level visibility: hide entire categories from anonymous + non-trade groups. Trade buyers see "Wholesale Only" subtree; everyone else doesn’t.
• Login-walled storefront: entire store requires login. New visitors see only a login page + "request trade account" form. Used by pure-B2B distributors who don’t want their catalog scraped or visible to retail customers.
• Per-company custom catalog (Adobe Commerce Shared Catalogs): each company-account gets its own catalog snapshot — SKUs they shouldn’t see are simply not in their feed.

SEO consideration: hidden trade catalogs should return HTTP 404 (not 403) for non-authorised users to stay out of Google’s index. Pair with robots.txt deny rules for the URL paths and a separate sitemap that excludes the trade-only sections.

Pricing visibility: a common ask — show product but hide price until login. Native cart-rule: "Display price = $0 / login to see" with a "Request quote" CTA replacing the price. Done with a small Hyvä template override.

Common path. Risk is real but quantifiable.

The typical custom-portal stack: Laravel / Django / Rails app + MySQL/Postgres + manual ERP scripts. Built 5–10 years ago, hard to hire for, no upgrade path, every new feature is a custom build. Maintenance is a tax on the dev team.

Migration plan (12–20 weeks):

1. Data audit (week 1–2): companies, buyers, customer-group pricing rules, requisition lists, open quotes, AR balances. Map to Magento entities — companies → B2B Companies module, buyers → customers, segment pricing → customer-group prices.
2. Feature parity matrix (week 2): what does the custom portal do that Magento doesn’t out-of-box? Build the gap list. Usually 6–12 items, 3–5 of which need custom modules.
3. Magento + extensions setup (week 3–5): base Magento, Hyvä theme, B2B extensions, ERP connector, payment gateways.
4. Custom-portal data export (week 6): SQL dumps + CSV exports of all customer + order + pricing data. Validate counts.
5. Magento data import (week 7–9): via dataflow / API / direct SQL. Spot-check 100 customers + 50 orders for accuracy.
6. Parallel run (week 10–14): both portals live. New orders go to Magento; old portal is read-only for AR / reporting. Buyers get a "we’ve moved" email + reset-password link.
7. Cutover (week 15): DNS flip. Old portal stays read-only for 90 days for any AR queries.
8. Stabilisation (week 16–20): bug fixes, buyer training, ERP sync tuning.

Risk hotspots: (1) password migration — you can’t move hashes if the algos differ; force a reset email at first login. (2) saved-card tokens — need to re-tokenise at the new gateway via account-updater service. (3) custom-portal-only URLs — build a redirect map covering >95% of indexed traffic before DNS flip.

Real ranges from 40+ shipped projects:

Greenfield Magento Open Source B2B (no migration):

• Timeline: 12–16 weeks build + 4 weeks stabilisation
• Build cost: $30k–$80k depending on segment-pricing complexity + ERP integration depth
• Extensions: $3k–$8k one-time (Companies, Quote Workflow, Subscriptions, etc.)
• Hyvä theme licence: $1,000 one-time
• Hosting: $400–$1,500/mo (Cloudways / dedicated)
• 3-year TCO: $80k–$200k

Migration from Shopify Plus / SAP Hybris / custom portal:

• Timeline: 16–24 weeks build + 4 weeks parallel run + 4 weeks stabilisation
• Build cost: $50k–$140k
• Data migration: $10k–$30k (companies, buyers, pricing, AR balances)
• ERP re-integration: $15k–$50k depending on system
• 3-year TCO: $130k–$320k

Adobe Commerce B2B (vendor-supported):

• Same build cost as Open Source + Adobe Commerce license $30k–$80k/yr based on GMV
• 3-year licence: $90k–$240k on top of build cost
• Pays for itself when (a) you’d need 24/7 SLA anyway, or (b) you’re >$10M GMV with full B2B usage

Below $5M B2B GMV: Open Source + extensions is the right call. $5–$10M: close call — depends on team. Above $10M: Adobe Commerce + Cloud often wins on operational cost despite the licence.

Cheapest B2B build that’s not a regret: $30k. Anything cheaper skips ERP integration or quote workflow and you’ll rebuild within 18 months. The honest floor.

Magento handles 50k+ SKUs cleanly when three things are tuned correctly: EAV indexing, Elasticsearch, and Hyvä. Without those, default Luma + MariaDB will start choking around 30k SKUs — category pages take 2–5 seconds, layered nav lags 1–2 seconds per filter click.

• EAV index: schedule the catalog_product_attribute + catalog_product_price + catalog_category_product indexers to "Update on Schedule" with a cron run every 1 minute. Avoid "Update on Save" at 50k+ — admin saves stall.
• Elasticsearch / OpenSearch: required from Magento 2.4+. Tune refresh_interval to 30s, allocate 4–8GB RAM. Re-index rate target: 50k SKUs in <10 minutes.
• Hyvä theme: replaces Luma’s 3MB+ JS with ~150kB Tailwind/Alpine. Catalog list-view renders 60% faster. INP drops from 280ms to 80ms on a 50k-SKU store.
• Hosting floor: 8 vCPU / 16GB RAM / NVMe SSD, Redis for cache + sessions, dedicated MariaDB or Aurora. Cloudways "Pro" plan or Hetzner CX52 minimum.

With those four in place, a 50k-SKU electronics store hits Lighthouse 90+ on category and product pages. I’ve shipped one with 78k SKUs that holds 95+ Lighthouse mobile.

Both work. Different shapes of fit:

Akeneo: dedicated PIM. Cleaner UX for product managers, attribute-set workflow is excellent, multi-language is mature. The Akeneo Magento Connector (official, paid) ships with attribute mapping, channel publishing, image syndication, and incremental sync. Setup: 2–4 weeks. Annual licence: $25k–$120k depending on SKU count + user seats. Pick Akeneo if: you have dedicated catalog managers, >5 product categories with different attribute schemas, and you want a tool built specifically for product data.

Pimcore: PIM + DAM + MDM in one platform. More flexible (you can model anything — products, customers, orders), open-source core with paid enterprise edition. The Pimcore Magento Bridge is community-maintained. Setup: 4–8 weeks (more flexibility = more configuration). Annual cost: free OSS + dev time, or $30k–$80k for enterprise edition. Pick Pimcore if: you also need a DAM (digital asset management for spec sheets, datasheets, certifications), or you want a single platform for product + customer master data.

For pure product data with strong workflow needs, Akeneo wins. For combined PIM + DAM at electronics distributors with thousands of datasheet PDFs, Pimcore wins. Both integrate cleanly with Magento — integrator skill matters more than the tool.

Magento MSI (Multi-Source Inventory, native since 2.3) handles N warehouses with a priority-and-rule-based algorithm:

1. Sources: define each warehouse + drop-ship vendor as a "source" with location coordinates, contact, enabled/disabled flag.
2. Stocks: define which sources serve which sales channels. E.g. EU stock = "Berlin warehouse + Rotterdam warehouse + drop-ship vendor X". US stock = "Dallas warehouse + drop-ship vendor Y".
3. Reservations: when an order is placed, MSI reserves inventory logically (without decrementing source qty) until the order ships. This prevents oversells across concurrent orders.
4. Source selection algorithm (SSA): at fulfillment time, MSI picks the source(s) by priority (lowest priority number wins), distance from shipping address, and stock-availability rules. Native algorithms: "priority" (use the highest-priority source first), "distance" (use closest source). Custom algorithm via plugin: weighted score — e.g. Dallas first if >30 SKUs in stock, drop-ship vendor only if Dallas + Reno are out.

Common gotchas: (1) SSA is slow on category pages with 50k+ products — use cataloginventory_stock_status indexer with "Update on Schedule"; (2) drop-ship vendors should be flagged as "use stock from external source" so qty doesn’t drift; (3) partial-shipment splits work but require checkout customization to show "ships from 2 warehouses" to the customer.

Three real options at different price points:

Channel Advisor (now Rithum): enterprise marketplace integrator. Magento extension, syncs inventory + orders + listings to Amazon, eBay, Walmart, Newegg, Wayfair, Google Shopping. Strengths: bulletproof at $100M+ GMV, mature dispute / reconciliation tools, repricer included. Weakness: enterprise pricing — $30k–$200k/yr depending on GMV. Pick at >$10M marketplace GMV.

Codisto (now Shopify-owned but still has Magento connector): mid-market. Real-time inventory + order sync, listing builder, decent multi-region support. $200–$2,500/mo depending on plan + SKU count. Weakness: Newegg + Walmart support is thinner than Amazon/eBay. Pick at $1M–$10M marketplace GMV.

M2E Pro (free + paid editions): Magento-native open-source extension. Free for Amazon/eBay basic, $500–$2k/yr for advanced features. Strengths: deep Magento integration, no per-SKU fees. Weakness: needs more in-house ops attention than the SaaS tools. Pick at <$1M marketplace GMV with in-house Magento expertise.

Custom (direct API): build directly against Amazon SP-API + eBay API. Justified only at >$50M marketplace GMV with weird requirements (multi-account, complex SKU mapping, custom repricer). Build cost: $80k–$200k. Don’t pick this lightly.

This is Magento’s home-court advantage. One backend, two storefronts (or one storefront with logged-in B2B switching), fully separated pricing and catalogs.

• Customer groups: create "Wholesale Tier 1", "Wholesale Tier 2", "Distributor", "Reseller" customer groups. Each group gets its own price tier per SKU.
• Shared catalogs (Adobe Commerce B2B): assign different SKU subsets to different customer groups. E.g. distributors see professional-only SKUs that B2C never sees.
• Companies + buyer roles: B2B customers belong to companies with multi-buyer / multi-approver / company-admin roles. Native in Adobe Commerce; available via Aheadworks / Mageplaza B2B in Open Source.
• Quote workflow: distributor requests a quote, sales rep reviews, multi-step approval, converts to order. Native Adobe Commerce. Aheadworks "B2B" for Open Source.
• Net-30 / payment terms: per-customer terms (Net-15, Net-30, Net-60). Adobe Commerce native; Open Source via Mageplaza Payment Terms ($199 one-time).
• Tax exemption: per-company resale certificates, tax-exempt customer groups, integration with Avalara / TaxJar for cross-state US distributor tax.

The B2C storefront stays clean — consumers never see distributor pricing or trade-only SKUs. Logged-in B2B users automatically see their tier prices, requisition lists, and quote tools without a separate URL.

Magento has native product compare (the "compare" button on PDP / category) but it’s minimal — basic side-by-side with first-level attributes. Electronics shoppers expect richer comparison.

Native + theming: Hyvä compare module + custom layout for the compare-page renders all 30+ attributes per attribute set in a sticky-header table. Free, but needs ~3–5 days of theming work.

Extensions (in order of fit):

• Mirasvit Advanced Product Compare ($199): adds multi-set comparison, attribute grouping (display "Display" attributes together, "Battery" attributes together), sticky-header on long tables, share-comparison-by-link. Mature, well-supported.
• Magefan Better Compare ($129): lighter alternative, AJAX-based, mobile-optimised. Good for B2C electronics.
• Mageworx Advanced Compare ($249): includes "compare with" widget on PDP, "frequently compared together" recommendations. Adds a B2C upsell angle.

For high-end electronics (cameras, laptops, networking gear) Mirasvit + Hyvä is the standard combo. The compare table itself is also a SEO landing-page candidate — Google ranks "X vs Y" comparison URLs, so structure your compare-by-URL pattern with proper canonicals.

Three patterns, each with tradeoffs:

1. Custom attribute (file type): add a "Datasheet PDF" file attribute to the relevant attribute sets. Upload via admin or sync from PIM. Render as a download button on PDP with download tracking via Google Analytics event. Simplest, free. Limitation: one file per SKU per attribute — not great for products with multiple datasheets, certifications, manuals.
2. Magento Downloadable Product: gated downloads (require login) for warranty registrations or pro-only datasheets. Built-in but heavyweight — the SKU itself becomes "downloadable" rather than a physical product, so this conflicts with main electronics SKU type.
3. DAM + relations (Pimcore / Akeneo): store all PDFs in the PIM/DAM with relations to SKUs (one product → multiple files: datasheet, manual, warranty card, certification). Sync the metadata to Magento, link to the PDF served from PIM/DAM via signed URLs. Best at scale — 50k SKUs × 5 docs = 250k files, which Magento media folder doesn’t love.

SEO bonus: every datasheet PDF should have a clean URL (/datasheet/{sku}-{slug}.pdf), correct Content-Disposition (inline for browser preview), and JSON-LD on the parent PDP linking back to the datasheet as a DigitalDocument. Google indexes PDFs — they drive long-tail traffic to electronics pages.

The market is mature. Three serious options:

Mirasvit RMA ($349 one-time + optional support): full self-service portal, custom return reasons, multi-step approval workflow, return label generation (ShipStation / Shippo integration), repair tracking, refund/exchange/store-credit decisions, customer email automation. Used by 5,000+ stores. Most mature. Pick if RMA volume is 5%+ of orders and you want a polished customer-facing portal.

Mageworx RMA ($299 one-time): similar feature set, slightly less polished UX but cleaner admin. Good fallback if Mirasvit doesn’t fit.

Aheadworks RMA ($349 one-time): tightly integrated with Aheadworks B2B suite if you’re already on that. Strong on B2B return workflows (PO-based returns, distributor reverse logistics).

Extended warranty: separate concern. Two patterns:

• Magento product type "Warranty Plan" + Mageworx Product Warranty ($199): customer adds a warranty plan SKU at checkout. Magento tracks the relationship. Manual claim handling.
• Extend / Clyde / Mulberry third-party warranty providers: turnkey API integration, they handle the underwriting + claims. You get a revenue share. Best for B2C electronics where warranty is a margin-driver.

RMA + extended warranty are 5–15% of post-sale touch in electronics. Get this stack right or lose 0.5–1.5% of margin to bad ops.

Target: <200ms search response time at p95, <100ms layered-nav filter response. Achievable with:

• Elasticsearch / OpenSearch: required since Magento 2.4. Run a dedicated cluster (not co-located with MariaDB) at 4–8GB RAM minimum, NVMe storage. Single-node is fine to ~250k SKUs; shard to 3 nodes above that.
• Searchable attribute curation: not every attribute should be searchable. Review the catalog_eav_attribute.is_searchable flag — turn off "Cost", "Width Map" etc. that customers don’t search. Fewer searchable attributes = faster index + faster query.
• Layered nav indexing: catalog_product_attribute + catalog_search indexers on cron, not on save. Re-index 50k SKUs in 8–12 minutes nightly.
• Synonyms + boost rules: configure synonyms (e.g. "WiFi" / "Wi-Fi" / "wireless networking") in admin → Stores → Search Synonyms. Boost rules promote in-stock + high-margin SKUs.
• Hyvä autocomplete: replace Magento’s default suggest with Hyvä-native autocomplete — ~200ms keystroke latency vs Luma’s 600ms+.
• Optional: Algolia / Klevu / Searchspring — SaaS search overlay. $200–$2,500/mo. Worth it at >100k SKUs or when on-site search is a primary conversion driver. They handle relevance tuning, NLU, personalization out of the box.

For a typical 50k-SKU electronics store, vanilla Magento + Elasticsearch + Hyvä is enough. Add Algolia/Klevu only if the data shows search is a top-3 conversion driver.

For electronics, the platform decision is sharper than for apparel or general retail because of SKU scale, attribute richness, B2B distribution, and warranty workflows.

Shopify Plus wins for electronics when: catalog is <5k SKUs (cameras, audio, speciality electronics brands), pure D2C with no distributor channel, single warehouse, single language, marketplace presence is "Amazon only or none". E.g. a boutique audio brand selling 200 SKUs to consumers. Shopify Plus + a few apps gets to live in 6 weeks at $30k–$60k all-in.

Magento wins for electronics when: catalog >10k SKUs (computer components, IT distribution, consumer electronics retail), multi-warehouse or drop-ship blend, B2B distributor share >20%, multi-marketplace mandatory, PIM integration required. E.g. an IT distributor with 80k SKUs across 4 warehouses, 30% B2B revenue, listings on Amazon + Newegg + eBay. Shopify Plus would need 12+ apps stacked together at $1.5k–$3k/mo + custom dev to fake what Magento does natively. Magento + Hyvä build: 12–20 weeks, $80k–$200k. Pays back in 18 months on app fees alone.

Specific Shopify Plus gaps for electronics: (1) attribute-set inheritance is awkward — managing 30+ specs per SKU across 12 categories means metafield sprawl; (2) MSI equivalent (Shopify Locations) is shallower — no native source-priority rules; (3) B2B is improving but distributor-tier pricing + Net-30 + multi-step approvals still hit limits; (4) marketplace sync requires app stack ($300–$2k/mo) where Magento has direct integrators with deeper feature sets.

Yes — Hyvä is actually better suited to catalog-heavy stores than to brand-storytelling stores, despite the marketing focus on the latter.

Why: Hyvä replaces Luma’s ~3MB of JS (jQuery + RequireJS + KnockoutJS + UI components) with ~150kB of Tailwind + Alpine.js. On category pages with 60 product cards (typical electronics listing), this matters compounds — LCP drops from 3.8s to 1.2s, INP from 280ms to 80ms, and the browser stays responsive while scrolling. On catalog-heavy stores, page weight is the dominant performance variable, not template complexity.

Real numbers from a 60k-SKU electronics build I shipped in 2025:

• Lighthouse mobile: 96 (homepage), 94 (category), 92 (PDP).
• LCP: 1.1s mobile, 0.7s desktop (75th percentile, real-user data).
• CLS: 0.02 (well under the 0.1 threshold).
• INP: 78ms (well under the 200ms threshold).

Caveats: (1) Hyvä is a paid theme (€1,000 one-time per project licence + extension licences) — budget for it; (2) some legacy extensions don’t have Hyvä compatibility patches — check your stack before committing; (3) PWA Studio / pure-headless is overkill for 99% of electronics stores — Hyvä gives 95%+ of headless performance with 30% of the build cost.

Verdict: Hyvä is the default for new Magento electronics builds in 2026. Skip Luma.

Realistic ranges by SKU + complexity tier:

Tier 1: 2k–10k SKUs, single warehouse, B2C-only, Amazon only

• Build: 10–14 weeks. Cost: $35k–$70k.
• Stack: Magento Open Source + Hyvä + M2E Pro (marketplace) + Mirasvit RMA + simple PIM (or no PIM if catalog stable).

Tier 2: 10k–50k SKUs, 2–3 warehouses, 20–40% B2B share, Amazon + eBay

• Build: 14–20 weeks. Cost: $80k–$160k.
• Stack: Magento Open Source + Hyvä + Codisto (marketplace) + Akeneo PIM + Aheadworks/Mageplaza B2B + Mirasvit RMA + MSI configuration.

Tier 3: 50k+ SKUs, 4+ warehouses, >40% B2B distribution, Amazon + eBay + Newegg + Walmart

• Build: 20–32 weeks. Cost: $180k–$400k.
• Stack: Adobe Commerce (native B2B) or Magento OSS + Aheadworks B2B suite, Hyvä, Channel Advisor (marketplace), Akeneo or Pimcore enterprise, Mirasvit RMA + Extend warranty integration, custom MSI source-selection algorithm, ERP integration (NetSuite / SAP).

Hidden costs to budget for: (1) data migration from current platform — $5k–$25k depending on data quality; (2) URL redirect map — critical for SEO continuity, $3k–$10k; (3) ERP / OMS integration — $15k–$80k; (4) ongoing retainer — $2k–$10k/mo for keeping the stack patched + iterating.

I quote fixed-fee for Tier 1 + Tier 2; Tier 3 is time-and-materials with weekly check-ins because surprises are inevitable.

Furniture configurators are deeper than fashion variants but Magento handles them cleanly with the right pattern.

Schema: use Magento configurable products for the primary axis (typically dimension or model) and Custom Options for the secondary axes (fabric, finish, hardware, leg style). Bundle products handle multi-piece sets (e.g. sectional with 4-5 modules). EAV attributes hold the swatch metadata.

Visual swatch picker: the default Custom Options dropdown is unusable for fabric. Wire in a UI extension (Mageworx, Aheadworks Advanced Product Options, or a custom React widget on Hyvä) that renders fabric thumbnails, hover-to-zoom, and a “swatches by mail” CTA.

Validation rules: not every fabric ships on every frame. Use option dependencies (e.g. via the same extension or a custom rule engine) to disable invalid combos in real time.

Scale: 1,000+ valid permutations per product family is achievable. I’ve shipped a custom-sofa configurator with 4,200 valid combinations and a 1.8s LCP on Hyvä. Below 100 SKUs you can fake it on Shopify; above 500 SKUs with 3+ axes, Magento is the answer.

Three integration options, ranked by furniture fit:

• FreightCenter API — the most furniture-friendly. Pulls live LTL rates from XPO, ABF, R+L, FedEx Freight, YRC. Handles white-glove + room-of-choice + threshold delivery as line-item upsells. Good account-rep support. Most furniture brands settle here.
• uShip — marketplace model (carriers bid). Cheaper rates but slower quote turnaround (1-3 hours, not real-time). Better for very-large items where a marketplace bid beats a contract rate. Pair with FreightCenter for instant quotes + uShip fallback.
• Roadie (UPS-owned) — gig-economy local + regional. Excellent for last-mile + same-day in metro areas. Doesn’t replace LTL for cross-country — supplements it.

Integration shape: Magento shipping-method extension calls the carrier API on cart at the freight-quote step. White-glove / assembly / liftgate are separate SKU line items added by the customer (not bundled into the freight rate). Liftgate-required ZIP codes auto-toggle the line item. Real-time API call adds 1.5-3s to the cart, so cache aggressive on identical zip+weight combos.

Yes, and it’s the single biggest CX investment for made-to-order furniture.

PDP message: a per-product lead_time_min_weeks + lead_time_max_weeks attribute drives the “ships in 6-8 weeks” copy. Custom upholstery: 10-14 weeks. In-stock: “ships in 2-3 days.” The number is dynamic — pulled from inventory + production calendar — so it stays accurate.

Production milestones: custom order-status extension (or a custom workflow in sales_order with a state machine) tracks the stages: Order received → Materials cut → Frame built → Upholstery in progress → QC → Shipped → Out for delivery. Customer sees a progress bar on the order-tracking page. Each stage triggers an email (“your sofa is in upholstery this week”) which reduces support tickets ~40% in the data I see.

Outbound visibility: ShipStation or Shippo handles the LTL handoff and surfaces tracking once the carrier picks up. For white-glove deliveries, the carrier’s appointment-scheduling portal (XPO Connect, ABF’s scheduler, or Metropolitan’s app) gets embedded into the order-tracking page so the customer schedules their delivery window without phoning support.

Treat each delivery service as a separate line-item SKU with its own price logic, not as a freight-rate add-on.

• Curbside delivery — carrier drops at the curb. Default for LTL. No extra SKU.
• Threshold delivery — carrier brings to the front door / threshold. SKU price ~$50-$150.
• Room-of-choice — carrier places in the customer’s chosen room. SKU price ~$100-$250.
• White-glove — room-of-choice + unpack + debris removal. SKU price ~$200-$500.
• White-glove + assembly — full setup, includes furniture build + light installation. SKU price ~$300-$800 depending on complexity.

UX: a delivery-options widget on cart (above the freight quote) lets the customer pick the tier. Each tier adds the corresponding line-item SKU. The freight quote stays separate and doesn’t re-fetch when the customer changes tier (the SKUs are virtual / non-shipping).

Carrier coordination: the back-end fulfillment system tags the order with the chosen tier and routes to the right carrier (e.g. Metropolitan / Pilot for white-glove networks). Margin on white-glove is typically 30-40% — meaningful revenue, not a cost center.

Three serious vendors, different fits:

• Cylindo — furniture-specialist. Built for sofa / chair / casegoods configurators. Auto-generates 360-degree spins from 3D models, supports fabric/finish swap in real time, integrates with most configurators including Magento. Premium pricing ($1.5k-$5k/mo). Best fit for medium-large furniture brands.
• Threekit — broader (furniture, jewelry, apparel). Powerful 3D + AR + product configurator unified platform. Steep learning curve + higher TCO. Best fit for brands wanting one vendor for both visualization + configurator (replacing Magento Custom Options entirely).
• Sketchfab — cheapest entry point. Great for static 3D model viewer + iOS Quick Look + Android Scene Viewer integration via <model-viewer> Web Component. No real-time configurator overlay. Best fit for <100 SKU brands wanting AR-on-PDP without the Cylindo / Threekit budget.

Implementation: all three plug into Magento via product attribute holding the 3D model URL or vendor SKU. Front-end loads the viewer lazily on PDP scroll-into-view. Mobile AR triggers via the standard <model-viewer ar> tag — iOS uses USDZ, Android uses GLB.

Conversion lift: 1.8-3.2x AR-on / AR-off on furniture PDPs in the data I see, especially at AOV $1,500+. Pays back the integration cost within 60-90 days for most mid-market brands.

Calendly works fine for <3 showroom locations. Above that, dedicated appointment platforms scale better.

• Calendly — embed on PDP and footer via the official widget. Each showroom is a separate event-type. Customers pick location + designer + time slot. Free for basic, $12-$20/user/mo for team features. Limit: doesn’t handle inventory awareness (“is this sofa actually on the showroom floor today?”).
• SimplyBook.me — multi-location native, supports up to 50+ providers, custom intake forms, automated reminders. Better for retail furniture chains with 5+ showrooms.
• Acuity Scheduling (Squarespace-owned) — mid-tier. Good for design-consult bookings (60-90 min slots) with a virtual + in-person toggle.
• Square Appointments — bundles with Square POS. Good fit for brands already running Square in-store.

Magento integration: embed via product-attribute “available at showroom” flag + a CMS block on PDP that shows the appointment widget. For showroom inventory awareness (“the brown leather version is on the LA floor; the cream is at SF”), pull a per-store-per-SKU availability flag into Magento via custom attribute and surface it in the appointment-picker UI.

Conversion data: 30-50% of high-AOV furniture buyers want to see in person before buying. A booking widget on PDP routes those buyers into a showroom visit with an associate — closes ~25-40% of those visits.

Native Magento B2B (or Open Source + extensions) handles trade programs cleanly:

• Trade application — custom form captures business name, license number, resale-certificate upload, portfolio URL. Submission triggers an admin notification; manual approval flips the customer’s group to “Trade.”
• Tier pricing — customer-group price rules give Trade members 15-30% off retail (your call), with deeper tiers (e.g. 35% at Diamond) gated by annual purchase volume. Enforced at cart by Magento’s native pricing engine.
• Hidden trade catalog — segment-restricted categories let you stock items only Trade members see (e.g. wholesale-only fabrics, designer-only finishes).
• Net-30 invoicing — via Apruve / Resolve / TreviPay payment-method extensions. Customer checks out without a card; invoice sent post-shipment.
• Designer rebate program — track lifetime trade purchases via custom customer attribute. Issue quarterly rebate via store credit (Mageworx / Mirasvit credit extension) or check.
• Volume-tier discounts — cart-level rules (e.g. 10% off at $5k cart, 15% at $10k) layer on top of tier pricing.
• Line-sheet PDF export — trade members generate a branded PDF of selected products via a custom “export selection” action.

Adobe Commerce ships Companies + Quotes natively; Open Source needs Aheadworks B2B Suite or equivalent.

Furniture returns are catastrophically expensive. The right policy + workflow is more about preventing returns than processing them efficiently.

Prevention: swatches-by-mail (free or $5-15 refunded on order), AR / 3D visualization (cuts return rate 30-40% in the data I see), generous pre-purchase consultation (designer chat / showroom booking), and explicit dimensions + weight + clearance-needed measurements on PDP.

Policy structure: most furniture brands run a 30-day return window for in-stock items, no returns on custom upholstery / made-to-order, restocking fee 15-25% to cover reverse freight + repackaging. Some premium brands eat the freight cost as a brand investment.

Reverse freight: integrate with the same LTL carrier (FreightCenter, uShip) that delivered — they handle pickup + return-to-warehouse with one workflow. White-glove returns include unpack-at-customer + repack + load. Cost is typically $200-$600 per return, which is why the restocking fee exists.

RMA workflow on Magento: Magento RMA module + Mirasvit Advanced Reports / Mageworx RMA extension handles the request, approval, return label, restock + refund flow. Photo-upload requirement deters “changed my mind” returns on items that arrived perfect.

Damaged-in-transit: separate workflow — customer files a damage claim with photos within 48h, brand replaces the piece + handles carrier claim with the LTL carrier. White-glove deliveries have lower damage rates (~3%) than curbside (~8-12%).

Furniture is one of the categories where Magento clearly wins above ~$2M GMV.

Where Magento wins:

• Configurator depth — Custom Options + Bundle products + EAV handle 1,000+ valid combinations cleanly. Shopify maxes out at 100 variants per product without third-party apps that add per-month costs and slow PDPs.
• LTL freight — Magento shipping-method extensions integrate FreightCenter / uShip / Roadie natively. Shopify needs Bolt-on apps (Shipper HQ, etc.) with limits on white-glove + assembly upsells.
• B2B / trade — native customer groups + hidden categories + tier pricing. Shopify B2B (Plus-only) added similar features in 2023 but has gaps on multi-step trade approval + designer rebates.
• Lead-time + production milestones — custom order-status workflow on Magento; Shopify doesn’t expose order state-machine.
• Multi-region freight — one Magento backend can serve US LTL + EU pallet courier with separate freight rules per store view. Shopify Markets shares freight logic across regions.

Where Shopify wins:

• Furniture brands under 200 SKUs with simple variants (no real configurator) and parcel-shippable items. Shopify launches in 4 weeks vs 12-16 on Magento.
• Pure DTC, no B2B / trade, no white-glove, in-stock only. Shopify avoids the Magento ops overhead.

Practical rule: under $2M GMV with simple SKUs → Shopify; above $5M GMV with configurator + LTL + B2B trade → Magento; the $2-5M middle is a case-by-case fit decision based on configurator complexity.

US and EU furniture freight are different operational worlds. Magento multi-store handles both; the rules per region are separate.

US LTL: dominant carriers XPO, ABF, R+L, FedEx Freight, YRC. Pricing by NMFC freight class + zone + weight. White-glove networks (Metropolitan, Pilot, J.B. Hunt) handle premium delivery. Liftgate required at residential. Integration via FreightCenter / uShip API.

EU pallet courier: different model entirely. Brands like Palletways, FreightOne, DPD Pallet, DSV. Pricing by pallet count + dimensions + zone. White-glove + assembly is more rare in the EU; most consumers expect curbside or threshold. Two-man delivery teams handle large items (sofas, beds). Integration via partner-specific APIs or aggregators like Sendcloud.

Currency + tax differences: US sales tax (managed via Avalara or TaxJar, varies by state + economic-nexus rules). EU VAT (managed via Magento native VAT engine + per-country rates, with OSS reporting for cross-border B2C and reverse-charge for B2B). UK post-Brexit needs separate handling (UK VAT + customs declarations on EU↔UK shipments).

Magento setup: one backend, two store views (US + EU), separate shipping-method configurations, separate freight-API credentials, separate tax rules. Shared product catalog with per-store-view price + currency overrides.

Brexit footnote: UK customers ordering from EU stock incur UK VAT + customs at delivery (or merchant pre-pays via DDP). Most furniture brands stock locally in the UK to avoid the friction.

Made-to-order upholstery is the highest-margin furniture segment but the most operationally complex. Magento + a production-management extension handles it.

Order capture: the configurator stores every customer choice (frame, fabric SKU, fabric direction, contrast piping, leg style, leg finish, cushion fill, etc.) as line-item options on the Magento order. The order is “locked” once placed — changes require a phone call to support to reissue.

Production routing: custom Magento extension or workflow tags the order with production stage (cut → sew → upholster → QC → ship). Each stage has an SLA (e.g. cut by day 7, sew by day 14, ship by day 56). Production team marks each stage complete via admin or a barcode-scanner app; the customer sees the progress bar update.

Material allocation: fabric is reserved against the order at checkout (Magento MSI reservation) so the production team knows the yardage is dedicated. Backorder triggers a customer email + ETA update if the fabric runs out.

Quality control: the QC step uploads photos before shipping (so the customer sees the actual piece) — cuts post-delivery dispute rate ~50% in the brands I’ve worked with.

Shipping: custom upholstery typically ships LTL with a pre-scheduled white-glove window. The carrier’s appointment scheduler (or a manual call from the brand’s ops team) confirms the date. No surprise deliveries.

Cancellation policy: most brands lock the order at “materials cut” (typically day 5-7). Before cut: full refund. After cut: store credit only or 25% restocking. Communicated upfront on PDP + at checkout.

Realistic ranges for a furniture-specific Magento + Hyvä build:

• Greenfield (replatform from Shopify or new build): 12-16 weeks, $35k-$95k. Includes Hyvä theme + configurator + LTL freight integration + lead-time tracking + AR/3D wiring + B2B trade layer + showroom booking.
• Configurator-only retrofit on existing Magento: 4-6 weeks, $12k-$30k. Adds the fabric/finish/dimension picker + visual swatches + validation rules + custom-options optimisation.
• LTL freight integration only: 2-4 weeks, $6k-$18k. FreightCenter / uShip API + white-glove + assembly line items.
• AR/3D visualization rollout: 4-8 weeks (depends on 3D-model availability), $8k-$25k for the integration; 3D models themselves cost $200-$1,500 each from a vendor like CGI Furniture or Confetti Design.
• B2B trade program retrofit: 3-6 weeks, $10k-$28k. Trade application form + customer-group pricing + Net-30 + hidden catalog + designer rebate tracking.

Ongoing: $1.5k-$5k/mo retainer for continuous optimisation through seasonal calendar (configurator UX iterations, freight rate audits, AR conversion tuning, trade-program refinements). Most brands keep a retainer for the first 12 months post-launch.

What inflates timeline: 3D model acquisition (12+ weeks if starting from scratch), ERP / OMS integration (NetSuite / Acumatica), custom production-management extension if standard ones don’t fit, multi-region launch (US + EU + UK).

The cheapest builds skip AR + skip B2B trade + use a generic LTL aggregator. The most expensive builds include real-time configurator visual rendering + bespoke production-management workflow + 4-region deployment.

Claude Code is Anthropic’s official command-line interface for Claude. It’s a Node.js CLI you install with npm i -g @anthropic-ai/claude-code and run from your terminal inside any repo. Unlike the chat-window claude.ai, Claude Code reads your real source tree, edits files in place, runs your tests, executes shell commands you authorise, and ships PRs end-to-end. It’s designed to be an AI pair-programmer — you steer, Claude does the keystrokes. Built and maintained by Anthropic, the same company that makes Claude itself.

Three key differences:

• Vs. Copilot: Copilot is autocomplete-in-IDE. Claude Code is a CLI agent that plans, edits multiple files, runs tests, and commits PRs — not just inline suggestions.
• Vs. Cursor: Cursor is an IDE (VS Code fork) with chat. Claude Code is editor-agnostic — works in your existing VS Code, JetBrains, Vim, or terminal. Same agent, no IDE lock-in.
• Vs. Aider: Aider is similar in shape (CLI pair-programmer) but provider-neutral. Claude Code is Anthropic-native, so you get first-party access to Claude features (extended thinking, prompt caching, computer use, MCP) without a translation layer. Sub-agents and hooks are also first-party.

For Magento & Hyvä work specifically, Claude Code wins on: real codebase reads, MCP-database access, hook-gated safety, and the slash-command library.

By default, the latest production-tier Anthropic model — currently Claude Opus 4.7 for heavy coding tasks and Claude Sonnet 4.6 for fast routine work (May 2026). You can pin specific models with --model or set defaults in your .claude/config.json. Extended thinking mode kicks in automatically for complex tasks (architectural decisions, debugging). You can also route Claude Code via AWS Bedrock or GCP Vertex AI if your org requires cloud-vendor billing — the CLI picks up ANTHROPIC_BEDROCK_BASE_URL / ANTHROPIC_VERTEX_PROJECT_ID env vars.

Three steps, ~60 seconds total:

1. Install the CLI: npm i -g @anthropic-ai/claude-code (requires Node.js 18+).
2. Authenticate: Run claude login — opens browser, signs in with your Anthropic account (Pro / Team / API). Or set ANTHROPIC_API_KEY env var if you’re using API direct.
3. Run it: cd into any repo, type claude, ask your first question. That’s it.

For corporate setups behind a proxy, see the 5-step setup section above. For Magento-specific install + CLAUDE.md, see our Magento playbook.

CLAUDE.md is a Markdown file at your repo root that holds your project rules — coding standards, “never edit vendor”, “always write MFTF tests”, deploy flow, naming conventions, links to internal docs. Claude Code re-reads it at the start of every session, so your team’s rules become muscle memory for the AI. Write once, AI follows forever.

A good Magento CLAUDE.md includes: tech stack (Magento 2.4.x + Hyvä), “no vendor edits”, “plugin-over-rewrite”, “db_schema not raw SQL”, “MFTF tests required”, deploy commands, and a list of internal modules with their purpose. Sub-folders can have their own CLAUDE.md files that compose with the root one — useful for monorepos.

Different shape, similar goal. Cursor @-mentions reference files / docs / web pages inline in chat. Claude Code slash-commands are reusable prompt templates stored as Markdown files in .claude/commands/. When you type /scaffold-module, Claude Code injects the contents of .claude/commands/scaffold-module.md as your prompt — with optional argument substitution.

Slash-commands are repeatable workflows — you write the prompt once (“scaffold a Magento module with these conventions, db_schema, registration, MFTF test stub”), then any team member runs it with one keystroke. Claude Code also supports arguments ($ARGUMENTS placeholder) and file references (@path/to/file) inside command files, so you get the best of both worlds.

The Model Context Protocol (MCP) is an open standard (open-sourced by Anthropic) for connecting AI assistants to external tools and data sources. An MCP server exposes a specific resource — GitHub, Linear, Sentry, your Postgres database, your Magento DB, your design system — through a standardised interface that Claude Code can call.

You wire MCP servers in .claude/mcp.json. Once wired, Claude Code can read your GitHub issues, query your Magento DB, fetch Sentry stack traces, file Linear tickets — all without you copy-pasting context into chat. Crucially, your API keys live in MCP server config, not in your prompts — so they don’t leak into your conversation logs. Anthropic + the community ship 100+ official MCP servers; building your own is a 50-line Node script.

Hooks are shell scripts that run before or after Claude Code performs an action — editing a file, running a Bash command, finishing a tool call. They’re your safety net.

• PreToolUse hooks can block dangerous actions: refuse to rm -rf /, refuse to push to main branch, refuse to write into vendor/, refuse to edit prod credentials. Hook returns non-zero exit, action is cancelled, you stay safe.
• PostToolUse hooks auto-run lint / format / tests after every file edit. phpcs + phpstan + composer validate on every Magento file change — built into the CLI, not bolted on.
• Stop hooks run when Claude finishes a session — great for auto-committing or running test suite.

Configure hooks in .claude/settings.json. They’re the difference between “cool AI demo” and “production-grade workflow.”

Sub-agents are parallel Claude Code instances spawned by your main session, each with its own context window, working independently on a task you delegate. Useful when:

• Parallel work: spawn three sub-agents to audit, build, and test in parallel — they each get a fresh context window, so a 30-min audit doesn’t blow your main session’s context.
• Long-running tasks: a sub-agent can grind on “port these 80 Luma blocks to Hyvä” for an hour while you keep planning in your main session.
• Specialised personas: a sub-agent with a stricter CLAUDE.md (e.g. “you are a security auditor; only output findings, never edit”) gives you focused output without polluting your main agent’s instructions.

Spawn with the Task tool. They report back to the main session when done — you get the summary, not the keystroke-by-keystroke noise.

Three billing options:

• Claude Pro ($20/mo): unlimited Claude Code usage with model auto-routing. Best for solo devs — effectively flat-rate AI pair-programming.
• Claude Team ($25/seat/mo, 5+ seats): Pro features + admin controls + shared workspace + SSO. Best for engineering teams.
• Anthropic API (pay-per-token): $3/M input + $15/M output for Sonnet, $15/M + $75/M for Opus. With prompt caching enabled, repeated reads of vendor/ drop ~90% of input cost. Best for pipelined / CI / sub-agent-heavy workflows.

For most Magento dev work, Claude Pro flat rate is the right answer — you don’t want to think about per-token cost while shipping. For agentic / parallel sub-agent workflows, API with prompt caching is more economical.

No — not on commercial-tier inputs. Under Anthropic’s Commercial Terms of Service, customer inputs and outputs (Claude Pro, Claude Team, Anthropic API) are not used for model training. That’s contractual, not just a setting.

For zero-data-retention setups (regulated industries, NDA-heavy work), Anthropic supports a zero-data-retention mode on the API and Bedrock / Vertex routes — inputs aren’t logged at all past the live request. Free-tier claude.ai consumer use can opt-in to training (the consumer privacy notice differs), but Claude Code does not run on free-tier accounts. Net effect: your codebase stays in your VCS — nothing leaves except the API call you made.

Six workflows that compound massively in ecommerce dev:

1. Setup-patch generation: a /setup-patch slash-command that scaffolds idempotent DataPatchInterface patches with dependency wiring — for seeding configs, products, categories, FAQs.
2. db_schema → migration: describe the column you want, Claude Code writes db_schema.xml + db_schema_whitelist.json + a setup-patch for backfill.
3. Hyvä port: a /hyva-port-block command that takes a Luma block and spits out the Hyvä equivalent with Tailwind classes + Alpine.js.
4. MFTF + PHPUnit: features ship with tests in the same PR — non-negotiable in CLAUDE.md.
5. Sub-agent audit: nightly sub-agent that audits your repo against Magento Coding Standard + EQP, files Linear tickets via MCP.
6. SEO page builder: a slash-command that scaffolds a new Tier-1 pillar page (block + layout + template + LESS + 3 setup-patches) following your established pattern. (We use this exact one to ship our SEO landing pages.)

For the deep-dive, see our Magento playbook and Hyvä playbook.

A single, well-defined OpenCart bug starts at $99 (a Quick Fix, ~4h @ $25/hr) and ships in 24–48 hours. A batch of related bugs, or one deep root-cause like post-upgrade fallout or a payment-callback failure, is a Bug-Fix Sprint at $499 (~20h @ $25/hr) with full regression testing. Stores that need round-the-clock cover take an Emergency / Retainer; a full stabilization sprint is around $2,499 (~100h @ $25/hr). You always get the quote before any work starts.

Emergencies — a blank white storefront or a broken checkout — get a first response inside 4 hours. Most standard single bugs (an Undefined index notice, an OCMOD conflict, a 404 SEO URL) are fixed and verified within 24–48 hours. We always read your storage/logs/error.log first so the triage is accurate, not a guess.

Staging first, always. We clone your store to a staging environment, turn full error logging on, and reproduce the bug there — never debugging blind on your live storefront. Once the fix is tested, we deploy it to live, refresh the vQmod/OCMOD modification cache, clear the OpenCart cache, and verify the fix in production with you. If you don’t have staging, we can spin one up.

Yes. Every fix is reproduced and tested on a clone before it touches production, and ships with a regression check across cart, checkout, payment and admin so one fix never silently breaks another flow. Where possible we patch through a clean OCMOD or vQmod modification rather than hacking core files, so the change is reversible and survives future updates.

A blank white page (WSOD) almost always means a PHP fatal error is being hidden. The cause is in storage/logs/error.log — commonly Fatal error: Uncaught Error: Call to a member function ... on null, a missing class after a half-finished extension install, a memory-limit exhaustion, or a broken vQmod/OCMOD modification. We tail the log, trace the controller and model, and patch the real cause — we don’t just hide the error with display_errors off.

Notice: Undefined index (and on PHP 8, Warning: Undefined array key) appears when a template or controller reads an array key that wasn’t set — usually after a PHP version bump or a theme/extension that wasn’t written for your version. They flood the header, product and category pages. We harden the controller data and templates so the keys are always defined, then quiet the log — without masking genuine errors.

Yes — this is one of the most common OpenCart bugs. When two modifications patch the same core file, the XML search/replace can silently fail or apply in the wrong order, breaking a page. We inspect the vqmod/vqcache output (or the merged OCMOD modification.xml), find the clashing rule, and re-order or rewrite the search/replace so both extensions coexist. We then refresh the modification cache so the fix actually loads.

Yes. Orders stuck in Pending usually mean the gateway’s IPN/callback never reached OpenCart, or it did but the signature check or order-status mapping failed — we see this with PayPal, Stripe, Razorpay, SagePay and Authorize.Net. We verify the callback route resolves (not a 404), confirm SSL and the expected headers, check the IPN/webhook signature, and fix the order-status mapping so paid orders flip to Processing.

OpenCart friendly URLs 404 when the rewrite chain breaks — commonly a missing RewriteBase in .htaccess, the SEO URL setting left off, missing seo_url rows after a migration, or $_SERVER['REQUEST_URI'] behaving differently on a new server/PHP version. We restore the rewrite block, fix the SEO PRO / SEF configuration, and re-seed any missing seo_url keywords so your indexed URLs resolve again.

Yes — post-upgrade fallout is a big part of what we fix. Moving to 3.x (or onto a new PHP 8 host) often breaks a theme or extension that relied on old behaviour: Twig template errors, undefined-index notices, broken OCMOD modifications, or a payment module that no longer matches the new API. We map what broke, fix the templates and modifications, and bring extensions up to the version they were built for. This usually fits a Bug-Fix Sprint.

Yes. Wrong totals after switching currency or changing a tax class are usually rounding drift, a stale exchange rate, or a tax rule applied to the wrong geo zone. We trace the calculation through system/library/cart and the tax classes, reconcile the math against expected totals, and confirm the cart, checkout and order confirmation all show the same figure across every currency you sell in.

Yes. A Quick Fix carries a 7-day warranty on that specific bug — if it recurs, we fix it again at no charge. A Bug-Fix Sprint includes 14 days of post-fix coverage. Because every fix is reproduced on staging and regression-tested before deploy, recurrences are rare. For ongoing peace of mind on a live OpenCart store, an Emergency / Retainer keeps you in a priority queue.

Use multi-store when your storefronts share most of the catalog, customer base, or admin operations — you get one upgrade, one extension stack, one hosting bill, and surgical per-store overrides where needed. Use separate installs when storefronts are run by different teams, have totally distinct catalogs, or need fundamentally different stacks (e.g. one Hyvä, one Luma headless). 90% of cases we see are multi-store wins — the maintenance and SEO consolidation alone usually justify it.

Magento has three scopes:

• Website — isolation boundary for customers, carts, orders and (by default) prices. Use one website per legal entity / region with separate carts.
• Store — root-category boundary. Use multiple stores per website when you need different catalog trees (e.g. brand A vs brand B sharing a checkout).
• Store view — locale boundary. Use one per language inside the same store (e.g. EN, FR, DE views of the EU store).

Wrong-scope configuration is the #1 source of multi-store pain. We map the hierarchy in the audit before any code is written.

Magento supports multiple currencies natively. We typically wire it up like this: (1) Allowed currencies set per website. (2) Live FX feed (ECB, OpenExchangeRates, fixer.io) with cron import every hour. (3) Per-currency rounding rules and price-display formatting per locale. (4) Optional fixed prices in customer-group + website scope to avoid FX drift on premium SKUs. Customers see only the currency for their region; admins see all currencies side-by-side in reports.

Three rules: (1) Every URL must reference every other locale variant of itself, including a self-reference. (2) Each variant must point back — bidirectional. (3) Always include x-default. We generate hreflang server-side per URL (not via JS), validate it on every deploy with Screaming Frog, and emit it on canonical URLs only. Common foot-guns we prevent: hreflang on non-canonical URLs, region-only tags without language, and hreflang loops between cross-linked storefronts.

Both. Magento has a customer account scope setting (Stores > Configuration > Customers > Account Sharing Options): set to Global for one account across all websites, or Per Website to isolate. Most multi-region setups want per-website isolation (so a UK customer can’t accidentally order at US prices), while same-language sibling stores often share globally. Switching this setting after launch is painful — we always decide it upfront in the audit.

Done right, no. The Magento application is shared in memory; each store view just changes what gets rendered. Done wrong — with bloated core_config_data, runaway URL rewrites per store, or unscoped extension queries — multi-store can be measurably slower. We size Redis + Varnish for the storefront count, scope every config to the right level, and load-test each store view separately before launch. We commit Lighthouse 90+ on every storefront, regardless of count.

Payment method config is scoped per website. We typically enable: iDEAL + Bancontact for NL/BE, Klarna + Sofort for DE/AT, BACS + Worldpay for UK, Stripe + Apple Pay + Google Pay for US/CA, Razorpay + UPI for IN, plus PayPal as a global fallback. Each website only exposes payment methods that work for its region — customers never see options that will fail at gateway.

Yes — three layers of control: (1) Catalog price scope set to Website, so each website can have its own price list. (2) Customer-group pricing for tier-based discounts (B2B, VIP, etc.). (3) Cart price rules per website for region-specific promotions. We can also import region-specific price CSVs nightly from your ERP if you have a master pricing system. Tax-inclusive (EU/UK) vs tax-exclusive (US) display is handled at the same scope.

Each regulation has different requirements — we configure them per store-view, not site-wide. GDPR (EU + UK): explicit cookie consent before any tracking, right-to-be-forgotten endpoint, data-export request flow. CCPA (California): “Do Not Sell My Personal Information” link, opt-out by default. LGPD (Brazil): explicit consent + DPO contact in footer. PIPEDA (Canada): less invasive, but still requires consent for marketing. We use scoped cookie-consent extensions that auto-detect the visitor region, and integrate with your CRM for unified data-subject-access requests.

Yes. Theme assignment is scoped per store-view, so each storefront can have its own theme, logo, colour palette, fonts, header, footer, even checkout layout. Most clients use one parent theme with per-storefront skins (cheaper to maintain, faster to build, easier to upgrade). For radically different brands — e.g. a luxury sub-brand vs a discount sub-brand on the same backend — we deploy fully separate themes with shared core blocks. Hyvä supports this pattern natively.

Yes — Adobe Commerce B2B (companies, quote workflow, requisition lists, customer-specific pricing, Net-30 / Net-60 payment terms) is scoped per website. So you can run B2C in the US, B2B in DE, and a hybrid B2B+B2C in the UK off the same backend. Each region can have its own sales reps, quote approval flow, payment terms and ERP integration. Salesforce / HubSpot / NetSuite integrations can also route per region. (Note: B2B requires Adobe Commerce, not Open Source.)

Lower than running N separate Magentos — that’s the point. (1) One upgrade applies to all storefronts. (2) One extension stack to license & maintain. (3) One hosting bill (provided you sized it for the storefront count). (4) One admin login for your ops team. The catch: set up wrong, multi-store can become an n-by-n compatibility matrix every time you change something. That’s why we audit + diagram + scope-test before any code goes live, and bake regression tests for each storefront into the deploy pipeline. 30 days post-launch + retainer covers ongoing localisation.

Yes, by an embarrassing margin. On a stock Magento Open Source 2.4.8 install with the default catalogue:

• Lighthouse mobile performance: Hyvä 95 – 99 vs Luma 25 – 45 (orange/red zone)
• JS bundle (gzipped, homepage): Hyvä ~70 KB vs Luma ~450 KB
• First Contentful Paint (4G mid-tier Android): Hyvä 0.4s vs Luma 1.8s
• Largest Contentful Paint: Hyvä 0.9s vs Luma 4.1s
• Time to Interactive: Hyvä < 1s vs Luma 4 – 8s
• Interaction to Next Paint: Hyvä ~60ms vs Luma ~380ms

These numbers are from production stores I’ve migrated, not synthetic benchmarks. The gap shrinks slightly under heavy customisation, but Hyvä still wins by 2 – 3x on every Core Web Vital.

Luma: $0 license, ships with Magento Open Source. The cost is in performance work afterwards — a Luma store usually needs $5 – 15k of optimisation to claw the Lighthouse score above 60.

Hyvä: $1,000 – $2,000 one-time license per store (per major version), then you own the code forever — no per-seat, no SaaS fee. Migration dev runs $5 – 20k depending on customisation depth and extension count. Greenfield builds tend to be cheaper than migrations because there’s no porting work.

3-year TCO: Hyvä typically wins by $5 – 30k once you factor in the conversion lift (8 – 25%) and the avoided performance-tuning bills. Stores with strong organic traffic break even fastest because every second of LCP improvement compounds across millions of pageviews.

Probably yes — the answer depends on the extension category:

• Storefront-impacting paid extensions (Amasty, Mageplaza, Magefan, etc.): ~95% have native Hyvä support in 2026, or work via the Hyvä Compatibility Module.
• Marketplace storefront extensions (free): ~70% native or compat-supported. Some niche ones may need a port.
• Admin-only extensions (reporting, exports, RMA): 100% — they don’t touch the storefront so Hyvä doesn’t affect them.
• Heavy frontend customisation extensions (page builders, layered nav, configurators): 80 – 90% have Hyvä parity, but check each one before committing.

The audit step in any migration starts with a per-extension compat check — no surprises mid-build.

Depends on where the bleeding is. Two patterns I see:

• Storefront slow, checkout OK → full Hyvä first. If PLP/PDP Lighthouse is < 50 and bounce rate is high, fix the entry pages first. Hyvä Checkout is a smaller win on top.
• Storefront OK-ish, checkout abandonment > 70% mobile → Hyvä Checkout first. Captures ~50% of the perf wins for ~25% of the migration cost. Lower risk, faster ROI. Then plan a full Hyvä migration in a later phase.

For heavily customised Luma stores where a full migration is genuinely $30k+, Hyvä Checkout alone is often the right answer for the first 12 months. The two aren’t mutually exclusive — they stack.

Three rough sizes:

• Small (low customisation, < 10 extensions): 4 – 6 weeks, $5 – 10k. Mostly theme port + brand re-skin. Fastest payback.
• Medium (custom Luma child theme, 10 – 25 extensions, some B2B): 6 – 9 weeks, $12 – 20k. Most stores fall here.
• Large (multi-store, heavy custom modules, B2B-heavy, 25+ extensions): 10 – 16 weeks, $25 – 60k. Often phased — full Hyvä on B2C storefronts first, B2B portal in a later phase.

Side-by-side QA + soft cutover (10% traffic for 7 days, then full) is included in every estimate. Roll-back plan stays available for 14 days post-cutover.

Yes — Hyvä supports the full Magento B2B feature set (company accounts, requisition lists, quotes, shared catalogues, tier pricing). The work is in re-implementing custom UI on top of those features.

What needs porting:

• Company-account dashboards (custom Knockout templates → Alpine + Magewire)
• Requisition list / quick-order UIs (usually a clean refactor; the Hyvä versions are simpler)
• Custom price-tier display logic on PLP/PDP (move from KO to Alpine)
• B2B-only checkout flow tweaks (often easier in Hyvä Checkout)

B2B-heavy stores often see bigger conversion lifts after Hyvä migration than B2C ones — buyer expectations on UX have caught up to consumer-grade, and B2B Luma UX usually lags badly.

Same Magento multi-store mechanism (websites, store views, store-scoped configs) — Hyvä sits on top, doesn’t change the architecture. Per-store theme overrides, per-store-view translations, per-store catalogue all work identically.

Where it’s actually better than Luma:

• Tailwind config can be per-child-theme, so different brand looks share the parent Hyvä foundation without LESS-import gymnastics
• Alpine state is local to each Hyvä component, so store-view-specific UI tweaks don’t leak across views
• Faster builds — no `setup:static-content:deploy` per-locale RequireJS pipeline grinding through 8 store views

For 5+ store-view setups, Hyvä actually saves engineering time on top of the perf wins.

If done right, no. If done wrong, yes — but it’s preventable. The risk areas:

• URL structure changes: none, if you keep the same Magento URL rewrites. Hyvä is a theme layer, not a URL change.
• Schema markup: Hyvä emits product/breadcrumb/organization schema by default. Verify it matches your current structured data, port any custom JSON-LD.
• Meta tags + canonical: handled by Magento core, so Hyvä doesn’t change them. Verify after cutover with a crawl.
• Page speed (positive): Lighthouse 95+ improves Core Web Vitals, which improves Google rankings on competitive queries. The lift usually shows up 4 – 8 weeks post-cutover.

Standard playbook: full Screaming Frog crawl pre-cutover, same crawl post-cutover, diff every node. Submit updated sitemap. Rankings hold or improve within 2 months in 90%+ of cases.

Adobe hasn’t formally deprecated Luma, but the de facto signals are clear:

• No meaningful Luma updates since 2022 — only security backports.
• Adobe’s own 2024 announcement positioned Hyvä as the recommended frontend for Adobe Commerce going forward.
• Adobe Commerce Cloud onboarding for new merchants now defaults to Hyvä project templates.
• Magento Open Source still ships with Luma as default (won’t change in 2026), but every "what should I build new with?" recommendation from Adobe Solution Partners points at Hyvä.

The way to read this: Luma will keep working for 5+ more years (Magento doesn’t break things), but it’s in maintenance mode. Building greenfield on Luma in 2026 is choosing the legacy stack on day one.

The Hyvä Compatibility Module is a separately-licensed wrapper that lets Luma-only extensions render their UI inside a Hyvä storefront without rewriting them. It does this by injecting a sandboxed Knockout/RequireJS environment for those specific extensions, while the rest of the page stays Hyvä-native.

What it covers:

• ~95% of paid Luma-only extensions from major vendors (Amasty, Mageplaza, Magefan, Aheadworks, etc.)
• Most Magento Marketplace storefront extensions that haven’t shipped native Hyvä support yet
• Custom Luma extensions written in-house (with some setup work)

What it doesn’t cover:

• Page-builder extensions that try to take over the whole page rendering pipeline
• Extensions that hard-code Luma-specific class names everywhere
• The performance wins — Compat Module re-introduces some Luma JS, so a Compat-heavy store loses 10 – 30% of the Hyvä perf win. Still way ahead of pure Luma.

Yes, and mostly in your favour. The required skills:

• Tailwind CSS: mainstream front-end skill, huge talent pool, easy to hire
• Alpine.js: small, easy to learn — most React/Vue devs pick it up in a weekend
• Magewire (server-side reactivity): Hyvä-specific, but well-documented. 1 – 2 weeks to ramp
• Magento backend (PHP, GraphQL, modules, plugins): identical to Luma — same talent pool

Compare to Luma which needed:

• jQuery (still findable, but devs hate it now)
• RequireJS (legacy, fewer experts every year)
• KnockoutJS (effectively dead — almost nobody under 30 has used it)
• UI Components XML (Magento-specific arcana)

Hiring for Hyvä is genuinely easier than Luma in 2026, and the dev quality is higher because the talent pool overlaps with mainstream web dev.

Hyvä, by a clear margin. The reasoning:

• Active development: Hyvä ships a new version every 6 – 8 weeks. Luma ships security patches only.
• Adobe’s direction: Adobe Commerce + Hyvä is the strategic frontend stack for 2026 – 2030.
• Talent pool: Tailwind/Alpine devs are growing; jQuery/Knockout devs are aging out.
• Extension ecosystem: new extensions ship Hyvä-first from 2024 onwards. Luma compat is becoming a "legacy support" feature in marketplace listings.
• Hyvä team: Acquired by Vaimo in 2024, well-funded, growing engineering team. Not a side-project.

Realistic horizon: Luma will work for 5+ more years but stop being competitive in 2 – 3. Hyvä has 10+ years of clear runway. If you’re planning a build that’ll live 5+ years, Hyvä is the only sensible answer in 2026.

For 95% of Magento stores: Hyvä. Server-rendered, Tailwind + Alpine, Lighthouse 95+, $5 – 20k build, simple to hire for, simple to maintain.

The 5% who should pick PWA Studio know it from the start: native iOS/Android app sharing one GraphQL backend with the web, $50M+ GMV, dedicated React team already on payroll, and a budget that covers the 8x cost multiplier without flinching. If you’re unsure which group you’re in, you’re in the 95%.

For a typical mid-volume Magento store (50 – 500 SKUs, B2C, 1 storefront, no exotic UX):

• Hyvä build: $5 – 20k. Hyvä parent license + child theme bootstrap + brand tokens + PLP/PDP/header/footer/cart re-implementation in Tailwind + Alpine. 4 – 12 weeks elapsed time.
• PWA Studio build: $50 – 200k+. Apollo Client setup + GraphQL schema design + React component library + service-worker config + bundle optimization + SSR / SEO config + headless cache strategy. 16 – 40 weeks elapsed time.

The gap is roughly 8x and it doesn’t close as scope grows. Custom features in PWA Studio cost more to build (every feature touches React + GraphQL + Apollo cache) and more to test. The "PWA Studio is faster long-term" argument doesn’t hold up against production data — most teams are still shipping features faster on Hyvä three years in.

Same Magento 2.4.8 install, same product catalog, same hosting:

• Hyvä: Lighthouse Performance 95+ on every page out of box. ~70 KB JS bundle. LCP under 1s on mid-tier mobile. Predictable across PLPs, PDPs, cart, checkout. No tuning required.
• PWA Studio: Lighthouse 70 – 85 typical for production stores. Variable — depends entirely on bundle size, hydration strategy, image handling, route caching. Specialist tuning can push it higher (90+ achievable) but it costs 80 – 200 hours of perf engineering and it regresses every time someone adds a feature.

The "PWAs are faster" narrative was true vs Luma (where the bar was Lighthouse 30). It is not true vs Hyvä. Hyvä wins on perf in 9 out of 10 head-to-head benchmarks in 2026.

Hyvä is server-rendered. Crawlers receive fully-formed HTML, structured data renders immediately, no hydration gap, no escape-fragment dance. SEO works out of the box — same as old-school PHP rendering.

PWA Studio needs careful SSR config to avoid leaking rankings: Apollo SSR setup, cache hydration on the client, fallback HTML for crawlers, escape-fragment cleanup, route-level meta-tag injection. Many real PWA Studio implementations leak rankings during build complexity — the dev team optimises for the React experience and Googlebot times out before hydration completes. We’ve seen production stores drop 30 – 50% organic traffic in the first 6 months post-PWA-launch and only recover after a 6-figure SSR-tuning project.

If SEO is in your top-3 reasons for the rebuild, Hyvä is the safer answer.

Concrete numbers from real engagements:

• Hyvä: $5 – 15k/year. One stack (PHP + Tailwind + Alpine), one build pipeline, one mental model. Magento upgrades are mostly transparent. Hyvä parent theme upgrades take 1 – 3 days per major version.
• PWA Studio: $50 – 100k/year. React expertise on retainer, GraphQL schema upkeep, Apollo cache tuning, service-worker debugging, SSR config maintenance, bundle-size budgets policed every PR. Magento upgrades require coordinated GraphQL contract testing. PWA Studio version bumps occasionally rewrite half the codebase.

Over 3 years that’s a ~$240k delta on maintenance alone, on top of the 8x build cost gap. The cost difference compounds — every quarter you stay on PWA Studio costs more than the equivalent quarter on Hyvä.

Sort of, but the framing is misleading. PWA Studio ships a Progressive Web App by default — installable on Android home screen, offline-capable for cached routes, push-notification ready. It’s not a native app — it doesn’t ship on the App Store / Play Store on its own.

To get a real native app from PWA Studio you wrap it with Capacitor or React Native. That works because the React frontend is already built — but it’s a separate engineering effort with its own App Store review process, push-notification infrastructure, and platform-specific UX.

Hyvä can also be installable as a basic PWA (service worker for offline, manifest for home-screen install) — that’s a separate Hyvä module. What Hyvä can’t do is share its frontend codebase with a native app on App Store / Play Store. That capability is the real PWA Studio differentiator. If you don’t need it (and 95% of stores don’t), the "mobile app" framing isn’t worth the 8x cost.

Real cases where PWA Studio is the right call:

• D2C brand shipping web + iOS + Android from one engineering team, where the native apps are non-negotiable (cosmetics, athleisure, lifestyle) and have material revenue.
• B2B with kiosk — physical retail kiosks running the same React app as the web checkout, sharing GraphQL state, branded as one experience.
• Content-led commerce where a separate CMS (Contentful, Sanity) drives content + pages and Magento is purely the commerce backend — true headless decoupling.
• Smart-display / TV / set-top-box commerce — extremely rare but does exist for media + entertainment merchants.

If your roadmap doesn’t look like one of those, PWA Studio is overkill. "We might build a native app later" is not a real multi-channel reason — it’s a $150k frontend gambling on a feature that may never ship.

Hyvä Checkout is a separate paid module — Magewire-driven (server-rendered state), one-page, fully customizable in Tailwind, Lighthouse 95+. Most Hyvä stores adopt it once they see the LCP delta vs default Magento checkout. Add-on cost ~$1k.

PWA Studio Checkout is fully client-side React, talks to Magento via GraphQL mutations, supports advanced UX (multi-step animations, instant validation, payment-method UX patterns SPAs do well). The ceiling is higher for very-custom UX, but you pay for that ceiling with build complexity and ongoing maintenance.

For most stores the Hyvä Checkout ceiling is more than enough — sub-1s LCP, full control over fields, support for every Adobe-Marketplace payment method. The PWA Studio Checkout ceiling only matters if you have specific UX requirements that need an SPA (Apple-Pay-style sheet animations, real-time multi-currency conversion in the cart). If you don’t, the simpler ceiling wins.

Hyvä developer: Magento dev who knows Tailwind + Alpine. Tailwind and Alpine are 30-min skills for an experienced dev — most Magento devs pick them up in a week. Wide talent pool, $50 – 100/hr in 2026, hireable on Upwork / LinkedIn / direct in 1 – 2 weeks.

PWA Studio developer: Magento dev + React + Apollo Client + GraphQL schema design + service-worker debugging. That’s 5+ overlapping specialties. Narrow pool, $100 – 200/hr in 2026, hireable in 1 – 3 months and only if you’re paying market rate. The agency that built your PWA Studio storefront will move on; you’ll be hiring on the open market three years later.

Long-term ownership is the most under-priced variable in this decision. By year 3, "who maintains this?" matters more than "who built this?" — and Hyvä wins that race.

Both are Adobe-blessed in 2026, but the support models are different:

• PWA Studio is an Adobe-owned project — Adobe ships the source, Adobe pays the core team. It’s in the Magento Open Source repo, Adobe Commerce documentation references it as the official headless reference. That said, Adobe’s public roadmap commitment to PWA Studio has been quieter in 2025 / 2026 than 2020 – 2022, and most new Adobe Commerce + Hyvä deals don’t mention PWA Studio at all.
• Hyvä Themes is independent (Vendic-led, Netherlands), but Adobe acquired a stake / partnered formally and Adobe’s 2024 + 2025 announcements list Hyvä as the recommended frontend for new Magento builds. Hyvä is shipping — new releases monthly, active dev community, growing extension marketplace.

If you optimise for "what does Adobe sell to enterprise customers in 2026" — that’s Adobe Commerce + Hyvä, not Adobe Commerce + PWA Studio.

Same starting point (existing Luma store), same scope:

• Luma → Hyvä: 4 – 12 weeks, $5 – 20k. Hyvä Compatibility Module covers most marketplace extensions for free. Brand tokens port to Tailwind config. Most stores recoup the cost in 3 – 6 months on conversion lift.
• Luma → PWA Studio: 16 – 40 weeks, $50 – 200k+. Every extension needs a GraphQL contract. Frontend is rebuilt from scratch in React. Extension marketplace coverage is much thinner — many paid Luma extensions have no PWA Studio equivalent at all. ROI window is 18 – 36 months at best, often longer.

The migration cost differential is the clearest signal in the decision. If you’re migrating off Luma in 2026, Hyvä is almost always the right answer unless your roadmap genuinely requires native apps + multi-channel + you have the team and budget to support it.

Rarely, and only for very specific multi-brand setups. Real cases I’ve seen:

• Multi-brand parent — flagship D2C brand on PWA Studio (with native apps), B2B back-office portal on Hyvä on a separate Magento instance. Two surfaces, two stacks, two dev teams, shared product data sync.
• Regional split — North-American storefronts on PWA Studio (where the React team is based), EMEA storefronts on Hyvä (where the Magento + Tailwind team is based). Same backend, different frontends per region.

What I haven’t seen work: trying to run both Hyvä and PWA Studio on the same store / same domain. The maintenance burden compounds, the dev team gets pulled in two directions, and you end up paying 1.5x the cost of either stack alone. If you find yourself drafting a "we’ll do both" plan, that’s usually a sign the underlying decision wasn’t made — pick one and commit.

Apples-to-apples at $5M GMV with 5k SKUs and a B2B mix:

• BigCommerce Pro / Enterprise: $399–$2,000+/mo plan + B2B Edition (~$2,000+/mo) + apps ($300–$800/mo for ERP, search, reviews, tax) + theme dev ($5k–$15k one-off). Annualised: ~$50k–$80k/yr excluding payment-processor fees (BC takes 0% per-tx; processor still does 2.4–2.9%).
• Magento Open Source: $0 license + hosting ($300–$1,500/mo on AWS / Cloudways / managed) + DevOps retainer ($1,500–$5k/mo) + extensions ($3k–$10k one-off + $200–$500/mo updates) + theme on Hyvä ($8k–$25k one-off). Annualised: ~$40k–$80k/yr.
• Adobe Commerce: $30k–$60k/yr license at this GMV band + $20k–$50k hosting (Adobe Commerce Cloud or self-managed) + dev. ~$80k–$140k/yr.

Net: BigCommerce Pro vs Magento Open Source on Hyvä is roughly the same money at $5M GMV. Adobe Commerce is the premium tier. Move the GMV to $25M and the gap inverts — Magento OS gets cheaper relative to BC Enterprise.

For a typical mid-market store (1k–10k SKUs, B2B + B2C, 2 years of order history): $15k–$30k and 8–12 weeks end-to-end.

Phases:

• Weeks 1–2: Discovery + architecture + Magento + Hyvä install + dev environment.
• Weeks 3–5: Catalog + customers + orders migration via Cart2Cart / LitExtension or a custom export-import. URL redirect map (BC URLs differ from Magento’s — SEO-critical).
• Weeks 4–7: Theme rebuild on Hyvä (BC Stencil themes don’t port; Hyvä is the modern replacement).
• Weeks 5–8: Payment / shipping / tax reconnection, B2B feature setup, app replacements (each BC app needs a Magento equivalent).
• Weeks 8–10: ERP / WMS / ESP integrations.
• Weeks 10–12: UAT, performance tuning, cutover with 14-day rollback window.

Faster & cheaper paths exist for very simple stores ($5k–$10k, 6 weeks). Bigger / heavier-customization stores creep to $50k+ and 16 weeks — budget accordingly.

BigCommerce B2B Edition (powered by BundleB2B, owned by BC) is real, well-built, and shipped reliably — but it’s an add-on (~$2,000+/mo on top of plan, often Enterprise-tier only). Magento native B2B (Open Source extensions or Adobe Commerce-bundled) is deeper at the seams.

Where they’re comparable:

• Companies / sub-accounts / role hierarchy — both do this
• Customer-segment pricing — both do this
• Quote workflow — both do this; Magento quote-to-order conversion is more flexible
• Net-30 / Net-60 invoicing — both do this

Where Magento goes deeper:

• Catalog gating by company / category / SKU / segment — Magento has the granularity, BC’s rules engine is shallower
• Multi-step approval flows with custom logic — Magento can do almost anything via plugins; BC’s approval rules are template-bound
• Tiered pricing matrices with quantity breaks per company — both do this; Magento doesn’t flinch at 50 segments × 10k SKUs
• ERP-driven catalog (real-time stock, real-time price) — Magento self-hosted lets you do this directly; BC needs API-bound apps and runs into rate limits

If your B2B is straightforward, BC B2B Edition is fine. If your business rules are weird, Magento.

Stencil is BigCommerce’s theme framework: Handlebars templates + SCSS + a few Stencil-specific helpers + the Storefront API for client-side data. It’s well-documented and powerful for theming.

What Stencil handles cleanly: layout customization, component swaps, custom widgets, A/B-able UI, custom checkout (single-page checkout v3 is editable), custom storefront API consumers.

Where Stencil hits ceilings:

• Server-side business logic. You can’t hook into BC’s pricing engine, cart-rules engine, or tax engine the way you can with Magento plugins. Workaround: build an app that proxies the Storefront / Cart APIs — works, but adds latency and a hosting bill.
• Custom DB columns / tables. No direct DB access — you store custom data in metafields (limited size) or in your own backend service synced via API.
• Heavy catalog logic. Real-time stock / real-time price / customer-driven catalog visibility — doable via Channels API but rate-limit-bound.
• Complex multi-currency rules. BC handles standard multi-currency well; weirder rules (per-country tax-inclusive vs tax-exclusive on the same SKU) need apps or workarounds.

Magento gives you full PHP access — you can rewrite the cart engine if you genuinely need to. Different toolboxes.

BC publishes per-plan rate limits on Storefront, Catalog, Cart, and Checkout APIs. Rough numbers (subject to change):

• Storefront API: ~200 req/sec on Standard, 450 on Pro, custom on Enterprise
• Catalog (V3) API: ~150 req/sec sustained
• Cart / Checkout APIs: lower, with stricter burst limits

When they bite:

• Catalog sync from ERP. If NetSuite pushes 8k SKU updates an hour during inventory recon, you’ll throttle. Workaround: batch + queue + retry.
• PIM-driven content updates. Same problem.
• Headless storefronts. Each PDP load makes ~5–10 Storefront API calls; high-traffic homepage = limit-bound.
• 3rd-party app stack on Pro+. Loyalty + reviews + search + abandoned-cart all eat the same per-store budget.

Magento self-hosted has no API limits beyond your own infrastructure — bottleneck moves to MySQL, app server, cache. You control the dial. Different problem space, but the dial is yours.

Magento multi-store is the gold standard: one admin, multiple stores, multiple websites, multiple store views, shared customers / catalog / inventory or independent — you choose. Three brands sharing 80% of catalog with separate themes / domains / currencies / tax rules — native.

BigCommerce Multi-Storefront (released 2022) is real and improving but constrained:

• Available on Pro + Enterprise plans only
• Each storefront shares the catalog; per-storefront pricing / inventory rules are limited
• Customer accounts can be shared or per-storefront, configurable
• Separate themes per storefront, separate checkout

For 2–3 closely-related brands sharing most catalog: BC Multi-Storefront is fine and easier than Magento (no DevOps multiplier).

For 5+ stores, deeply-different catalog rules per store, B2B + D2C splits, country-specific tax / pricing logic: Magento bends, BC starts working against you.

BigCommerce defaults to good Core Web Vitals on Stencil + their CDN: LCP under 2.5s on average for stock themes, decent INP, low CLS. SaaS hosting is tuned by their infra team — you don’t need a performance specialist.

Magento default Luma is poor on CWV. Magento on Hyvä is excellent: LCP under 1.5s achievable with proper hosting + caching (we’ve hit 1.0s on production stores). But it requires the right setup — Hyvä theme + Varnish + Redis + a competent host + optimized images. Without those, default Magento can hit 5s LCP and tank Lighthouse.

Net: BC is good-by-default. Magento is great-with-effort. If your team can’t / won’t invest in DevOps, BC is the safer CWV bet. With a Hyvä team, Magento beats BC on raw speed.

Both can rank well; both can rank badly. Differences in 2026:

• URL control: Magento gives you near-total URL flexibility (URL rewrites table, per-store URL keys). BC gives you URL key control on products / categories / pages but the underlying URL structure (/products/, /categories/) is fixed without a custom domain hack.
• Schema markup: Magento on Hyvä with the schema modules I publish (Product, Breadcrumb, FAQ, Article, Organization) is best-in-class. BC ships basic Product schema; deeper schema needs apps.
• Sitemaps: both auto-generate; Magento can be customized (segmented sitemaps per store, hreflang sitemaps); BC’s is fine but rigid.
• Hreflang: Magento native via store views or via a hreflang module. BC supports hreflang in Multi-Storefront but the implementation is shallower.
• Page speed: covered above — both can be excellent.
• Custom landing pages, blog, programmatic SEO: Magento with CMS pages + the right modules gives you a programmatic SEO surface. BC’s blog is basic; large landing-page programs need 3rd-party apps.

For pure SEO surface area, Magento has more levers. For getting-it-right-without-thinking SEO, BC is fine.

BigCommerce: BC handles infrastructure, security patching, uptime, Black-Friday scaling, PCI scope. Risk shifts to vendor risk — pricing changes, deprecations, feature ceilings you can’t code around. Outages are BC’s problem (and rare).

Magento self-hosted: you own infrastructure risk. Hosting + DevOps + security patching + WAF + Black-Friday scaling + PCI compliance scope are on you (or your hosting partner). Upside: no platform risk, no surprise pricing shifts, no “feature deprecated next quarter”.

Adobe Commerce Cloud: middle ground. Adobe handles infra (mostly), you handle code. More expensive ($30k+/yr); fewer DevOps headaches.

For a 5-person ecom team without DevOps capacity, BC is the lower-risk choice. For a 20+ person team with engineers, Magento is sustainable.

BigCommerce: PCI DSS Level 1 certified at the platform level. As a merchant on BC, you generally complete SAQ-A (the lightest self-assessment) because cardholder data never touches your servers. Easy.

Magento self-hosted: depends on your checkout. Use a hosted payment gateway (Stripe Checkout, PayPal, Braintree hosted-fields) and you’re SAQ-A or SAQ-A-EP. Use server-side card capture (rare in 2026, not recommended) and you’re SAQ-D — full PCI scope, audits, quarterly scans, expensive.

Adobe Commerce: similar to Magento OS; the official Adobe Commerce + hosted-gateway setup is SAQ-A or SAQ-A-EP.

For 95% of merchants on either platform, PCI is SAQ-A — equivalent burden. For high-volume merchants who need cardholder data residency for fraud / chargeback workflows, the equation gets more nuanced.

NetSuite + BigCommerce: well-trodden path. Celigo, Boomi, Jitterbit all have BC + NetSuite connectors. Out-of-box covers items, customers, orders, payments. Custom logic = paid customization on the iPaaS side. Real-time-ish (10–30 min lag).

NetSuite + Magento: equally well-trodden. Celigo, Boomi, plus Magento-specific connectors (MageWorx, Magenest, custom). Real-time achievable via direct DB or queue subscription.

SAP + BigCommerce: doable via SAP Commerce Cloud (different product), or SAP ↔ iPaaS ↔ BC. Less polished than NetSuite path.

SAP + Magento: SAP’s own ecom-bridge tools target Magento natively in some setups (Hybris connector); B1 / S/4HANA ↔ Magento via Boomi or custom.

Odoo + either: Odoo has reasonable connectors for both. Magento has the longer history.

Net: BC is fine for stock NetSuite. Magento is more flexible for custom ERP rules (especially when you need DB-level access for stock-allocation logic).

BigCommerce: native VAT / GST / US sales-tax via Avalara AvaTax integration (most merchants), TaxJar (cheaper), or built-in basic tax tables. EU VAT-MOSS / OSS supported. UK VAT post-Brexit handled via tax tables. Generally clean for under 10 jurisdictions; gets fiddly past that.

Magento: same toolbox (Avalara, TaxJar, Vertex on Adobe Commerce, native tax tables). More flexibility on tax-rule edge cases — B2B tax-exempt customers, mixed product-class rules, country-of-origin-driven rates. Adobe Commerce + Vertex is the heavy-duty enterprise stack.

Where Magento wins: complex tax-class logic per customer-segment, mixed B2B / B2C rules in the same checkout, country-of-import-driven HS-code calculations.

Where BC wins: simple multi-region D2C with standard Avalara rules — setup is faster, fewer edge-case bugs.

"Break" is too strong, but it does become operationally painful. Specifically:

• Database: WooCommerce stores products in wp_posts + wp_postmeta, which is fine for blog posts but a poor fit for a 10k-row catalog. Variant SKUs explode the meta table. By 10k SKUs the meta table is often 5M+ rows, making attribute filtering slow.
• Search: default WP search is LIKE %term% on titles. Past a few thousand products you need ElasticPress or Algolia — both are paid plugins or external services.
• Admin: the products list pagination starts choking at 5k. Bulk-edit, bulk-import, and even category-tree operations get slow. Operators feel it daily.
• Indexes: there’s no Magento-style indexer. Woo recomputes things on the fly, so each cart-rule, tax-rate change, or attribute update slows query response.

Magento was built for catalogs. EAV plus dedicated tables for inventory, prices, and search keep query times stable from 10k to 200k SKUs. The platform-architecture difference is real — not marketing.

$1M is roughly the crossover point. Below it, Woo is clearly cheaper; above it, Magento amortises better. Numbers:

WooCommerce 3-year TCO at $1M: Woo plugin $0. WordPress hosting (Cloudways / Kinsta WooCommerce plan) $80–$300/mo → $3k–$11k. Paid plugins (Yoast Premium, ACF Pro, WPML, Wholesale Suite, AffiliateWP, payment add-ons) $300–$2k one-time + $400–$1.5k/yr renewals → $1.5k–$6.5k. Theme $80–$500. Dev work $5k–$25k. Total: ~$10k–$45k.

Magento Open Source 3-year TCO at $1M: Magento $0. Hosting (Cloudways Magento / dedicated) $200–$700/mo → $7k–$25k. Hyvä theme licence $1,000–$2,000. Dev build $15k–$45k. Ongoing dev $1k–$3k/mo retainer → $36k–$108k. Search / monitoring $100–$400/mo → $3.5k–$14k. Total: ~$60k–$190k.

So at $1M GMV WooCommerce is 4–5x cheaper. The crossover happens because Magento’s fixed dev cost (build + retainer) doesn’t scale up much from $1M to $10M, but Woo’s app/plugin / hosting cost does scale up sharply (especially when you add WPML, WP Rocket, ElasticPress, Wholesale Suite, etc.) by $5M. The two lines cross around $1M–$2M.

Well-trodden path. Realistic numbers for a typical Woo store at 5k–15k SKUs:

• Timeline: 6–12 weeks for a clean Hyvä-themed Magento rebuild, including data import. Faster (4 weeks) for sub-1k SKUs with a stock theme; longer (16+ weeks) if you’re also re-platforming PIM / ERP or have heavy Woo customisations.
• Cost: $12k–$50k for the rebuild + data migration. Tools like cart2cart ($300–$1.2k) handle the bulk product/customer/order transfer; the rest is dev time on theme / payments / shipping / SEO redirects.
• What breaks: (1) WP-specific URL patterns don’t map 1:1 to Magento — you need 301-redirect maps for every product/category, (2) WP user passwords are bcrypt with a different salt, so users have to reset on first login, (3) Yoast SEO meta migrates only if you use a custom mapping plugin, (4) pretty permalink slugs in WP often clash with Magento’s URL rewrite logic.

The migration is more about SEO continuity than tech. Map redirects for every indexed URL, run both stores parallel for 30 days behind a feature flag, validate the redirect map covers ≥98% of organic traffic, then cut DNS.

Viable, but rare and only worth it for content-led businesses with substantial blog traffic and serious commerce needs.

Architecture: WordPress at blog.brand.com (or brand.com/blog/ via reverse proxy) for the editorial side. Magento at shop.brand.com (or brand.com/shop/) for commerce. Shared header/footer via a small JS include or shared theme tokens. Single sign-on optional.

What you gain: WordPress’s editorial tooling (Gutenberg, ACF, Yoast, custom-post-type ecosystem) for content; Magento’s catalog + B2B + multi-store for commerce. Each platform plays to its strength.

What it costs: two CMSes to patch, two hosts (or two Docker stacks), two deploy pipelines, two sets of plugins/extensions to keep up to date. Add ~$300–$1k/mo to ops. Internal linking between blog and shop has to be deliberate (ideally with shared canonical / hreflang strategy across the subdomains).

Who actually does this: media-driven brands (e.g. cooking sites with merchandise, fitness influencers with supplements, magazine-led DTC brands), enterprises with separate "content marketing" and "commerce" P&Ls, and agencies serving both audiences. For most stores, picking one platform end-to-end is cheaper and simpler.

WooCommerce can do basic B2B with the right plugins (Wholesale Suite, B2BKing, WholesaleX) but the gaps vs Magento Adobe Commerce B2B are real:

• Companies + sub-users: Magento has a Company entity with multiple buyers under one account (each with role/permission). Woo plugins fake this with WP roles or an ACF-driven org table — works, but the data model is bolted on.
• Quote workflow: Magento native (request → negotiate → convert to order). Woo: limited to the "Request a Quote" plugin, which emails a draft order — no multi-step approval, no comment thread.
• Requisition lists: Magento native. Woo: not really — saved carts, sometimes.
• Tiered customer-specific pricing: Magento handles unlimited price tiers per customer + per SKU + per quantity. Woo: customer-group pricing is fine; per-customer-per-SKU gets awkward at scale.
• Net-30 / payment terms: Magento allows custom terms per company (Net-15, Net-30, Net-45). Woo: deferred-payment plugins exist but require manual reconciliation.
• Approval workflows: Magento allows multi-level (requester → manager → finance). Woo: nothing native.

Verdict: B2B share >25% of revenue → Magento. B2B <25% with simple "wholesale price + Net-30" mechanics → Woo + Wholesale Suite is workable.

Possible, but architecturally fragile vs Magento.

WooCommerce multi-currency: via plugins like CURCY, WooCommerce Currency Switcher, or WPML’s WooCommerce Multilingual (which bundles a currency switcher). All do the same thing — convert prices on display, optionally per-region. Limitations: no per-SKU per-currency price control without bolt-on plugins; tax handling per region can break with mismatched plugin combos; checkout sometimes shows the wrong total under load.

WooCommerce multi-store: WordPress Multisite + WooCommerce + a sync plugin (e.g. Multilingual Press, Octolize Multistore). Each "store" is a separate WP site sharing users and (optionally) a master catalog. Pros: WP-native. Cons: catalog sync is plugin-dependent and breaks with bigger Woo updates; tax / shipping has to be configured per site; admin operators have to context-switch.

Magento multi-store: one admin → N websites → N stores → N store views. Each axis can override catalog, pricing, tax, currency, language, payment, shipping. Designed-in, not bolted-on.

Rule of thumb: 1–2 currencies, 1 region → Woo is fine. 3+ regions with different tax / shipping / catalog → Magento. The Magento setup is more upfront work but won’t fail in production.

Out-of-the-box Woo wins; with proper engineering, Magento + Hyvä wins.

• WordPress + WooCommerce + Astra/Kadence theme + WP Rocket: LCP ~1.6–2.2s, CLS ~0.05, INP ~150–200ms. Lighthouse mobile ~80–90. Achievable in days.
• Magento + Luma (default): LCP ~3.8s, CLS ~0.12, INP ~280ms. Lighthouse mobile ~45. Painful out of the box.
• Magento + Hyvä theme: LCP ~1.0–1.4s, CLS ~0.02, INP ~70–90ms. Lighthouse mobile ~95+. Takes 4–8 weeks to stand up but stable for years.

The hidden Woo issue: WP plugin sprawl. A typical mid-market Woo store accumulates 25–40 plugins over 2 years. Each adds JS, CSS, and DB queries. By year 3, LCP often drifts to 3–4s and Lighthouse drops to 50–70. Removing plugins to fix performance breaks features.

The hidden Magento issue: if you build on Luma without theme work, you’ll never beat 70 Lighthouse without buying perf-optimization plugins of dubious quality. Hyvä is the right call for any new Magento build.

Yes, but less than WP-people claim, and it doesn’t apply equally to ecommerce.

Where WordPress SEO genuinely wins: blog content, programmatic content pages, internal linking via Yoast/Rank Math’s automated suggestions, schema-markup automation via Yoast, and Gutenberg-driven landing pages with structured data baked in. For content-marketing-heavy sites, WordPress is best-in-class.

Where Magento catches up: product/category SEO. With the right modules (mage2kishan AdvancedSeo, StructuredData, Hreflang, FilterSeo, Crosslinks), Magento generates better category-landing-page SEO than Woo because the catalog data model exposes more programmatic levers (per-attribute landing pages, faceted-nav SEO without duplicate-content traps, native hreflang per store-view).

What actually moves rank: Core Web Vitals (Magento + Hyvä wins), URL structure (both controllable), structured data (both controllable), internal linking (WP wins for content, Magento wins for catalog), domain authority (platform-agnostic).

Verdict: content-marketing-led business → Woo SEO advantage matters. Catalog-led ecommerce business → roughly a wash, with each platform’s native strengths balancing out.

Different operational profiles.

Managed WP hosts (WP Engine, Kinsta, Cloudways WordPress, SiteGround):

• $30–$300/mo for sub-$1M GMV stores; $300–$1,500/mo for $1M–$5M.
• Auto-updates for WP core / PHP, automated backups, staging, CDN, page-cache, security firewall.
• Limitations: hosts often disable certain plugins (heavy ones, security-risky ones); SSH access is limited; you can’t pin PHP version freely.
• Best fit: store owners who don’t want to manage ops, willing to pay 2–3x raw VPS cost for the convenience.

Magento on Hetzner / AWS / Cloudways:

• Hetzner dedicated: $50–$200/mo for sub-$1M; $200–$600/mo for $1M–$5M. AWS / GCP: 2–4x that.
• Cloudways Magento: $50–$700/mo, similar managed-feel to WP Engine but with more Magento control.
• You own: PHP version, MySQL tuning, Redis cache, Varnish layer, OpenSearch indexing, security patches.
• Best fit: operators with a dev or retainer who value control and lower long-run cost.
• Adobe Commerce Cloud: $40k–$200k/yr for managed Magento — the WP-Engine-equivalent, but expensive.

Verdict: Woo hosting is "set and forget" cheaper at <$1M GMV. Magento hosting is meaningfully cheaper at >$5M GMV but requires real ops capability.

Roughly equivalent, as long as both use tokenized payment forms.

WooCommerce: with Stripe / Braintree / PayPal / Square (the standard payment plugins), card data never touches your server. PCI scope is SAQ A — the easiest tier, basically a self-attestation. Cost: $0 extra. With on-server gateways like Authorize.Net AIM (rare on Woo, but possible), PCI scope jumps to SAQ A-EP — quarterly ASV scans, $5k–$25k/yr in compliance work.

Magento: identical situation. With Stripe Elements / Braintree Hosted Fields / Adyen drop-in / PayPal smart buttons, you stay in SAQ A. With on-server payment forms (rarely seen on modern Magento), you move to SAQ A-EP or SAQ D.

Where Magento has a small edge: Adobe Commerce ships with PCI-DSS Level 1 attestation for hosting; Adobe Commerce Cloud is PCI-DSS Level 1 certified at the infrastructure layer. WooCommerce hosting is host-dependent — managed WP hosts (WP Engine, Kinsta) are usually PCI-DSS Level 1 at the infra layer too, but you have to confirm with each host.

Verdict: not a real differentiator in 2026. Both platforms with tokenized gateways = SAQ A.

Both can. Different paths.

WooCommerce ERP integration: mostly via middleware (Celigo, Workato, Boomi) or app-store connectors (e.g. WP-CRM, NetSuite for WooCommerce by Folio3). Pros: connector vendor handles schema diffs and auth refreshes. Cons: middleware costs $400–$2,000/mo indefinitely; custom field mappings often require service-desk tickets; real-time sync rare (most are 5-min batches).

Magento ERP integration: direct API integration is the norm. Magento’s REST + GraphQL APIs cover orders, customers, inventory, products. Custom modules can expose ERP-specific webhooks. Pros: no middleware tax (one-time $20k–$80k dev cost), real-time sync achievable, full control over data shape. Cons: you own the integration — when SAP changes its IDoc format or NetSuite deprecates a SuiteScript, you’re fixing it.

For Indian ERPs (Tally, Zoho Books): Tally Magento connectors are mature (Cynoteck, Gateway, Adobe Marketplace listings). Tally Woo connectors exist (TallyXL, others) but tend to be batched 1–6 hour syncs. For real-time inventory + orders, Magento has the edge.

Rule of thumb: under $1M GMV with stock NetSuite / Tally → Woo + middleware is faster. Above $5M GMV with custom SAP / NetSuite workflows → Magento direct integration is more reliable and 3-year-cheaper.

Both punt to specialised services for serious multi-jurisdiction tax. The differences are in how easy that integration is.

WooCommerce tax: built-in tax engine handles US sales tax (manual rates, or with WooCommerce Tax / Avalara plugin), EU VAT (manual config or with EU VAT Compliance plugin), UK VAT, Canadian GST. For complex setups (marketplace facilitator rules, B2B reverse-charge, OSS reporting), the standard path is Avalara, TaxJar, or Quaderno — all have first-party Woo plugins.

Magento tax: built-in tax-rate / tax-rule engine is more flexible (per-region, per-customer-group, per-product, per-store-view). Native support for tax-exempt customer groups, tax classes per attribute, and OSS reporting with the right module. Avalara, TaxJar, Vertex have official Adobe-Marketplace integrations.

EU VAT specifically: Magento handles distance-selling thresholds, OSS reporting, B2B reverse-charge natively or via official extensions. Woo needs a third-party (Vatify, Quaderno, EU VAT Compliance) for OSS / reverse-charge — works but adds plugin surface area.

India GST specifically: Magento has native + community modules (GST Manager, India GST by Webkul) covering CGST / SGST / IGST splits, HSN codes, e-Way bill linkage. Woo has plugins but they’re thinner.

Verdict: US-only retailer with simple tax → Woo + Avalara is the fastest path. EU + cross-border B2B, or GST-heavy India operation → Magento is more flexible.

3-year all-in TCO at $200M GMV, comparable scope (B2C with light B2B, 3 regions, mid-complexity catalog):

Adobe Commerce 3-year TCO at $200M: license $80–150k/yr → $240–450k. Adobe Commerce Cloud infra $30–80k/yr → $90–240k. Implementation (mid-tier or tier-1 SI) $400k–$800k one-time. Ongoing engineering retainer $30k–$80k/mo → $1.08M–$2.88M over 3 years. Adobe Marketplace extensions $50k–$150k. Total: ~$1.9M – $3.7M.

Salesforce Commerce Cloud 3-year TCO at $200M: license / revenue-share $500k–$1M/yr → $1.5M–$3M. Implementation (tier-1 SI: Capgemini, Accenture, Publicis Sapient) $800k–$2M one-time. Ongoing SI retainer $50k–$150k/mo → $1.8M–$5.4M over 3 years. Cartridges + integrations $100k–$300k. Total: ~$4.2M – $10.7M.

The TCO gap at $200M GMV typically lands at 2–3× in favor of Adobe Commerce. The gap narrows above $1B GMV but rarely closes — SFCC’s revenue-share pricing scales linearly with GMV; AC’s license tiers cap out.

SFCC pays for itself when the value of native Salesforce ecosystem integration exceeds the 5–10× license premium. In practice, that means:

• You already run on Salesforce. CRM (Account 360), Marketing Cloud (Journey Builder + Email Studio), Service Cloud (cases + returns), Mulesoft (integration), Tableau (BI). The data flows into a single Salesforce org with no middleware.
• Your CX is data-flow-driven. Personalization comes from CRM data (segments, lifetime value, service interactions). SFCC + Einstein AI plugs into that natively. Replicating it on Adobe Commerce requires significant integration engineering ($300k–$1M).
• Your Service Cloud reps need order context. SFCC orders surface inside Service Cloud with one click. Replicating on AC requires a custom integration that’s never as smooth.

If you don’t check those three boxes, SFCC’s license premium is a tax you’re paying for ecosystem features you don’t use. The break-even GMV where pure-economics tip toward SFCC is ~$2B+ — and even then, only when you’re Salesforce-native.

Yes — and the gap is wider on smaller-mid enterprises, narrower on $1B+ ones.

License floor comparison:

• Adobe Commerce: ~$22k/yr (Pro tier, <$1M GMV) → $190k/yr (Pro tier, $25M+ GMV).
• SFCC: ~$200k/yr entry tier (Starter or B2C Commerce). Realistically closer to $300–500k/yr at any meaningful scale because SFCC pricing is partly revenue-share (typically 0.3–0.5% of GMV).

At $50M GMV: AC ~$60k/yr license, SFCC ~$300k/yr → 5×.

At $200M GMV: AC ~$120k/yr, SFCC ~$700k/yr → ~6×.

At $1B GMV: AC ~$200k/yr (tier cap), SFCC ~$3M/yr (revenue-share keeps scaling) → 15×.

The ratio gets worse at scale because Adobe’s pricing tiers cap out while Salesforce’s scales linearly. License-only TCO is one of the strongest arguments to migrate off SFCC at $1B+ GMV.

The native integrations that are genuinely hard to replicate on Adobe Commerce:

• Account 360 + Order History. SFCC orders show up inside Salesforce CRM Account 360 with no middleware. Sales reps see commerce + service + marketing in one view. AC requires a custom Salesforce Connector ($150k–$300k build).
• Marketing Cloud Journey Builder triggers. SFCC events (cart-abandon, order-placed, return-requested) drop into Journey Builder out-of-the-box. AC integration needs MuleSoft or Patchworks middleware.
• Service Cloud case-from-order. Customer service rep clicks an order in Service Cloud → sees full order context, can issue refunds / RMAs. AC equivalent requires custom integration.
• Einstein AI personalization. SFCC + Einstein uses Salesforce’s data lake (CRM + commerce + marketing). AC + Sensei AI uses Adobe’s data lake. Different gravity wells.

The "AC can replicate this with a custom integration" answer is technically true but practically expensive — typical replication of native SFCC + Salesforce stack via AC + middleware runs $500k–$1.5M up-front + ongoing middleware fees. If you’re fully Salesforce-native, SFCC’s premium starts to make sense.

Different architectural philosophies, very different ceilings.

SFRA (Storefront Reference Architecture) on SFCC: JavaScript controllers, ISML templates, reference-architecture cartridges. You extend by adding cartridges to the cartridge-path; you can’t change the Demandware platform itself. No DB schema changes, no PHP, no custom services running on the server. Pros: guardrails, security, multi-tenant safety, easier upgrades. Cons: hard ceiling — anything outside the SFRA model requires either a workaround or escalation to Salesforce. Examples that get blocked: custom ERP write-paths, deep custom checkout flows, non-standard payment routing logic, complex B2B approval chains.

Magento module system on Adobe Commerce: full PHP modules with DB schema (db_schema.xml), observers, plugins (interceptors), GraphQL extensions, headless-API extensions, custom services. You can change anything — the platform is the framework. Pros: no real ceiling, extensions ship to Adobe Marketplace as products. Cons: more rope to hang yourself with; bad extensions slow the store; upgrades require regression testing.

Verdict: 80% of common features fit SFRA fine. The 20% that don’t are the reason enterprises re-platform from SFCC to AC.

Adobe Commerce wins on B2B depth + cost — it’s a single codebase. SFCC B2B is a separate product line with its own gaps.

Adobe Commerce B2B (native): Companies (parent-child accounts), Negotiable Quotes (request → negotiate → convert, with multi-step approvals), Requisition Lists, customer-segment catalogs (different products visible per customer group), tier prices per SKU per group, sales-rep impersonation, Net-30 / Net-60 / custom payment terms per customer, shared catalogs across stores. All in one codebase.

Salesforce B2B Commerce: separate product from B2C SFCC. Companies + multi-buyer accounts, contract pricing, MyAccounts portal, reorder workflows, quote requests. Capable but feels like a parallel platform — UX differs from B2C SFCC, admin is split, migration between B2B and B2C SFCC is non-trivial. Enterprise B2B is solid but you’re effectively running two SFCC instances if you have B2C + B2B.

Practical pick: if B2B is >25% of revenue and you want one platform serving both, AC wins. If B2B is the only line and you’re committed to Salesforce stack, SFCC B2B is fine. If B2B is <25% and bolted onto B2C, AC’s native B2B beats SFCC’s B2B-as-a-separate-product hands-down.

Both handle multi-region well, with different patterns.

SFCC multi-site model: sites + locales + currencies share product data via a Master Catalog. Per-site overrides for content, pricing, and merchandising. SI partners specialise in this — large enterprise multi-site SFCC builds are routine. Strengths: scales smoothly to 50+ locales sharing a base catalog. Weaknesses: per-region completely-different catalogs are awkward; you end up managing exclusion rules.

Adobe Commerce multi-store model: websites → stores → store views, with each axis able to override catalog, pricing, currency, language, tax, payment methods, shipping. Strengths: scales to 5–20 distinct stores with very different catalogs (different brands, different product mixes). Weaknesses: scaling to 50+ locales sharing a catalog needs more configuration discipline; not as turn-key as SFCC.

Implementation complexity:

• SFCC: 4–8 months for 5-region multi-site, $400k–$1M with tier-1 SI.
• AC: 3–6 months for 5-store multi-region, $150k–$500k with mid-tier agency.

Both ship hreflang correctly. SFCC wins on scale + locale density; AC wins on cost + per-store catalog flexibility.

Both can hit excellent CWV with engineering discipline. SaaS multi-tenancy is mostly neutral — it’s the architecture choices on top that matter.

SFCC defaults: SFRA-based stores hit Lighthouse mobile 75–85 out of the box. CDN edge is included (Salesforce’s eCDN), so static assets are fast globally. Performance ceiling: 90+ Lighthouse mobile with a clean SFRA cartridge stack and disciplined third-party tag management. Watch out: SFCC’s page generation is server-rendered and can be slow under heavy load if cartridges aren’t optimised.

Adobe Commerce defaults: Magento Luma sits at 45 Lighthouse mobile. With Hyvä theme (Tailwind + Alpine.js, ~95% less JS), it hits 95+. Adobe Commerce Cloud includes Fastly CDN, so static assets are also fast globally. Performance ceiling on AC + Hyvä is genuinely higher than SFCC defaults — but requires the Hyvä re-theme commitment ($25k–$80k).

Practical comparison: SFCC out-of-box > AC Luma out-of-box; AC + Hyvä > SFCC tuned. If CWV is a top-3 priority, AC + Hyvä is the strongest play. If you want fast defaults without a re-theme project, SFCC ships closer to that.

Both offer enterprise-grade SLAs but with different shapes.

Salesforce Commerce Cloud SLA: 99.99% uptime guarantee on the platform layer. Multi-tenant SaaS — Salesforce manages the entire stack, including Black Friday auto-scale. Service-credit refunds if uptime drops below 99.99% in a billing period. In practice: SFCC platform incidents are rare; when they happen, all SFCC customers are affected simultaneously.

Adobe Commerce Cloud SLA: 99.95% uptime on the standard tier; 99.99% on Pro tier (the one most enterprises run). Adobe manages infra, you manage application code. Auto-scale happens via Fastly + auto-scaling Magento application servers. Service-credit refunds if uptime drops below the threshold. In practice: AC Cloud incidents are usually customer-specific (your code bug, your extension regression) rather than platform-wide.

Self-hosted Adobe Commerce / Magento OSS: SLA is whatever you negotiate with your hosting provider (Cloudways, AWS, Hetzner). Typical: 99.9–99.99% depending on tier.

Verdict: SFCC and AC Cloud Pro are roughly equivalent on SLA. Self-hosted Magento needs more ops discipline to match. SLA differences are not the deciding factor — both are credible enterprise platforms.

Both directions are feasible. The economics + timelines differ significantly.

SFCC → Adobe Commerce (more common):

• Timeline: 6–12 months for a typical mid-enterprise re-platform.
• Cost: $250k–$1M for the rebuild + integration work.
• What migrates: catalog, customers, orders, content (CMS pages), redirects.
• What doesn’t migrate: SFRA cartridges (architecture is incompatible — must be rewritten as Magento modules), Einstein AI training data (can’t be exported in usable form).
• Driver: typically license-cost reduction (30–50%) + customization roadmap freedom.

Adobe Commerce → SFCC (less common):

• Timeline: 12–18 months. Discovery + architecture takes longer.
• Cost: $1M–$3M for the rebuild + tier-1 SI engagement.
• What migrates: catalog, customers, orders, content.
• What doesn’t migrate: custom Magento modules (must be rebuilt as SFRA cartridges), Sensei AI configuration.
• Driver: typically Salesforce ecosystem consolidation (acquired company brings them under group’s SFCC standard).

Both directions are well-trodden paths. The business case must be clear because the project costs are 7-figure regardless of direction.

Different talent gravity. Affects both initial cost and ongoing ops.

SFCC partner ecosystem: dominated by tier-1 SIs — Capgemini, Accenture, Cognizant, Publicis Sapient (formerly Sapient), Astound Commerce, Tata Consultancy Services. Rates: $200–400/hr for senior, $150–250/hr for mid, $80–150/hr for offshore. Partner tiers (Strategic, Crest, Ridge) reflect Salesforce certification depth + book-of-business. Pros: deep Salesforce stack expertise, enterprise change-management capability. Cons: high day-rates, slow turnaround on small changes, premium "you must work with us" gating.

Adobe Commerce partner ecosystem: tier-1 SIs (Wunderman Thompson, Vaimo, Born Group, Diconia), mid-tier agencies (50–200 staff, e.g. Bounteous, Inviqa, Atwix), full-stack freelance specialists. Rates: $80–200/hr depending on tier and geography. Adobe Solution Partner program tiers (Specialized, Gold, Platinum) reflect certification + portfolio. Pros: wider pool, easier to swap partners, mid-tier agencies offer excellent value. Cons: tier-1 SI capability for very large transformations is thinner than Salesforce’s.

Talent supply matters because: when you need to scale from 6 to 12 developers, AC’s deeper pool wins. When you need a 50-person SI team for a global rollout, SFCC’s tier-1 SIs win. Pick the partner before picking the platform.

Both have surprise costs that don’t show up in the initial sales pitch.

Salesforce Commerce Cloud hidden costs:

• Revenue-share creep. SFCC pricing scales with GMV — every successful year increases license cost. Renewals at $1B GMV often surprise CFOs.
• Sandbox limits. SFCC sandboxes are quota-limited (development sandbox, staging, etc). Hitting limits means buying more environments at premium rates.
• Tier-1 SI lock-in. The certified-SI ecosystem is a small club; rate negotiations are limited. Switching SIs is expensive (knowledge transfer + certification).
• Cartridge upgrades. Salesforce platform upgrades sometimes break cartridge integrations; tier-1 SI fixes are billable.
• Einstein AI seat fees. Salesforce charges per-seat for Einstein features that started "free" in evaluations.

Adobe Commerce hidden costs:

• Hosting overruns at peak. Adobe Commerce Cloud auto-scales but the bill follows. Black Friday spikes can 2–3× a quarterly hosting bill.
• Extension dependency hell. Mid-market AC stores accumulate 30–60 third-party extensions. Upgrades become regression-test marathons. Budget $20k–$80k/yr for extension maintenance.
• Security patch lag. Adobe ships security patches monthly; if you don’t apply within 30 days, breach risk rises sharply. Patch-application is real ops work — $5k–$20k/patch with regression.
• Hyvä theme licensing. Hyvä is paid (~€1k/yr/store-view + per-developer fees). Often missed in initial budgets.

Both platforms cost more in year 2 than year 1 — plan for it.

The codebases are 99% identical. The actual AC-only modules are a finite, well-known list:

• Magento_Company — multi-buyer B2B accounts with hierarchy, role permissions, shared catalogs, and company-specific pricing.
• Magento_NegotiableQuote — RFQ workflow with multi-round price negotiation between buyer and merchant.
• Magento_RequisitionList — recurring SKU lists for repeat B2B orders.
• Magento_PageBuilder — the drag-drop visual CMS editor.
• Magento_Staging — schedule price / content / promo changes to a future date with preview-mode.
• Magento_GiftCard, Magento_Reward, Magento_Rma — gift cards, loyalty points, return-merch authorisation.
• Magento_CustomerSegment — rules-based audience builder for promos and content.
• Adobe Commerce Cloud — managed Pro/Enterprise infrastructure (not a module, but bundled).

That’s the actual delta. Everything else — PWA Studio, GraphQL, Hyvä compat, REST — is identical between editions.

Rough rules I’ve seen hold across ~30 Magento stores:

• Pure D2C, no B2B: ~$25M GMV. Below that, OS plus a Page Builder alternative + scheduled-promo extension covers the gap for $5–10k one-time vs $30–80k/yr recurring.
• B2B-heavy (50%+ B2B share): ~$10M GMV. Native Companies + Negotiable Quotes + Requisition Lists save real dev hours; extension stack hits 80% feature parity but the last 20% gets expensive.
• Regulated industry (finance / healthcare / gov): the SLA + direct-from-Adobe patching alone justify the license at almost any GMV — you’re paying for compliance posture, not for features.
• Already in Adobe stack (Analytics + Target): integration value is real, knock $20k off the break-even threshold.

The break-even calculation is rarely about features alone. It’s features + ops time saved + risk reduction. On a $10M B2B store with a small ops team, the AC license can pay back in 4–6 months purely on hours saved by Page Builder + Companies.

~85% parity, yes. The OS B2B stack I recommend in 2026:

• mage2kishan B2B Suite (or Aitoc / Bizzbee / Magenest) — multi-buyer accounts, role permissions, company-specific catalogs — ~$1.5–3k one-time.
• Mageworx Negotiable Quotes — RFQ workflow with multi-round negotiation — ~$400.
• Aheadworks / Mageplaza Requisition Lists — recurring SKU ordering — ~$300.
• Net-30 + Purchase Order: Mageplaza Net Terms or custom (~$1k one-time).

Total ~$3–5k one-time vs AC’s $30–80k/yr recurring. What you don’t get from the OS stack: AC’s admin UX polish on the company-account flows, and tight Adobe-Analytics-driven segment-based pricing. For most B2B stores under $15M GMV, the OS stack is the right answer.

Yes, three viable paths:

• Magezon Page Builder Plus (~$300) — the closest functional clone of AC Page Builder. Drag-drop rows / columns / banners / sliders / product blocks. Ships with 60+ pre-built widgets. The default OS recommendation in 2026.
• Mageplaza Page Builder (~$200) — lighter, faster, fewer widgets but enough for most marketing-led teams.
• Hyvä + Tailwind + Builder.io / Sanity: headless-ish CMS, marketers edit in Builder/Sanity, content syndicates to the Hyvä storefront. Most flexibility, highest dev investment.

None of these match AC Page Builder’s native-Magento-block awareness (e.g. dynamic catalog blocks). For most OS sites the Magezon route covers 90% of marketing-team needs at 1% of AC’s recurring cost.

Less complex than a re-platform, more involved than a routine upgrade. Same database schema, vast majority of code carries over unchanged. What actually happens:

• License + Cloud activation — week 1.
• Extension audit: identify which OS-only extensions duplicate AC native modules (often 4–8 of them). Plan to remove or replace — 1–2 weeks.
• Schema reconcile: AC ships extra DB tables for staging / GiftCard / Rma / CustomerSegment. Setup:upgrade handles most; expect 1–2 days of edge cases.
• B2B re-platform: if you had OS B2B extensions, migrate data into Magento_Company tables — 1–3 weeks depending on volume.
• Page Builder content: existing CMS content stays as legacy WYSIWYG; new content uses Page Builder. No mass migration needed.
• Regression QA + cutover — 2 weeks.

Total: $30–100k all-in depending on customisation depth and extension count. 6–10 week project for a typical $10–30M store.

Cloud adds three things on top of the AC license:

• Managed infrastructure: Adobe runs the AWS-hosted environment with auto-scaling, Fastly CDN, New Relic APM, ElasticSearch, RabbitMQ, and Redis pre-configured. You don’t pick a hosting provider or DevOps a server cluster.
• Pro vs Starter tiers: Pro adds dedicated infra, multi-environment (integration / staging / prod), and 99.99% uptime SLA. Starter is shared infra, single environment.
• Bundled monitoring + WAF: Fastly WAF, Adobe Stock images, integrated Adobe Analytics — rolled into one invoice instead of stitched together.

What it costs: typically $80–250k/yr all-in (license + infrastructure + Fastly + monitoring), vs ~$30–120k/yr for self-hosted AC + your own AWS / hosted infra. The premium is real; whether it’s worth it depends on whether your team wants to own the DevOps. For most $20M+ stores without a dedicated DevOps function, Cloud earns the markup.

Yes, but the tiers aren’t public — Adobe quotes per-deal. What I’ve seen in the wild (2024–2026):

• Adobe Commerce (self-hosted), low-GMV tier: ~$22–35k/yr. Stores up to ~$1M GMV.
• Adobe Commerce, mid-GMV tier: ~$35–60k/yr. Stores $1–25M GMV.
• Adobe Commerce, high-GMV tier: $60–120k+/yr. Stores $25M+ GMV.
• Adobe Commerce Cloud, Starter: ~$50–80k/yr (license + bundled infra).
• Adobe Commerce Cloud, Pro: $80–250k+/yr (multi-env, dedicated infra, full SLA).

The tiers ratchet on revenue audit (annual). If your GMV grows past the threshold, Adobe will renegotiate at renewal — this catches a lot of fast-growth stores by surprise. Always model the next two tiers when budgeting.

What you get with AC support (Pro / Cloud Pro):

• Severity 1 (production down): 1-hour response, 24/7, phone-callable. Adobe engineer engages until resolution.
• Severity 2 (major function impaired): 4-hour response, business hours.
• Severity 3 / 4 (minor / question): 1 business day, ticket-only.
• Direct security patch delivery with pre-disclosure window before public CVE.
• Adobe Technical Account Manager (TAM) at Pro Cloud / Enterprise tiers.

What it doesn’t cover: bugs in your custom code or third-party extensions (those are agency / dev-team scope), and SaaS-level zero-downtime guarantees (you still need DevOps / agency on retainer for deployment, perf tuning, custom code support). The SLA is genuine; it’s also genuinely scope-limited to platform code. For most non-regulated stores, an agency retainer plus Mage Report patching service ($100–500/mo) covers the practical equivalent.

Both editions get the same patches; the difference is delivery channel and timing.

• Cadence: Adobe ships ~4 quarterly Magento Security Patches per year, plus emergency hotfixes for critical CVEs (typically 2–4 of those per year).
• AC delivery: patches available via Adobe support portal with pre-disclosure window (~1–2 weeks before public CVE). AC customers can patch ahead of public disclosure.
• OS delivery: patches drop to GitHub / Composer simultaneously with public CVE disclosure. No pre-disclosure window.
• Application urgency: high. Magento has been actively exploited (Magecart skimmer attacks 2021–2024). Stores 30+ days behind on patches show up in scanning. Mage Report / Sansec / Sucuri all monitor patch status publicly.

For stores in regulated industries with mandatory patch-window SLAs, AC’s pre-disclosure + direct delivery is genuinely load-bearing. For typical D2C stores, OS + a patching retainer ($200–500/mo for an agency to apply patches within 7 days) covers the operational equivalent.

Mostly AC, but it’s nuanced:

• Adobe Analytics: AC ships a native connector module with pre-built event mapping (product views, add-to-cart, checkout, purchase). OS can integrate via Adobe Launch (free) or a community connector — works, just more setup hours.
• Adobe Target: integration is at the JavaScript layer (mbox / at.js), so works on either edition. AC adds tighter customer-segmentation handoffs.
• Adobe Experience Manager (AEM): integration is via API. Both editions can talk to AEM equally well; the AEM commerce-pages connector targets AC by default but works on OS with config.
• Real Customer DataPlatform (RT-CDP): Adobe pushes this into AC contracts; OS doesn’t get the bundled hook.

If you’re fully committed to the Adobe Experience Cloud stack, AC + AEM + Analytics + Target sold together gets meaningful Adobe-bundle pricing. If you’re only using one Adobe product, OS + a custom connector is cheaper.

Most don’t. The breakage rate I’ve seen:

• Hyvä + Hyvä-compatible extensions: 100% carry over — AC and OS run the same Hyvä.
• Plain OS extensions from major vendors (Aheadworks, Amasty, Mageplaza, Magezon): ~95% work unchanged. Edge cases: extensions that monkey-patch core checkout or admin grids may collide with AC’s versions.
• OS B2B extensions: ~50% of these duplicate AC’s native B2B modules. Plan to remove them and migrate data into Magento_Company tables. Don’t leave both running.
• Custom modules: nearly always carry over. The collisions are with AC-native features (Staging / GiftCard / Rma / CustomerSegment) — if your custom module duplicates one, refactor.

Practical migration plan: pre-flight audit of every installed module against AC’s module list, decide remove / keep / replace per extension, run side-by-side regression in staging. 1–2 weeks of focused work for a typical 30-extension store.

More negotiable than most buyers realise. Levers I’ve seen work:

• Multi-year commit: 2–3 year contracts unlock 10–20% off list. Adobe’s sales team is targeted on commit-length.
• Migration credits: if you’re moving from OS, ask for a migration discount — Adobe runs programs for OS-converts at 15–25% off year 1.
• End-of-quarter timing: Adobe FY ends late November. Quarter-end deals (March / June / September / December) get better terms.
• Bundle with Adobe Experience Cloud: if you’re also buying Analytics or Target, the bundled price is materially lower than line-item.
• Competitive bid: Adobe sales will discount when shown a serious BigCommerce / Shopify Plus / Salesforce CC quote. Even if you’ve decided, get a reference quote to bring to the table.

Realistic outcome: 15–30% off list price for most committed deals. Don’t accept the first quote; renewal negotiations also leave 10–15% on the table if you push.

No — Claude Code is paid, but the entry tier is approachable. The cost has two parts:

• Claude Pro subscription: $20/mo. This unlocks Claude Code access in the IDE/CLI plus a baseline message allowance.
• Metered API usage: beyond the included allowance, you pay per token (currently ~$3 per million input tokens and ~$15 per million output tokens for Sonnet, ~$15/$75 for Opus).

Real-world bills:

• Solo dev, 4 – 6 hours/day Claude Code use: $25 – $80/mo all-in
• Small team (5 devs), heavy daily use: $300 – $700/mo for the whole team
• Agency, 15 devs + CI workflows + sub-agents: $1,000 – $2,500/mo

Compare to Copilot ($19/mo flat per seat, no metering) or Cursor ($20/mo + their own model API on top, similar metered model). Claude Code is rarely the cheapest, but it’s usually the highest-leverage on a per-hour-saved basis.

Depends on the refactor shape:

• Single-file polish (rename variables, extract method, tighten types): Cursor and Copilot are both excellent; Claude Code is overkill for this. Cursor’s Tab autocomplete + Cmd+K inline edit is genuinely best-in-class for this use case.
• Multi-file refactor in a known small codebase: Cursor does well — its agent reads workspace files and applies coordinated edits. Claude Code matches it.
• Multi-file refactor in a deep codebase (Magento `vendor/` + custom modules + generated DI): Claude Code wins clearly. Cursor often misses the cross-file dependencies; Claude Code reads the whole graph including vendor.
• Batch refactor across 20+ files (port templates, migrate APIs): Claude Code with sub-agents is the only one of the three that does this well. Cursor can’t parallelise; Copilot has no agent at all.

For day-to-day “clean up this function” work, stay in your IDE’s native AI. For systemic refactors, switch to Claude Code.

Yes, and many devs do. The pattern that works:

• Cursor (or Copilot) in the IDE for inline autocomplete, “explain this function” chat, and quick single-file edits
• Claude Code in a terminal pane for multi-file work, batch ops, sub-agent workflows, and CI integration
• Same repo, both tools read it — no conflict; they don’t step on each other
• CLAUDE.md + .cursorrules can both live in the repo, each tool reads its own file, they don’t fight

Cost note: $20 + $20 + metered API = $50 – $120/mo for a solo dev running both. Worth it for senior devs whose hourly rate is $100+; overkill for juniors learning the basics.

The only real downside is context-switching cost — if you’re jumping between Cursor’s chat and Claude Code’s terminal every 5 minutes, you lose flow. Most devs settle into “Cursor for inline, Claude Code for big tasks” within a couple weeks.

Magento is a deep PHP codebase where the answer to almost any question lives across 5 – 15 files: a controller in `app/code/`, an interface in `vendor/magento/framework/`, a generated factory in `var/di/`, an event subscription in `etc/events.xml`, a plugin in another module’s `etc/di.xml`. Claude Code reads all of those by default; Copilot reads the active editor and a small surrounding window.

Concrete examples where Copilot routinely fails on Magento:

• “Add a custom attribute to product save flow” — needs to find existing observers, plugins around `Product::save()`, and the right entity_type. Claude Code finds them in vendor and proposes the correct extension point. Copilot suggests editing `Product.php` directly (vendor edit — disaster).
• “Why is this category page slow?” — needs to trace through layered nav, indexers, full-page cache. Claude Code reads all the relevant files. Copilot guesses.
• “Generate the db_schema.xml for this new module” — needs to know the format precisely and link to the module’s composer.json. Claude Code gets it right; Copilot often produces invalid XML.

It’s not that Copilot is bad — it’s that Magento’s shape rewards filesystem access and ground-truth reading, which is Claude Code’s home turf.

None of the three know Hyvä natively out of the box — Hyvä is a niche enough framework that none of the model training cuts include deep Hyvä code in volume. But they handle it differently:

• Claude Code: reads `vendor/hyva-themes/` directly, picks up the patterns from real Hyvä modules in your project. After a few prompts it learns the Tailwind utility class conventions, Alpine.js patterns, and Magewire component structure your project uses. CLAUDE.md can capture house Hyvä rules (no inline JS, prefer Magewire over Alpine for server state, etc).
• Cursor: reads workspace including Hyvä parent theme if you scope it in. Reasonable but you have to set it up. .cursorrules can hold Hyvä conventions.
• Copilot: guesses based on Tailwind + Alpine training data. Often produces working-looking code that misses Hyvä conventions (uses jQuery instead of Alpine, edits Luma templates by mistake).

Practical advice: feed your AI tool the Hyvä docs and 2 – 3 example modules from your project once, then it picks up the patterns. Claude Code does this most reliably because it reads the most context.

Yes — `.cursorrules`. It serves the same purpose: a per-repo file the agent reads on every prompt, holding house rules and conventions. The differences:

• CLAUDE.md (Claude Code): Markdown, conventionally large (5 – 50 KB). Often holds detailed memory: tech stack, conventions, deployment process, recent decisions, links to related docs. Read aggressively by the agent every prompt. Supports nested `CLAUDE.local.md` for personal additions.
• .cursorrules (Cursor): Plain text, conventionally smaller (1 – 5 KB). Best for short conventions ("never use jQuery", "prefer composition over inheritance"). Read by the agent on each prompt but lighter weight.
• Copilot: no equivalent. You can put rules in repo READMEs but Copilot doesn’t read them deterministically.

For Magento projects, CLAUDE.md is meaningfully better because there’s a lot to encode (no vendor edits, plugins/observers/preferences only, Hyvä conventions, deploy flow, MFTF setup, etc). Cursor’s lighter `.cursorrules` works but you’ll bump into its size limits.

Copilot Workspace is GitHub’s answer to agentic coding — a step beyond inline Copilot. It works at the issue level: paste an issue, Workspace plans the change, generates a PR, you review. The feature set lands closer to Claude Code than to inline Copilot.

Where they overlap:

• Both read multi-file context
• Both produce diff-then-apply changes
• Both can run tests / commands as part of the loop

Where they differ (Claude Code wins):

• Claude Code is filesystem-native; Workspace is GitHub-cloud-native (your code uploads to Microsoft cloud per session)
• Claude Code reads `vendor/` automatically; Workspace can but it’s scoped to repo content (vendor/ usually `.gitignore`d in Magento)
• Claude Code has CLI / Python SDK; Workspace is GitHub web UI
• Claude Code sub-agents are first-class; Workspace runs one workflow at a time
• MCP — Claude Code yes, Workspace no

For pure GitHub-flow shops where issues + PRs are the primary unit of work, Workspace is genuinely useful. For agency Magento work where the unit is “ship 8 SEO pages by Friday,” Claude Code remains ahead.

All three offer enterprise privacy postures, but the defaults differ:

• Anthropic / Claude Code: by default, prompts are not used to train models. Enterprise plans include zero-data-retention (ZDR) toggle, SOC 2 Type II, optional region pinning. Most explicit privacy stance of the three.
• OpenAI / Cursor: Cursor wraps multiple models (OpenAI, Anthropic, custom). Default-off training opt-in, but the wrapper layer adds data passing through Cursor’s servers. Pro-tier privacy is decent; enterprise tier has stronger guarantees.
• Microsoft / GitHub Copilot: default-off training (suggestions are not used to train, per GitHub policy). Code goes to Microsoft cloud for inference. Enterprise tier adds IP indemnification (Microsoft will defend you if generated code triggers a copyright claim) — the strongest legal protection of the three.

Practical advice for ecommerce shops:

• Solo / small team: any of the three is fine on default settings — none train on your code by default
• Regulated industry / NDA-heavy work: enterprise tier on whichever you pick, ZDR on, region pinning if available
• Worried about IP indemnity: Copilot Enterprise has the clearest legal cover; Anthropic and Cursor have weaker indemnity language

Real numbers from teams I’ve advised:

• Copilot Business ($19/seat): 10 devs = $190/mo flat. No metering, no surprises. Lowest predictable cost.
• Cursor Business ($40/seat): 10 devs = $400/mo + variable model costs ($100 – $400/mo) = $500 – $800/mo total. Mid-range.
• Claude Code via Claude Pro ($20/seat) + API: 10 devs = $200/mo Pro + $400 – $1,500/mo API = $600 – $1,700/mo. Highest, but most leverage.
• Claude Code Enterprise (annual contract, often $50 – $100/seat with bundled tokens): 10 devs = $500 – $1,000/mo. Mid-range with the leverage of Claude Code.

The right way to think about cost: divide tool spend by hours-saved-per-dev-per-month. At a conservative 4 hours/week saved per dev (16 hours/month), even Claude Code at $170/seat is paying for itself if your blended rate is $50+/hour.

Common pattern at agencies: Copilot per-seat for daily autocomplete + a shared Claude Code budget for batch ops and CI. Best of both, ~$300 – $500/mo for 10 devs.

Claude Code, by a clear margin. The reasons map directly to its strengths:

• MFTF (Magento Functional Test Framework): XML-heavy, needs precise selectors, must match the actual UI of the page. Claude Code reads the layout XML, the phtml templates, and the existing MFTF tests — produces selectors that actually work. Cursor often misses the layout chain; Copilot guesses selectors and fails ~50% of the time.
• PHPUnit (unit + integration tests): Claude Code reads the existing test base classes, finds the right fixture pattern, generates tests that follow project conventions. Cursor does well in workspace; Copilot is hit-or-miss on Magento-specific patterns.
• Cypress / Playwright (E2E): all three are competent here — these frameworks have lots of training data. Pick whichever your team prefers.

Common Magento testing workflow with Claude Code:

1. “Read this controller and generate a PHPUnit test that covers the happy path + 2 error cases.”
2. “Now generate the MFTF test for the storefront flow.”
3. “Run them, fix any failures.”

15 minutes per controller, instead of 1 – 2 hours by hand. This is where the metered API cost pays for itself fast.

The friction points (in order):

• Editor familiarity: Cursor is a VS Code fork — Claude Code runs in your terminal alongside any editor. First week feels like a downgrade; second week feels like an upgrade once you stop trying to use Claude Code “like Cursor.”
• Inline autocomplete: Claude Code doesn’t do inline ghost-text suggestions. Most migrating users keep Copilot ($19/mo) for inline-only use, run Claude Code in a terminal pane for multi-file work.
• Mental model shift: Cursor is reactive (you steer every step). Claude Code is agentic (you give a goal, it plans + executes). Smaller prompts → bigger goals. Took me ~2 weeks to fully reset.
• CLAUDE.md migration: port your `.cursorrules` content into a CLAUDE.md, expand with project-specific conventions. Usually a 30-min job per repo.

Things that get easier:

• Multi-file refactors that Cursor used to half-finish
• Batch ops (build N pages, audit M modules) — Cursor genuinely can’t do these
• CI integration — Claude Code runs headless in GitHub Actions, Cursor doesn’t
• Reading vendor/ for ground truth instead of guessing

Most devs who migrate keep both for a month, then drop Cursor by week 5 unless they really love the inline UX (in which case they keep both forever — about $40/mo total, worth it).

Real cases where Cursor is the right pick:

• Pure frontend (React / Vue / Next.js) work: Cursor’s inline UX is genuinely the best autocomplete in this space. The codebase fits in workspace, vendor depth doesn’t matter, multi-file refactors are usually small.
• Designers + design engineers: visual workflows in Cursor (Tab autocomplete on Tailwind classes, inline Cmd+K edits, paste-screenshot-to-code) feel more natural than terminal-driven Claude Code.
• Junior devs learning the codebase: Cursor’s “explain this function” popovers are gentler onboarding than Claude Code’s agentic style. Lower learning curve.
• Latency-sensitive flows: Cursor Tab is sub-second; Claude Code multi-step plans take 10 – 60 seconds. For “hit Tab to accept, keep typing” rhythm, Cursor wins.
• Already-paid Cursor seats with no Magento work: if you’re a generic web shop with Cursor across 20 devs, the marginal cost of switching is high and the marginal value is low.

Honest take: for ~30% of ecommerce dev tasks (small inline edits, design work, learning), Cursor is genuinely better. For the other 70% (multi-file work, Magento depth, batch ops, CI), Claude Code wins. Most senior devs run both.

One well-defined checkout bug starts at $99 (~4h @ $25/hr) — reproduced on staging, root-caused, fixed, and verified with a real test order. A batch of bugs or one deep root cause behind several symptoms is the $499 Bug-Fix Sprint (~20h @ $25/hr). If checkout is down and you need 24/7 cover, that’s a custom retainer that can include a $2,499 stabilization sprint (~100h @ $25/hr). You get a fixed price before any work starts — no per-hour surprises.

That generic message means the place-order request threw a server-side exception that Magento hid from the shopper. The real cause is in var/log/exception.log — usually a payment-gateway error, a third-party plugin throwing during quote-to-order conversion, or an Area code not set in a custom observer. We read the matching log line, reproduce it on staging, fix the throwing code, then place a full test order to confirm it’s gone.

An empty shipping step (“No shipping methods available”) usually comes from a carrier-config error, a broken rate request to a carrier like ShipperHQ or table rates, a country/region restriction on the method, or a cached checkout/index/index layout. We trace the rate request end to end — carrier settings, the quote address, and the network call — and fix the layer that’s actually returning zero rates, then confirm rates render for the regions you sell to.

A blank payment step or an endless spinner is nearly always a JavaScript error. We open the browser console first — a failed requirejs dependency, a payment-method renderer that throws, or a broken KnockoutJS template stops the whole step from rendering. We fix the failing component (not just hide the error) so payment methods render and the place-order button works, then test each enabled gateway.

Stale totals — subtotal, tax, or discount not refreshing when you change quantity, address, or shipping — come from a broken totals collector, a stale checkout-data / customer-data section, or a KnockoutJS component that isn’t subscribing to the totals observable. We repair the data flow so the displayed totals always match what the order will actually charge, and regression-test it across guest and logged-in carts.

That error means the form key the page sent doesn’t match the session. The usual causes are a full-page cache (Varnish) or CDN (Cloudflare) caching the form key, a session-cookie domain or path mismatch, or an aggressive caching rule on the checkout URL. We find which layer is serving a stale key — cache, cookie, or config — and fix the rule so genuine submissions go through without weakening CSRF protection.

Guests getting bounced to login or stuck in an email-step loop is usually a config flag (Allow Guest Checkout off, or per-website scope), a customer-group restriction, or a session/cookie issue that loses the guest cart. We check the checkout config at the right store scope, confirm the guest cart persists across steps, and fix whatever is forcing the login redirect — then test a full guest order.

We reproduce and fix on staging first, every time. Checkout is the most revenue-sensitive part of your store, so we never debug live by trial and error. We confirm the fix on staging with a full test order, then deploy to production during a low-traffic window and place one real verified order to prove it works. If you have no staging environment, we set up a safe clone before touching anything.

Emergency checkout-down issues get a first response in under 4 hours on a retainer or emergency ticket. A single, well-defined bug — rates not showing, totals not updating, agreements blocking submit — is typically fixed in 24–48 hours end to end. Deep root causes spanning several symptoms run on the Bug-Fix Sprint, usually within a few business days, because we reproduce and regression-test rather than guess.

Ideally three things: (1) admin access to read checkout, shipping, payment and agreement config; (2) SSH or a deploy path to read var/log/exception.log and ship the fix; and (3) a staging environment (we’ll clone live if there isn’t one). If you can only give live admin access at first, we can still start by reproducing the bug as a shopper and reading the on-screen and console errors.

Yes — that’s one of the most common checkout bugs we see. A version bump or a new extension often introduces a throwing plugin, a deprecated KnockoutJS template, or a payment-renderer conflict. We diff what changed, reproduce the regression on staging, and fix the conflict. For upgrade-wide breakage beyond checkout, see our Magento upgrade bug fixing page; for gateway-specific failures, see payment gateway bug fixing.

Yes. Two safety nets: (1) every fix is reproduced and verified on staging with a real test order before it goes near production, and (2) every job carries a fix warranty — 7 days on a Quick Fix, 14 days on a Bug-Fix Sprint — so if the same bug comes back, we fix it again at no charge. For checkout emergencies that can’t wait, see urgent Magento bug fixing or the emergency e-commerce bug fixing hub.

Fixed prices, no hourly surprises: a Quick Fix is $99 (~4h @ $25/hr) for one well-defined bug — like a single stuck “Pending Payment” order or a 3DS redirect. A Bug-Fix Sprint is $499 (~20h @ $25/hr) for a batch of bugs or one gnarly root cause with reconciliation and regression tests. For live stores losing orders right now, the Emergency / Retainer tier adds a 24/7 on-call SLA, with a $2,499 stabilization sprint (~100h @ $25/hr) for deeper payment-stack rebuilds.

Almost always the gateway charged the card but its webhook / IPN / callback never reached Magento, so the order never advances to Processing. The notify URL might be blocked by a firewall or WAF, redirected by an HTTPS / trailing-slash rule, or rejected by Magento’s CSRF / form-key check. We confirm the charge in the gateway dashboard, fix the listener, then replay the missed events so the stuck orders settle to their real status. Seen most with Stripe, PayPal IPN, and Razorpay.

3DS breaks when the redirect handshake doesn’t complete. Common causes: the return URL doesn’t match what’s registered with the gateway, the bank’s 3DS page is blocked from loading in an iframe by an X-Frame-Options / CSP header, or the Stripe / Adyen payment intent has gone stale before the customer finishes the OTP. Customers see Authentication failed or land back on an empty cart. We fix the redirect / iframe flow and re-test SCA end to end with a live 3DS test card.

Yes — this is one of the most common payment bugs after a go-live or a server migration. If the live store still points at test keys you’ll see errors like No such payment_intent or This API key is a test key; if test environments hold live keys you can take real money in QA. We audit the per-website / per-store-view config, move secrets out of the database into env.php so each environment is correct, and verify a real transaction against the live endpoint.

Yes. Double charges come from a retried submit, a slow 3DS return, or a webhook firing twice — creating two orders or two captures for one checkout. We reconcile the gateway ledger against Magento’s sales_payment_transaction records, refund the duplicate, then add idempotency on the place-order and capture calls so it can’t recur. The reconciliation is included in the Bug-Fix Sprint tier.

A method (PayPal, Stripe, Authorize.Net) vanishes when it’s filtered out: disabled for that website scope, restricted by country or currency, blocked by a minimum-order rule, or hidden because a JavaScript error broke the Hyvä or Luma payment renderer. We trace which rule or error is removing it — checking config scope, the browser console, and the payment method’s isAvailable() logic — and bring it back at checkout.

It means Magento can’t reach the gateway’s API. cURL error 28: Operation timed out usually means a blocked outbound port or a slow firewall; cURL error 60: SSL certificate problem means an expired or missing CA bundle on the server; cURL error 6: Could not resolve host is a DNS issue. We confirm connectivity from the server, refresh the CA bundle, and re-open the outbound path so auth, capture, and refund calls succeed again.

Yes. Admin-side capture and refund failures usually trace to an expired API credential, a currency mismatch between the order and the gateway account, a transaction that was already settled / voided gateway-side, or a cURL connectivity error. We check the gateway transaction state, fix the credential or config, and confirm a clean capture and a partial refund both go through from the admin.

All the major ones: Stripe, PayPal / PayPal Express, Braintree, Adyen, Razorpay, Authorize.Net, Klarna, and Mollie, plus the official Magento payment integrations and most third-party gateway extensions. If you’re on a regional or custom gateway, send the module name in the booking form and we’ll confirm before any work starts.

We reproduce and develop the fix on staging wherever possible — payment code is too risky to edit blind on production. If there’s no staging, we’ll spin one up or work in a safe, isolated way using the gateway’s test mode. The final fix is deployed to live and verified with a small real transaction. We never edit core files — everything is done via plugins, observers, or config, so it survives upgrades.

Yes — this is the whole point of working through a payment specialist. We work via the gateway’s tokens and webhooks, never raw card numbers, so your PCI / SAQ-A scope stays intact. Changes go through staging, get regression-tested across auth / capture / refund / 3DS, and ship with a rollback plan. Your existing successful orders and customer data are never touched.

Emergency cases (a live store losing orders) get a first response within 4 hours and a same-day diagnosis on the Emergency tier. A typical single bug is reproduced, root-caused, and fixed within 24–48 hours. Every fix carries a 14-day warranty on the same bug — if the issue we fixed comes back in that window, we fix it again at no charge. Report it on this page, or if it’s a wider checkout problem see our Magento checkout bug fixing page or the emergency e-commerce bug fixing hub.

Afterpay ships an official Magento 2 module via the Magento Marketplace and via Composer (`afterpay/module-afterpay`). Setup is three steps: (1) create an Afterpay merchant account at portal.afterpay.com and grab your Merchant ID + secret key, (2) install the module + configure under Stores → Config → Sales → Payment Methods → Afterpay, (3) test in sandbox before flipping production. The module supports product page messaging (the “4 instalments of A$X” widget), cart messaging, and checkout. Afterpay was founded in Sydney in 2014 — it’s the de-facto BNPL rail for AU consumers, particularly fashion / DTC / lifestyle. We’ve integrated it on 30+ AU stores.

Since 1 July 2018, imports under A$1,000 are subject to GST when sold to AU consumers by overseas merchants — previously they were GST-free. If you’re an international seller selling into AU, you must register for GST under the OSR (overseas-supplier registration) scheme once your AU sales exceed A$75,000 in a 12-month period. In Magento, this is configured via Stores → Config → Sales → Tax: set up an AU-specific tax zone, apply 10% GST to all goods + services, and gate B2B orders by ABN to skip GST where appropriate. We’ll wire the tax-class mapping, ABN-based exemption flows, and OSR-compliant invoicing per ATO requirements.

ABN (Australian Business Number) validation is critical for B2B Magento stores so you can skip GST on tax-invoice flows where the buyer is a registered business. Two approaches: (1) Live lookup via the ABR (Australian Business Register) web service — we wire an extension or custom module that calls abr.business.gov.au/json/AbnDetails.aspx at registration / checkout, validates the ABN, and stores the verified entity name. (2) Offline checksum validation using the ABN modulo-89 algorithm for instant client-side validation before the live lookup. We typically combine both: instant feedback on the form, live verification before order placement. Combine with a customer attribute `is_abn_verified` and a customer-group rule to expose B2B catalogues / Net-30 terms only to verified ABNs.

Stripe AU — global rail, best for international DTC stores already on Stripe elsewhere. Lowest international card fees, native Apple Pay / Google Pay, deep developer ecosystem. Settlement to AU bank in 2 business days. eWAY — Australian-founded (now part of Global Payments), best for established AU retailers wanting AU-bank merchant services. Strong AMEX support, mature recurring-billing, AU-based phone support. Pin Payments — Australian-owned, Sydney-based, simplest pricing model (one flat rate, no monthly fees). Best for AU-only SMB stores. Recommendation: Stripe AU for DTC scale, eWAY for B2B + AMEX-heavy, Pin Payments for AU-only SMB. We’ve wired all three across 40+ AU Magento stores.

Yes — BPAY is the standard for B2B Magento stores in Australia, particularly for trading-account / Net-30 customers who prefer to pay via internet banking rather than card. There’s no off-the-shelf Magento BPAY module from BPAY itself, but two community modules + a custom approach work well: (1) generate a unique CRN (customer reference number) per order, (2) display the BPAY biller code (yours) + CRN on the invoice + order-confirmation email + customer order history, (3) reconcile incoming BPAY payments daily via your bank’s BPAY remittance file (CSV import to a custom Magento module). For high-volume merchants, integrate with NAB Transact or Westpac PayWay which both offer real-time BPAY APIs. Combine with ABN-gated customer groups so only verified B2B accounts see BPAY at checkout.

Australia Post ships an official Magento 2 module (free) that wires their MyPost Business API for ParcelPost (regular), Express Post (next-day metro), and StarTrack (B2B / large-parcel / regional). The module handles real-time rate quoting at checkout, label printing, manifesting, and tracking events. StarTrack is Australia Post’s premium B2B / regional service — same module covers it. For multi-warehouse stores (e.g. Sydney + Melbourne), we wire ShipperHQ on top so the cart picks the closest warehouse based on postcode + product availability + carrier-rate-shopping. We also build custom routing rules for rural / NT / TAS where Australia Post has different SLAs and StarTrack is often more cost-effective for parcels > 5kg.

Rural Australia, Northern Territory, and Tasmania need special handling because (a) Australia Post SLAs are 5–10 business days vs 1–3 for capital cities, (b) some couriers (Couriers Please) don’t deliver beyond metro areas, and (c) freight to remote NT / TAS often costs 3–5× metro rates. Our standard build: (1) postcode-based shipping zones in Magento with separate rate tables for metro / regional / remote, (2) carrier fallback chain (Australia Post Express → StarTrack → Sendle → Aramex) configured via ShipperHQ, (3) delivery-time messaging on PDP + cart so customers in remote NT see “5–10 business days” up-front, (4) optional freight surcharge for parcels > 5 kg to NT / remote TAS, (5) signature on delivery default for rural to reduce lost-parcel claims.

The Privacy Act 1988 + Australian Privacy Principles (APPs) apply to any business with annual turnover > A$3M (and to all health-data / credit-data businesses regardless of size). For Magento stores: (1) cookie consent banner (we wire CookieYes or CookieFirst with AU-specific text), (2) privacy policy covering APP 1 (open and transparent), APP 5 (notification), APP 6 (use / disclosure), APP 12 (access), APP 13 (correction), (3) opt-out flows for marketing / SMS (Spam Act 2003), (4) data-subject-access requests (DSAR) automation — we build an admin tool that exports a customer’s data on request within the 30-day APP-12 deadline, (5) Notifiable Data Breaches scheme — if you’re breached, you have 30 days to notify the OAIC + affected individuals. We configure logging + monitoring so a breach can actually be detected, not just notified after the fact.

Adobe Commerce Cloud (Sydney region) — managed Magento, Adobe handles patches / upgrades / Fastly CDN / New Relic. Best for stores doing > A$5M/yr that want zero infra burden. Costs A$1,500 – A$5,000+/month depending on tier. Lock-in to Adobe’s deploy flow (ECE-Tools). Self-host on AWS Sydney (or Cloudways Sydney / MyHost / BigCloud) — cheaper (A$200 – A$1,500/month), full control, can use any Magento version / extension. Best for stores doing < A$5M/yr or technical teams that want flexibility. Trade-off: you (or we) own patches / upgrades / CDN / monitoring. Recommendation: under A$3M/yr revenue — AWS Sydney + Cloudways for managed-VPS comfort. Over A$5M/yr — Adobe Commerce Cloud Sydney is worth the price for the SLA + Fastly + auto-scaling. We’ve migrated stores both directions.

Real overlap is 4–6 hours per day between IST (India Standard Time, UTC+5:30) and AEST (Australian Eastern Standard Time, UTC+10) — or AEDT (UTC+11) during daylight saving. Specifically: 1 PM – 7 PM IST = 5:30 PM – 11:30 PM AEST (your business afternoon / early evening, our late afternoon / evening). We schedule daily stand-ups, calls, screen-shares in this window. For early-morning Sydney calls (8–10 AM AEST = 3:30–5:30 AM IST), we offer that on launch nights or for critical incidents. Async tools we use: Loom for code walkthroughs, written end-of-day status notes (sent before our 7 PM IST = your 11:30 PM AEST), Notion project board kept current. WA / NT (UTC+8) overlap is 2 hours longer; SA / NT during AEST is similar to east-coast.