Adobe Commerce Partners

Three broad routes and what each commits you to

The first route is to build on the platform's own theming layer, where the storefront is rendered by Commerce itself. It is the fastest to deliver, the cheapest to staff because the skills are common, and every extension you buy will work with it without adaptation. Its ceiling is front-end performance and design flexibility: you are working within an established template structure, and pages carry more weight than a purpose-built front end would. The other cost is delayed. Heavily customised themes are precisely what makes platform upgrades painful, because each upgrade becomes a visual regression exercise across templates that have drifted from the supplied ones.

The second is a decoupled or headless storefront, where a separately built front end talks to Commerce over APIs. You get full control of the experience and the performance profile, and the front end can be replaced without touching commerce logic. In exchange you now maintain two applications, you lose the front-end half of most off-the-shelf extensions, and features that came free in the standard storefront, such as checkout edge cases and account management screens, have to be built.

The third is a supplied storefront framework such as Adobe's Edge Delivery-based commerce storefront, which aims to give the performance of a decoupled build without the whole of the maintenance burden, at the cost of working within its conventions. The right answer depends less on ambition than on who will maintain the thing. A team that cannot resource a front-end application separately should think hard before choosing the second route.

Questions that expose the real cost of the choice

• Who maintains the front end in year three — if the answer is an external team on an ad hoc basis, a decoupled storefront will decay.
• Which extensions are load-bearing — if your business depends on extensions with front-end components, a headless build means rebuilding those experiences.
• How often does the storefront change — frequent experimentation favors a front end your marketing team can iterate on without a full platform release.
• What does checkout need to do — complex delivery options, split payments, click and collect or B2B approval flows are substantially more work to rebuild than to configure.
• Can you upgrade without a redesign — the more the theming layer has been customised, the more every platform upgrade becomes a visual regression exercise.

Load testing with acceptance criteria, not reassurance

Every commerce build gets tested before launch, and most of those tests prove very little because nobody agreed in advance what passing meant. A useful load test is defined by numbers written down before it runs: concurrent sessions at peak, orders per minute sustained for a defined period, the mix of browsing to searching to checking out, and the response time thresholds each step must meet under that load. Without those, a test produces a report rather than a decision.

Model the peak from your own data, not from an average. Take your busiest historical hour, apply expected growth, and then test above it, because peak trading in retail is not a smooth curve. It is a spike triggered by an email send, a broadcast appearance or a sale opening at a set time, where a large share of the day's traffic arrives in a few minutes. Test the specific paths that break under that pattern: search on a large catalog, category pages with many filters, cart and checkout under contention for limited stock, and payment gateway behavior at rate limits. Third-party dependencies deserve particular attention, since their capacity is not yours to control.

Front-end performance budgets on commercial pages

• Set budgets per page type — category, product detail and checkout have different content and should have separate targets rather than one site-wide number.
• Measure from field data — real-user metrics at the seventy-fifth percentile reflect what customers on mobile networks experience, which is where most commerce traffic now sits.
• Control the tag layer — marketing tags, personalization scripts and chat widgets are the usual cause of a fast store becoming slow without a code change.
• Watch layout shift in the cart — late-loading promotions, stock messages and delivery estimates move buttons under the customer's finger at the worst possible moment.
• Include search response time — on large catalogs, a slow or poor-quality search silently suppresses conversion more than page speed does.
• Re-test after every peak campaign — the configuration that survived last year's peak is not the configuration you are running now.

Both ends of every integration need a named owner

A commerce platform is a hub. Product data arrives from a PIM, stock and pricing from an ERP, orders flow out to an order management or warehouse system, payments and fraud checking go to providers, tax and shipping rates come from services, and customer data moves to a CRM and a marketing platform. Every one of those connections has two ends, and the common failure is that the commerce build is contracted to deliver its end while nobody is formally responsible for the other.

Write an integration register before the build is scoped. For each connection, record the direction of data flow, the frequency, the volume at peak, the format, the system of record for each field, the expected latency, the behavior when the other side is unavailable, and the named owner on both sides. Whether calls are real time or batched is a commercial decision as much as a technical one: real-time stock checks prevent overselling but make your checkout dependent on ERP availability, while hourly synchronisation is more robust but will oversell during a fast-moving sale. Decide that per data type, with the consequences stated.

Migrating catalog and order data from messy sources

catalog migration is where commerce timelines usually slip, and the cause is nearly always data quality rather than tooling. Real catalogs contain products with missing attributes, inconsistent variant structures, three different size vocabularies, images referenced by filenames that no longer exist, category assignments that contradict each other, and duplicate product records created by different teams. None of that is visible in a sample export of fifty products, which is what most estimates are based on.

Profile the full catalog early: count products missing required attributes, count distinct values in fields that should be controlled, find duplicates, and check that every referenced image exists. Then decide explicitly whether cleansing happens in the source system, which is usually better because the problem stops recurring, or in the migration, which is faster but means you migrate the mess again next time. Order history is a separate decision with a real cost: migrating several years of orders so customers can see them in their account is meaningful work, and many retailers migrate a limited window and keep older history queryable elsewhere.

What the store costs after it is built

Price the operation, not the project. Across five years you will pay for licensing, hosting and its scaling behavior at peak, application and security patching, platform version upgrades, extension licences and their compatibility maintenance, integration maintenance as the systems at the other end change, front-end work as the store evolves, and support cover at the level your trading hours demand. For most mid-sized retailers this total is several multiples of the build price, and it is the number that determines whether the platform choice was right.

Two variables move it more than the others. The first is extension count: every third-party module is something that must be tested against each upgrade and that may become abandoned, and stores with forty extensions spend materially more on upgrades than stores with twelve. The second is how much the standard behavior of the platform has been customised, since customisation is what makes upgrades a project rather than a task. A build that resisted twenty small customisation requests is cheaper to own for years afterwards, which is worth remembering when those requests are being made.

B2B capability, where it applies

• Company accounts with structure — multiple buyers under one organization, with roles, spending limits and an internal approval chain before an order is placed.
• Negotiated pricing and shared catalogs — contract prices per customer and restricted product visibility, which is the requirement most likely to be underestimated.
• Quote to order — a buyer requests a quote, a sales person adjusts it, and the agreed quote converts directly into a purchasable order without rekeying.
• Purchase order and account payment — buying on account with credit limits rather than by card, which means an ERP integration for credit status rather than just a payment method.
• Requisition lists and fast reordering — repeat B2B buyers order the same things repeatedly, and making that quick is often worth more than any storefront refinement.
• Mixed B2B and consumer trading — if you serve both from one store, decide early whether that is one storefront with customer groups or two experiences, because it affects catalog, pricing and checkout design throughout.

Programs rarely stop at one product. Buyers hiring for Adobe Commerce often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.