Building an MCP server means deciding what parts of your business to expose to AI assistants, wiring those to your live systems, and choosing how an assistant reaches them safely. The work is approachable to start and easy to underestimate in production, which is the part most guides skip.

This article is part of our series on the Model Context Protocol. The first explained what MCP is, the second covered ChatGPT apps for eCommerce, and this one is about the layer underneath both: the server you build so assistants can actually access your catalog, inventory, and orders. 

You will not need to write code to follow this. There is one short example, so the shape of the work is concrete, and your engineering team can take it from there.

What an MCP server is, in one minute

An MCP server is a program that exposes your data and actions to AI assistants through the Model Context Protocol, the open standard that lets clients like Claude and ChatGPT connect to external systems. The server publishes a set of capabilities, the assistant calls them during a conversation, and your systems stay behind a single consistent interface. Building one means deciding what to expose, wiring it to your data, and choosing how the assistant reaches it.

The reason this is one standard rather than a dozen integrations matters for budgeting. Before MCP, connecting your store to each assistant meant a separate, bespoke integration for every one. MCP replaced that with a single interface that many assistants already know how to use. You build the server once, and Claude, ChatGPT, and other clients can all reach it. 

The standard is also no longer a single-vendor project. MCP was introduced by Anthropic in November 2024 and, in December 2025, was donated to the new Agentic AI Foundation under the Linux Foundation, with Anthropic, Block, and OpenAI as co-founders. By that point, it counted roughly 97 million monthly SDK downloads and around 10,000 active servers. That governance move is the de-risking signal that the interface you build against is an industry standard.

MCP server vs MCP client

An MCP server exposes capabilities, your tools, data, and prompts, while an MCP client is the application that consumes them, such as Claude Desktop, ChatGPT, Cursor, or an agent you write. The client connects to one or more servers and decides when to call them. When you build an MCP server, you are building the side that holds your systems, and the assistant is the client that talks to it.

This distinction keeps a project scoped correctly. You are not building the AI, and you are not building a chat interface. You are building the connector that lets an assistant someone else operates reach the things only your business can provide: your real products, your real stock levels, your real order status. That is a smaller and more controllable piece of work than teams often assume when they first hear “build an MCP server.”

The building blocks: tools, resources, and prompts

An MCP server exposes three kinds of capability. Tools are functions the assistant can call to take an action, such as searching a catalog or checking stock, usually with user approval. Resources are read-only data the assistant can pull in, like a product record or a document. Prompts are reusable templates that guide the assistant through a task. Most commerce servers lean on tools and resources.

For a store, the mapping is intuitive once you see it:

• Tools are the actions: search products, check availability, get order status, start a return.
• Resources are the reference data: a product detail record, a sizing guide, a returns policy.
• Prompts are the guided flows: a “help me find a gift” template that walks the assistant through the right questions.

It helps to picture one real exchange. A shopper tells an assistant they need running shoes for wide feet under a set budget. The assistant calls your product-search tool with those constraints, your server queries the live catalog and returns matching products with current prices and stock, and the assistant presents them in the conversation. If the shopper then asks where an existing order is, the assistant calls your order-status tool. Each of those is a capability you chose to expose, and nothing happens that you did not define.

Deciding which capabilities to expose, and which to hold back, is the first real design conversation. A good early scope is narrow: two or three high-value tools that map to questions customers actually ask, rather than an attempt to expose the whole platform on day one.

How to build an MCP server, step by step

Building an MCP server takes five stages: pick an SDK, define the server, register the tools and resources you want to expose, choose a transport, then connect a client and test. For a store, the useful version exposes real capabilities, product search, stock checks, order status, rather than a toy example. The official Python and TypeScript SDKs handle the protocol, so most of the work is wiring tools to your own systems.

1. Pick an SDK. Official SDKs exist for TypeScript, Python, C#, and Go, among others. Most teams choose the language their commerce systems already use, so the server can talk to existing code directly.
2. Define the server and register tools. This is where you name the capabilities. A product-search tool, a stock-check tool, an order-status tool.
3. Wire each tool to your real data. This is the bulk of the work and the part no tutorial can do for you: connecting each tool to your catalog, inventory, and order systems.
4. Choose the transport. Streamable HTTP for anything customer-facing, as covered above.
5. Connect a client and test. Point Claude or ChatGPT at the server and confirm each tool returns correct, current data.

A single product-search tool in Python with the FastMCP framework looks like this:

from fastmcp import FastMCP

mcp = FastMCP("store-catalog")

@mcp.tool()
def search_products(query: str) -> list[dict]:
    """Search the live catalog and return matching products."""
    return catalog.search(query)

That is the entire pattern. The framework turns the function and its description into a tool the assistant can call, and your team repeats the pattern for stock checks and order status. The hard, valuable work is behind catalog.search: making sure it returns accurate, current, well-structured data. When scandiweb built tools like the Claude Blog Factory, the protocol layer was quick, and the systems integration was where the real effort and care went. A store-specific server follows the same balance.

Choosing a transport: stdio vs Streamable HTTP

MCP servers talk to clients over JSON-RPC using one of two transports. Use stdio when the server runs on the same machine as the client, such as a local developer tool. Use Streamable HTTP when the server is remote and reached over the network, which is the case for anything customer-facing. The older HTTP and SSE transport is deprecated, so new servers should not start with it.

If the person using the AI client also controls the machine the server runs on, use stdio; for anything your customers or a hosted assistant reach, use Streamable HTTP. 

Almost any commerce use case is the second kind, because the server lives on your infrastructure and assistants reach it over the internet. There is one technical gotcha worth knowing so it does not surprise your team mid-build: a stdio server must never write logs to standard output, because that channel carries the protocol messages and stray output corrupts them.

Connecting your server to Claude and ChatGPT

The same MCP server works across assistants, so you build once and connect many. Claude Desktop reads a local config that points at your server command for stdio, or a URL for a remote server. ChatGPT consumes MCP through its Apps SDK and requires an HTTPS endpoint registered as a connector in developer mode. Building to the protocol, rather than to one assistant, is what makes the server reusable across Claude, ChatGPT, and others.

Taking your MCP server to production

A production MCP server needs more than a local script. Host it behind HTTPS on a platform such as Cloudflare Workers or Google Cloud Run, containerize it for repeatable deploys, and add rate limiting because AI clients can call tools in tight loops. Add logging and error handling per tool so a single failure does not break the conversation. The jump from a local demo to a hosted service is where most of the real work is.

This is the line item to plan for. A weekend prototype that answers questions in Claude Desktop is encouraging, and it is also perhaps a fifth of the way to something customers can touch. The remaining work is the standard discipline of any service that faces the public: reliable hosting, encryption in transit, sensible limits so an automated client cannot hammer your systems, and monitoring so you know when a tool starts failing. Budgeting for that gap up front is the difference between a demo that impresses leadership once and a service that earns its place in the customer experience.

On timeline, a narrow first server, a few read-only tools against a clean catalog, is a matter of weeks rather than months for a capable team. What stretches a timeline is usually messy product data that has to be cleaned before a tool can return it reliably, approval cycles for anything that touches orders or payments, and the security review a customer-facing endpoint deserves. 

Securing your MCP server

Any MCP server that touches customer data needs authentication. The MCP spec treats remote servers as OAuth resource servers and calls for OAuth 2.1 with PKCE and Resource Indicators, while local development can use API keys or environment variables. Validate every input, because the assistant will send unexpected calls, and watch your dependencies: a 2025 vulnerability in the popular mcp-remote package showed how a weak link exposes the whole chain.

Security is the section the generic tutorials skip, and it is the one a decision-maker should ask about first. An MCP server is a door into your live systems, opened to an assistant acting on a customer’s words. That door needs the same rigor as any other public endpoint: proper authentication on anything that reaches customer or order data, validation on every request, and current dependencies. The mcp-remote vulnerability, disclosed in 2025 and rated critical, affected a package with hundreds of thousands of downloads and is a useful reminder that the protocol being standardized does not make every tool around it safe. This is also where the PPC audit agent and other production builds taught us to treat the connector as carefully as the systems behind it.

Should you build your own MCP server or use a prebuilt one?

Build your own MCP server when your systems or logic are specific enough that no prebuilt server fits, which is common for custom stacks and bespoke workflows. Use a prebuilt server, such as Shopify’s official Storefront or Catalog MCP servers, when you are on a supported platform and need standard commerce capabilities. Use a managed MCP platform when you want hosting, auth, and monitoring handled and prefer to focus only on your tools.

It helps to know the prebuilt options are real and growing. Shopify, for example, ships official MCP servers: a Storefront server that exposes a single store’s catalog, cart, and policies, a Catalog server for cross-merchant product discovery, and a Customer Accounts server for order tracking and returns. If you are on a platform like that and need standard commerce capabilities, a prebuilt server can put you live quickly with far less to maintain. You build your own when your data or logic is specific enough that no prebuilt server fits.

Build your own if:

• Your data or actions are specific to your stack and no prebuilt server exposes them
• You need fine control over which tools and resources are exposed, and how
• You have engineering capacity to maintain it as the spec and your systems change
• You need custom authentication or compliance rules a generic server will not enforce.

Use a prebuilt server if:

• You are on a platform that ships official MCP servers, such as Shopify
• You need standard capabilities, catalog, cart, order status, rather than bespoke logic
• You want to be live quickly with less to maintain.

Use a managed MCP platform if:

• You want hosting, HTTPS, and authentication handled for you
• You prefer to write only the tools and leave the infrastructure to the platform
• You are testing demand before investing in your own deployment.

For many stores, the right answer is a mix of a prebuilt server for the standard parts and a custom one for what makes your business specific. If you are deciding what to build versus buy, our team can scope an MCP server against your stack using the same approach behind the MCP servers we run in production.

Frequently asked questions about building an MCP server

How do I build an MCP server?

To build an MCP server, pick an official SDK such as Python or TypeScript, define a server, register the tools and resources you want to expose, choose a transport (stdio for local, Streamable HTTP for remote), then connect a client like Claude or ChatGPT and test. Most of the work is wiring your own data and actions to the tools, since the SDK handles the protocol itself.

What is the difference between an MCP server and an MCP client?

An MCP server exposes capabilities, your tools, data, and prompts, while an MCP client is the application that uses them, such as Claude Desktop, ChatGPT, or Cursor. The client connects to the server and decides when to call its tools. When you build an MCP server, you build the side that holds your systems.

What are tools, resources, and prompts in MCP?

They are the three capabilities an MCP server can expose. Tools are functions the assistant calls to take an action, like searching products. Resources are read-only data the assistant can read, like a product record. Prompts are reusable templates that guide a task. A typical commerce server uses mostly tools and resources.

What language should I use to build an MCP server?

Use whichever official SDK fits your stack. The tier-one SDKs are TypeScript, Python, C#, and Go, with more languages supported at lower tiers. Python with FastMCP is the fastest path for many teams, and TypeScript is common when the server lives alongside a web codebase. The protocol is the same across all of them.

What is the difference between stdio and Streamable HTTP?

They are the two transports an MCP server uses. Stdio runs the server as a local process on the same machine as the client, which suits developer tools. Streamable HTTP exposes the server over the network for remote and customer-facing use. The older HTTP and SSE transport is deprecated, so new servers should use Streamable HTTP for remote access.

How do I connect an MCP server to ChatGPT?

ChatGPT consumes MCP servers through its Apps SDK. You host your server behind an HTTPS endpoint, then register that endpoint as a connector in ChatGPT developer mode. During development you can expose a local server over HTTPS with a tunneling tool. The same server also works with Claude and other MCP clients without changes.

How do I secure an MCP server?

Any MCP server that touches customer data needs authentication. The spec treats remote servers as OAuth resource servers and calls for OAuth 2.1 with PKCE, while local development can use API keys or environment variables. Validate every input the assistant sends, and keep dependencies patched, since a 2025 vulnerability in a popular MCP connector package showed how one weak link exposes the chain.

Do I need to build my own MCP server?

Not always. If you are on a platform that ships official MCP servers, such as Shopify, a prebuilt server may cover standard commerce needs. Build your own when your data or logic is specific enough that no prebuilt server fits, or when you need control over exactly which tools and resources are exposed and how they are secured.

If you are weighing whether to build your own MCP server or connect a prebuilt one, talk to our team and we will map it to your catalog, your assistants, and your security needs before your engineers write much code.

The post How to Build Your Own MCP Server appeared first on scandiweb.

If your team keeps forwarding you headlines about shopping inside ChatGPT and asking whether the brand needs to do something about it, this guide gives you the answer and the reasoning behind it. 

ChatGPT apps for eCommerce are third-party services that run inside ChatGPT, so a shopper can find products and act on them without leaving the conversation. They are built with OpenAI’s Apps SDK, launched in October 2025, and they are a different thing from the ChatGPT chatbot, from custom GPTs, and from the older plugins.

The reason this matters now, rather than next year, is timing. ChatGPT reached around 800 million weekly active users by late 2025, and OpenAI has spent the months since turning it into a place where people find and buy things, not only a place where they write. Most of the content ranking for this topic is either a product page from OpenAI or a vendor pitch telling you to build a custom app today. Our guide explains what a ChatGPT app is, how it works, what changed through 2026, and how to decide whether your store should build one, prepare for it, or wait.

We write this from a specific vantage point. scandiweb has put apps built on the same underlying standard into production, including a content agent and a PPC audit agent, so the guidance here comes from systems we build and maintain ourselves.

What a ChatGPT app is

ChatGPT apps are third-party services that run inside ChatGPT, so people can use them in a normal conversation instead of leaving for a separate site. In eCommerce, that means a shopper can browse your catalog, get a recommendation, and in some cases complete a purchase without opening a browser tab. Apps are built with OpenAI’s Apps SDK, launched in October 2025, and they differ from the ChatGPT chatbot, custom GPTs, and older plugins.

The distinction matters because the word “app” is doing a lot of work here. This is not your mobile app reskinned for ChatGPT, and it is not a marketing chatbot bolted onto your storefront. A ChatGPT app is a connected service that ChatGPT can call mid-conversation, render inside the chat with its own interface, and use to take real actions against your live systems. When a shopper asks ChatGPT to find a winter coat under a set budget, an app can return your actual products, in stock, with a way to act on them right there.

Three properties make a ChatGPT app different from anything merchants have plugged into before:

• It runs inside the conversation, so the shopper never context-switches to a new tab or site.
• It reads live data from your systems, so prices, stock, and variants are current rather than scraped or stale.
• It can take actions, from adding to a cart to starting an order, depending on how far you build it.

For a merchant, the practical model is straightforward. ChatGPT is the place the customer already is. The app is how your store shows up there with real data and real functionality, rather than as a static link the model might happen to mention.

ChatGPT apps vs GPTs, plugins, and Instant Checkout

A ChatGPT app is built on the Apps SDK and connects ChatGPT to your live systems through an MCP server, with an interactive interface inside the chat. A custom GPT is a configured version of ChatGPT with instructions and files, not a connected service. Plugins and connectors were the earlier integration model. Instant Checkout is a separate payment feature that lets shoppers buy from supported merchants in chat without a full app.

This is the single most common point of confusion, so it is worth a clear comparison. Merchants are being sold “ChatGPT apps” by some vendors and “custom GPTs” by others, and the two solve different problems at very different cost.

A custom GPT is a quick experiment a marketing team can stand up in an afternoon. It can hold your tone of voice and a few documents, but it does not see your live catalog or take orders. A ChatGPT app is a connected channel that does. Instant Checkout works alongside both as a payment path you can switch on through a supported platform, even before you commit to building an app of your own.

The reason this confusion is expensive: a vendor who pitches “a custom ChatGPT app” for the price of an app build, but delivers a custom GPT, has sold you a brochure when you needed a storefront. Knowing which of the four you actually need is the first real decision.

How ChatGPT apps work, the Apps SDK, and MCP

A ChatGPT app has three parts: tools that let ChatGPT take actions, structured data the model can read, and widgets that render an interface inside the chat. Underneath, the Apps SDK runs on the Model Context Protocol, the open standard that lets ChatGPT connect to external tools and data. For a store, that means your catalog, inventory, and order systems can be reached through one MCP server that the app talks to.

If that last part sounds familiar, it should. The Model Context Protocol is the same standard we covered in depth in our guide to MCP. The Apps SDK builds directly on it, which is why a ChatGPT app is, underneath, an MCP server with an app layer on top. MCP is the plumbing that lets an assistant reach external tools and data in a consistent way. The Apps SDK is what OpenAI layered on top so those connections can run, and render, inside ChatGPT. 

Walk it through in the order a request travels:

1. A shopper asks ChatGPT something your app can answer, such as a product search or an availability check.
2. ChatGPT calls one of your tools, the named actions you have exposed, like search_products or check_stock.
3. Your MCP server receives that call, queries your live commerce systems, and returns structured data the model can read.
4. A widget renders the result inside the chat, a product grid or a configuration panel, so the shopper can act without leaving.

The engineering reality comes down to one component you have to own and maintain: an MCP server that exposes your commerce systems in a way ChatGPT can use safely. The widgets and conversation flow are on top of that server. This is why the build question is really an infrastructure question, and why stores with clean, well-structured catalog and inventory data have a real head start. A store whose product data is scattered across spreadsheets and a tired PIM will spend most of the project getting that data fit to expose, before a single widget is drawn.

Why ChatGPT apps matter for eCommerce

ChatGPT reached around 800 million weekly active users by late 2025, which makes it a discovery surface, not only a writing tool. As shopping shifts toward agentic commerce, where an assistant helps choose and buy, brands that are reachable inside ChatGPT can be recommended at the moment of intent. For eCommerce, the value is presence in the conversation where a purchase decision is forming, rather than waiting for a separate site visit.

This is a meaningful change in where discovery happens. For two decades, the contest was for position in a list of blue links. In an assistant-led model, the contest is for being the answer the assistant reaches for when a customer describes what they want. That is the heart of agentic commerce – the assistant does more of the searching and comparing, and sometimes the buying, on the customer’s behalf.

There are two implications worth considering. A customer who completes a purchase inside ChatGPT may never touch your site, which changes how you think about owned traffic, analytics, and the first-party data you have relied on. And the brands that are structured to be reachable, with clean feeds and a working app, are the ones in the consideration set at all. The brands that are not structured for it simply will not appear, the same way a store with no SEO never showed up in organic search.

That second point is the one to take to leadership. This is less about a new marketing channel and more about whether your products are legible to the systems that are starting to mediate demand. A brand can have the better product and still lose the recommendation to a competitor whose data an assistant can actually read and act on.

Shopping and Instant Checkout inside ChatGPT

Customers can already buy inside ChatGPT in some cases. OpenAI’s Instant Checkout, announced in September 2025 and built with Stripe, lets US shoppers purchase from supported merchants in the chat, starting with Etsy sellers and expanding toward Shopify merchants. It runs on the Agentic Commerce Protocol, an open standard that handles how a merchant’s products, promotions, and orders move through the conversation.

Instant Checkout is the lower-effort entry point. You do not have to build a full app to be purchasable, provided your platform supports the integration. The difference is between being buyable inside ChatGPT and owning a richer, branded experience there. Many stores will start by being buyable through Instant Checkout while they weigh the decision about a full app.

How to get your products discovered in ChatGPT

Being buildable is not the same as being found. Before a ChatGPT app or Instant Checkout can sell anything, your products have to be legible to the assistant, which comes down to the quality and structure of your product data. This is the work that almost every store can start now, regardless of whether they ever build an app.

A few things carry most of the weight:

• Clean, structured product feeds. Titles, attributes, variants, availability, and pricing that are accurate and machine-readable. If you sell through Shopify, the Shopify Catalog route is one way merchant products reach ChatGPT users.
• Rich attributes. Material, fit, compatibility, use case. An assistant matching “a waterproof jacket for commuting” needs the attributes that let it match, not only a product title.
• Consistent identifiers. GTINs, SKUs, and category mappings that line up across your systems, so the same product is not described three different ways.

This is familiar territory for any team that has done serious product information management, and it is why a clean PIM and a disciplined feed strategy pay off twice. Once for traditional channels, and again for assistant-led discovery.

What changed in 2026, the shift to brand-owned apps

Through early 2026, OpenAI shifted its commerce focus away from checkout inside the chat and toward brand-owned ChatGPT apps, giving merchants more control over the buying experience. Around 100 companies had apps by then, Instacart integrated in December 2025, and Walmart launched a standalone app. The signal is that owning your own app, rather than relying only on in-chat checkout, is becoming the more durable path.

This is the part that most ranking content has not caught up with. The early story, in late 2025, was “buy directly in ChatGPT.” The 2026 story is more layered: OpenAI appears to be steering high-intent commerce toward apps the brand controls, where the merchant owns more of the experience, the data, and the customer relationship. The App Directory, which opened to third-party submissions in December 2025, is the front door for that model, and the early movers are large retailers who can see where this is heading.

If you are setting a strategy, treat the direction of travel as the planning input, rather than any single week’s announcement. The platform is moving toward brand-owned apps as the serious commerce surface, with feed-based discovery and Instant Checkout as the lighter-weight ways to participate in the meantime. A merchant who plans only around in-chat checkout is planning around the version OpenAI is already moving past.

How to build a ChatGPT app for your store

Building a ChatGPT app requires a paid OpenAI plan with developer mode enabled, then an app made of tools, structured output, widgets, and an MCP server. Apps are submitted through OpenAI’s developer platform for the App Directory, which opened in December 2025. At launch, apps were unavailable to logged-in users in the EEA, Switzerland, and the UK, which matters for European brands planning rollout.

In practice, a build moves through a handful of stages:

1. Connect your systems through an MCP server. This is the foundational piece and usually the largest share of the work. The server exposes your catalog, inventory, and order operations as tools ChatGPT can call.
2. Define the tools. Decide what ChatGPT is allowed to do, such as search the catalog, check availability, or start an order, and set the guardrails on each.
3. Build the widgets. The interface that renders inside the chat, the product grid, the configurator, the order summary.
4. Submit to the App Directory. Package the required metadata, testing, and country availability, then submit through the developer platform for review.

The work resembles other production agent builds more than it resembles front-end web work. When scandiweb built the Claude Blog Factory and a PPC audit agent, the hard and valuable parts were the same: connecting the model to real systems through MCP, defining safe actions, and maintaining the connection as the platform changed underneath. A store-specific ChatGPT app follows that shape, with your commerce stack in place of the marketing systems.

On cost, there is no single number, and any vendor quoting one without seeing your data is guessing. The real drivers are the state of your product data, the number and complexity of the actions you want to support, and whether you build in-house or with a partner. The ongoing cost is maintenance: an app that talks to your live systems needs care as both your stack and OpenAI’s platform evolve.

One caution for European merchants! Regional availability has lagged, and at launch, apps were not available to logged-in users in the European Economic Area, Switzerland, and the UK. If those are your primary markets, confirm current support before committing to a build timeline, and use the wait to get your product feeds in order so you are ready when availability widens.

Should your store build a ChatGPT app now?

For most stores, the honest answer in 2026 is to prepare, not rush. Building a full ChatGPT app makes sense when you have the engineering capacity and a clear in-chat use case. Preparing your product feeds and data makes sense for almost everyone because it is the low-cost way to be discoverable. Waiting is reasonable if you sell mainly in the EEA or UK, where availability still lags.

Build a ChatGPT app now if:

• You have in-house or partner engineering capacity to maintain an MCP server and app
• You have a clear, repeatable in-chat use case such as reorder, configure, or check availability
• Your buyers are US-based, where the commerce features are live
• You can commit to maintaining the app as OpenAI’s platform changes
• You want a defensible early position before competitors fill the directory.

Prepare your feeds and data instead if:

• You want ChatGPT discoverability without owning an app yet
• Your catalog and inventory data are not yet clean or well-structured
• You sell through Shopify and can use the Shopify Catalog route
• You want to test demand before committing to an engineering budget.

Wait if:

• Your primary market is the EEA, Switzerland, or the UK
• You have no engineering capacity and no development partner
• Your category sees little assistant-driven discovery today.

If you are weighing where your store falls, our team can run a readiness assessment using the same MCP stack we have already put into production, so the decision rests on your catalog, your markets, and your capacity rather than on a vendor’s timeline.

Frequently asked questions about ChatGPT apps for eCommerce

What are ChatGPT apps for eCommerce?

ChatGPT apps for eCommerce are third-party services that run inside ChatGPT, letting shoppers discover products, ask questions, and sometimes buy without leaving the conversation. They are built with OpenAI’s Apps SDK, which connects ChatGPT to a store’s catalog and systems through an MCP server. They differ from the ChatGPT chatbot, from custom GPTs, and from the separate Instant Checkout payment feature.

What apps are available in ChatGPT?

Early ChatGPT apps include Booking.com, Canva, Coursera, Expedia, Figma, Spotify, and Zillow, with Uber, DoorDash, Instacart, OpenTable, Target, and Tripadvisor following. After the App Directory opened in December 2025, third-party developers began submitting their own. The mix is growing quickly, and a notable share are shopping-oriented, including major retailers.

How do I use apps in ChatGPT?

In a supported ChatGPT plan, you can call an app by name in a conversation, or ChatGPT may suggest one when it fits your request. The app then runs inside the chat, showing an interface where you can browse, configure, or act without opening a separate site. Availability depends on your plan and your region.

Is the Apps SDK the same as MCP?

No, but they are closely linked. MCP, the Model Context Protocol, is the open standard that lets ChatGPT connect to external tools and data. The Apps SDK builds on MCP and adds the parts needed to run an app inside ChatGPT, such as interactive widgets. In practice, building a ChatGPT app means running an MCP server plus the app layer on top.

Can customers buy products directly in ChatGPT?

In some cases, yes. OpenAI’s Instant Checkout, announced in September 2025 and built with Stripe, lets US shoppers buy from supported merchants inside the chat, starting with Etsy sellers and expanding to Shopify merchants. Through 2026, OpenAI also shifted toward brand-owned apps, where the merchant has more control over the purchase experience.

How much does it cost to build a ChatGPT app?

There is no fixed price. Cost depends on the complexity of your use case, the state of your catalog and inventory data, and whether you build in-house or with a partner. The main ongoing investment is engineering time to build and maintain an MCP server connected to your commerce systems, plus a paid OpenAI plan with developer mode enabled.

Are ChatGPT apps available in the EU and UK?

At launch, ChatGPT apps were unavailable to logged-in users in the European Economic Area, Switzerland, and the UK, with availability rolling out over time. European brands should confirm current regional support before planning a launch, and may prioritize preparing product feeds while waiting for fuller availability.

Should an eCommerce brand build a ChatGPT app or use Instant Checkout?

For most brands in 2026, the practical path is to prepare product feeds and data first, then decide between a full app and Instant Checkout based on use case and market. Build an app when you have engineering capacity and a clear in-chat use case. Rely on Instant Checkout or feed-based discovery when you want presence without maintaining an app.

Where ChatGPT apps fit in your commerce roadmap

ChatGPT apps for eCommerce have moved from a developer demo to a discovery and buying surface that 800 million weekly users already touch. The sensible first move for most merchants is getting your catalog and data clean enough to be discoverable, then choosing between a brand-owned app and Instant Checkout based on your markets and your engineering capacity. The brands that prepare now will be in the consideration set when assistant-led shopping becomes routine. The brands that wait for full certainty will be wondering why a competitor got there first.

If you are trying to work out whether a ChatGPT app belongs on your roadmap this year or next, talk to our team and we will map it to your catalog, your markets, and the MCP stack we already run in production.

The post What Are ChatGPT Apps for eCommerce? A Merchant’s Guide appeared first on scandiweb.

“Sales volume was so high that our US team considered increasing shipping prices to slow orders down.”

Jean-Christophe Jouve
Global Finance Director at FELCO

For over 75 years, FELCO built a product so good that professionals worldwide wouldn’t use anything else. Swiss-made pruning tools, trusted by arborists and master gardeners who knew exactly what they were buying and why.

But by 2025, that professional loyalty, as valuable as it was, had become a ceiling. A much larger, underserved home gardening market was right there, and FELCO’s digital presence wasn’t speaking to it.

What followed was a six-month transformation in collaboration with scandiweb, bringing FELCO’s digital strategy from fragmented channel execution to a fully integrated DTC growth engine that delivered CHF 3.9M in revenue, +108% YoY growth, and the strongest Black Friday sale in FELCO’s digital history.

About FELCO

Founded in Switzerland, FELCO is globally recognized for manufacturing premium pruning and cutting tools used by professionals worldwide – the brand has long been synonymous with precision engineering and exceptional craftsmanship.

As DTC commerce became a growing strategic priority, FELCO identified an opportunity to expand beyond its professional base and reach the much larger home gardening segment, without compromising the premium positioning that defined the brand. At the same time, international expansion meant multiple markets and multiple digital channels, all running independently of each other.

Project goals

Main objectives at the start of our collaboration in July 2025 were to:

• Double DTC revenue YoY
• Achieve ROAS consistently above 4.0 across paid media
• Expand the customer base beyond professional buyers
• Build centralized performance visibility across markets
• Create a repeatable, scalable DTC operating model
• Execute the campaign following a tight timeline, with Black Friday only 4 months away.

Problem

Each channel – paid media, SEO, email, analytics, and CX – operated and reported independently. There was no unified picture of how a customer moved throughout touchpoints, where they dropped off, or what was actually driving revenue.

The issues showed up as:

• No cross-channel attribution or unified performance model
• Paid media profitability invisible by market, segment, and campaign type
• SEO disconnected from lifecycle strategy and conversion flows
• Limited email list segmentation and no meaningful automation
• GA4 and dataLayer inconsistencies
• Customer journey gaps at onboarding and post-purchase
• UX and messaging for professionals, creating friction for casual users.

Before and after: FELCO’s digital transformation

Solution

Rather than optimizing channels independently, scandiweb established a centralized growth operating model and launched a fully integrated marketing campaign. We took end-to-end responsibility for strategy, prioritization, and execution across paid media, SEO, AEO, email, analytics, CX, CRO, creative production, and development. Everything was oriented around the same funnel, audiences, and commercial targets.

Audience strategy and target personas

FELCO was beloved by professionals, but growth required repositioning the brand to resonate with the much larger, underserved home gardener audience. We treated this as a target audience expansion. Professionals remained a core audience, while we tried to make FELCO legible, appealing, and accessible to people who had never thought of themselves as the kind of person who uses professional pruning tools, and who would, once introduced correctly, become exactly that.

The two customer personas we built the strategy around:

• The Passionate Home Gardener – someone who values quality and durability, cares deeply about sustainability, and is genuinely invested in their garden; they can be overwhelmed by choice, so they need confidence and guidance.
• The Aspirational Hobbyist – drawn more by aesthetics and lifestyle than precision; they discover through social media and respond to seasonal projects, educational content, beautiful imagery, and the idea that the right tool is also the right statement.

Full-funnel paid media

We rebuilt the paid media architecture around intent and lifecycle stage:

• Upper-funnel creative introduced FELCO to home gardeners using emotional storytelling, like the satisfaction of a clean cut and pride of a well-kept garden
• Mid-funnel campaigns targeted active researchers with product-specific content
• Lower-funnel retargeting used dynamic creative adapted to browsing behavior.

Microsoft Ads, Pinterest, and TikTok were integrated as new channels into the acquisition strategy:

• TikTok for emotional resonance with younger home gardeners
• Pinterest for aspirational lifestyle content tied to seasonal moments
• Microsoft for capturing high-intent searches at lower cost. 

AI-powered creative workflow enabled over 300 ads deployed during BFCM.

SEO and AEO strategy

A full technical SEO and AEO audit addressed immediate gaps and longer-term search behavior, helping FELCO capture non-branded, high-intent searches from home gardeners and hobbyists:

• Technical SEO cleanup and crawl optimization
• Category tree expansion and navigation restructuring
• PLP and PDP content optimization
• Localized SEO for key European markets.

Alongside traditional SEO, we invested significant effort in answer engine optimization. A growing share of queries, particularly in product research and “how to choose” questions, is now answered directly by AI-powered engines, often without the user ever clicking through to a website. For a brand like FELCO, where purchase decisions frequently start with questions (what’s the best pruning tool for roses, do I need professional tools for home use, and similar), visibility in AI-generated answers is becoming as important as ranking on page one.

We restructured content so that it could be surfaced and cited by AI answer engines: rewriting key pages to lead with direct, concise answers to the questions FELCO’s target audiences were asking, building supporting educational content to establish topical authority, and ensuring that structured data and page architecture made it easy for AI systems to extract and attribute FELCO’s content accurately. 

Analytics and performance intelligence

The analytics infrastructure rebuild included GA4 implementation, dataLayer architecture, consent management, and reporting dashboards to support reliable, revenue-aligned decision-making.

For the first time, FELCO has:

• Cohort-level analysis by customer segment
• Cross-channel attribution across paid, SEO, and email
• Funnel drop-off diagnostics by step and audience
• Retention and repeat purchase tracking
• Campaign-level performance tied to contribution margin.

Lifecycle and retention marketing

We built a structured lifecycle engine and designed automated flows across the full customer journey: welcome and onboarding, product education, cart recovery, post-purchase engagement, cross-sell sequences, and seasonal gifting campaigns. Weekly newsletters were integrated into the broader marketing calendar, allowing CRM activity to reinforce paid media and seasonal pushes. 

Customer experience transformation

After the CX audit identified friction points specific to non-professional users, such as navigation and discovery that assumed product knowledge, and incomplete post-purchase experiences, we introduced, through UX redesign:

• Clearer product segmentation for professional vs. home gardener
• Simplified navigation and category structure
• Stronger tool selection guidance and product education
• Improved mobile usability
• Better integration of brand messaging throughout the journey.

Flagship campaign – BFCM 2025: professional-grade tools made accessible for every home gardener

Black Friday became the clearest expression of what this integrated model could do. We ran as a single coordinated experience throughout channels.

Paid media drove VIP early-access sign-ups ahead of the public launch, with intent-driven search and social campaigns leading on FELCO’s craftsmanship and seasonal offers.

Landing pages were rebuilt to lead with storytelling and simplify product selection for non-professional visitors – benefits first, technical specifications available but never required.

Email and SMS delivered early access to VIP members, then segmented flows throughout the sale window: educational content, offer reminders, abandoned cart, and checkout nudges, all coordinated with the paid calendar.

Retargeting showed dynamic product ads with messaging adapted to browsing behavior and funnel stage.

Post-purchase flows kept the conversation going after checkout with onboarding emails, usage tips, cross-sell recommendations, and a gifting push to satisfied BFCM buyers.

Results

2025 DTC performance

• +107.87% YoY revenue
• 4–5 ROAS consistently
• +208% traffic

What started as fragmented digital activity became a repeatable DTC growth system. This foundation helped us double DTC revenue year over year while expanding into new markets.

Jean-Christophe Jouve
Global Finance Director at FELCO

July–November (campaign window)

• +207% YoY DTC revenue, the strongest July–November period in FELCO’s digital history

November–December (peak season) YoY

• +167.2% revenue
• +154.4% transactions
• +5.0% AOV – given it was the most discount-driven week in the retail calendar, the campaign grew volume without requiring margin destruction to do it
• -76.7% add-to-cart drop-off

Black Friday week (24 Nov–1 Dec) YoY

• +292.1% revenue
• +828.6% PPC revenue
• +334.4% SEO revenue

The campaign delivered strong results. But the more interesting thing about this campaign is what it was actually doing. FELCO is a 75-year-old precision tool brand with deep credibility in a professional niche. We had to expand the definition of who FELCO is for without losing what made the brand worth expanding.

It required brand repositioning and performance marketing to align and meet a November deadline. The creatives had to work emotionally for a new audience while remaining honest about what FELCO is, and all the campaign activities had to scale a new segment without cannibalizing the professional base. The results are evidence that it worked. Alongside those numbers is the system that produced them: a fully integrated growth model that FELCO now owns.

Thinking about your DTC growth? If you are currently launching into a new segment or market, or trying to connect fragmented digital channels into something that performs – we’ve done it, and we can help. Get in touch with the scandiweb Integrated Growth team today.

The post Case Study: Doubling DTC Revenue for a 75-Year-Old Swiss Tool Brand in 6 Months appeared first on scandiweb.

We prepared an email marketing strategy for a prominent men’s grooming brand, used by professional barbers across 95 countries and trusted by customers who shop with them month after month. That kind of loyalty results from a product and brand identity that genuinely resonates. The email program was an opportunity to match that. 

In a mature DTC program, email drives 30–40% of total revenue. The key is to recognize that a first-time buyer, a returning customer, and a professional barber have very different relationships with the brand and need to hear from it differently. Here’s what’s possible when addressing customers with targeted messaging and personalization.

Emails for awareness, education, and conversion

Our mission was to develop an email program that is structured to use it at the right moment, for the right customer, in the right way. That starts with a simple framework of three email variants, each built for a different stage of the customer journey.

1. Editorial hero

This email should be portrait-driven with an offer in the first fold and minimal copy for moments where attention is the primary job. That could be a new launch or seasonal campaign. It earns the open and sets the narrative for what comes next, sent to the full list with a bias toward new and lapsed customers.

2. Product education

This type consists of a comparison structure that lays out the category decision before the CTA appears: welcome email follow-up, browse abandonment email, and cross-sell sends. It reads like a condensed blog post and converts like a product page, moving customers up a tier without leading with a discount. 

3. Offer close

This email variant is built for the 48-hour conversion window, focuses on a single product, has clear urgency, and uses a structure that does the selling that the first two variants warmed up for. It’s the right format for promo kickoffs and last-chance reminders. For this brand, that could be a reminder email timed to the 60–90 day reorder cycle, a seasonal promo close, or a win-back send that leads with what’s launched since the customer was last active. 

Email personalization based on customer types

The three email variants above only work if they’re reaching the right person at the right moment. That requires knowing who’s actually in the list. We identified three distinct customer types, each with a different relationship to the brand and a different reason to open an email. 

1. The New Customer who may already be pre-sold on product quality before their first order, or they may have zero brand context. What happens in the first few emails determines whether they become a loyal reorderer or a one-time buyer. Instead of a discount, they need to understand where the brand comes from, how the catalog is structured, and why the product they just bought is the right starting point.

2. The Returning Customer has the most revenue potential and requires the most nuance, even at the sub-segment level. Some customers in this segment reorder the same product every 60 to 90 days without much prompting, some bought one product and are curious about what pairs with it, while some haven’t ordered in six months and need a different kind of re-engagement. 

3. The Barber/Pro – they want technique content, early access to new formulas, and communication that acknowledges their expertise rather than talking to them like a first-time buyer. With 95 countries of barbershops connected with the brand, this segment is large enough to warrant its own flow.

New customer email flow

The welcome flow should be used for context setting. A new customer may have arrived via their barber, a social tutorial, or a gift, and what they need in the first few emails is enough brand context to understand what they’ve bought into and enough reason to come back.

The flow we developed:

• Day 0: Brand origin. Before any product recommendation, the new customer understands the brand origin and why that matters.
• Day 1: Product map. The catalog is introduced as four tiers, making SKUs feel navigable and not overwhelming.
• Day 3: Technique. Educational content that lets the brand’s credibility do the work.
• Day 6: Social proof. Showcasing scale that confirms a new customer made the right call.
• Day 10: First nudge. Free shipping over a threshold rather than a percentage off better fits the brand tone than a discount-first approach.

Returning customer email flow

The returning customer segment looks like one audience but behaves like several, and each one needs a meaningfully different email to move forward.

• Reorderer buys the same product every 60 to 90 days without much prompting – they need a “probably running low” email at day 50, with a one-click reorder link and no friction between the email and the checkout.
• Collector bought one product and is curious about what pairs with it. The right email is a popular pairing framed as education, less like a sale. The brand’s editorial blog already has this content, so the email just needs to surface it at the right moment.
• Lapsed customer hasn’t bought in six months or more. A generic “we miss you” email with 15% off gets ignored because every brand sends it. In this case, the right hook is what’s new since they were last active – lead with news, close with a frictionless reorder of their last product.

Barber/pro email flow

The pro segment is the most underserved by a generic email program. A professional barber uses the brand’s products on 20 or more clients a day, runs through product five to ten times faster than a consumer, sells it at the chair, and has zero interest in being spoken to like a first-time buyer.

The pro flow could look like:

• Day 0: A back-bar introduction. The professional product line, bulk SKUs, and framing that acknowledge this customer uses their product as a professional tool.
• Day 5: Technique content. On-chair application demos that make barbers better at their jobs and build loyalty.
• Day 14: Client matching. Explaining the products, making the barber a more confident advocate.
• Day 30: A reorder prompt. It’s calibrated to the professional cycle, which runs five to ten times faster than a consumer’s.

Every launch – early access before the general list goes live, giving a signal of status that costs nothing to deliver and builds the kind of loyalty that keeps a professional barber recommending the brand to every client they see. We also recommend zero discount-first language throughout, because this segment is community- not price-driven, and responds to content that treats them as the experts they are.

The full lifecycle email flow

The biggest revenue gains in email marketing come from lifecycle flows that continue working in the background every day, reacting to customer behavior regarding timing and products purchased. Here’s how a grooming brand could leverage those.

Welcome emails to build confidence

A new customer discovering the brand through Instagram, a referral, or a gifted product arrives with very different levels of product knowledge. The welcome sequence should focus on orientation first.

This is also where personalization begins. Well-structured welcome flows in DTC grooming brands commonly achieve 4–8% conversion rates when product education and personalized incentives are introduced early. 

Browse abandonment flow to recover high-intent traffic

One of the clearest lifecycle gaps appears when customers repeatedly view products but leave without adding them to the cart. This often signals hesitation rather than a lack of intent. Browse abandonment flows can continue the decision-making process by:

• Re-surfacing the viewed product
• Explaining how it differs from similar products
• Introducing popular pairings
• Reinforcing the quality through educational framing.

Behavior-triggered browse flows in grooming eCommerce regularly recover 1–3% of abandoned sessions without relying heavily on discounts.

Post-purchase emails to foster loyalty

Post-purchase flows are often underutilized despite being one of the highest-value stages in the customer lifecycle. The first order determines much of the future relationship and whether customers reorder. Well-developed post-purchase flows in DTC grooming typically generate between $1.50 and $2.50 revenue per recipient over a 60-day period.

We recommend extending beyond transactional confirmation emails into technique content shortly after delivery, routine pairings several weeks later, and reminders aligned with expected usage cycles. For products with predictable reorder windows, reminder sequences become especially valuable.

Win-back emails to reconnect through relevance

This brand’s customers often lapse because they purchased through a barber instead, they switched routines temporarily, or they simply haven’t been reminded of what’s changed since their last purchase. Instead of positioning reactivation around price, the flow reframes it around discovery and product evolution. That shift preserves brand positioning while still creating urgency to return.

The stronger approach is contextual reactivation:

• New product launches
• New formulations
• Updated routines
• Products connected to previous purchases.

Building a lifecycle email program

This approach starts with the data of who’s in the list, how they buy, and where the program currently isn’t reaching them. From there, we build email variants and lifecycle sequences based on customer behavior. Projected results:

• A mature email program like this drives 30–40% of total DTC revenue
• Personalized welcome flow has a 4–8% CVR, which is up to 4x higher than what a generic version produces
• Post-purchase sequences deliver $1.50–2.50 revenue per recipient over 60 days 
• Win-back flows reactivate 3–6% of lapsed customers within 90 days. 

Putting all of that together for a list spanning 95 countries and including a pro segment ordering at 3–5x the consumer rate, those benchmarks compound meaningfully.

If your email program isn’t tailored to your customer base, the gap is likely larger than it appears. We build the full program around your brand and customer data – let’s get in touch, and we’ll show you what that looks like in practice.

The post Email Marketing Accelerator: How a Lifecycle Email Program Drives Up to 40% DTC Revenue in 90 Days appeared first on scandiweb.

Every AI vendor, every data platform, every dev tool, and every commerce platform in 2026 ends the pitch with “we support MCP.” If you are the person on the other side of those pitches, and you still don’t have an internal frame for what MCP actually changes about your stack, this guide builds the frame. It covers what MCP is, how it differs from an API, and what it unlocks across developer tools, customer support, internal data, and commerce.

scandiweb already ships MCP-based AI agents in production, including the Claude Blog Factory and an automated PPC audit agent, so the view here is grounded in what we run.

What is MCP? A working definition

MCP, short for Model Context Protocol, is the open standard that lets AI agents read live data and run commands across external tools in a way every major model understands. Anthropic introduced it in November 2024, and it is now governed by the Linux Foundation’s Agentic AI Foundation. MCP is what allows agents in ChatGPT, Claude, Copilot, Cursor, and Gemini to reach codebases, support systems, data warehouses, and commerce stacks through one common interface.

MCP does three things at runtime. It lets an agent discover the tools and data a system exposes. It lets the agent read live data in a typed shape any compliant model can interpret. And it lets the agent take action, while the server enforces what is allowed.

You will hear MCP described as USB-C for AI. The cleaner framing: when an agent inside Cursor needs to find every callsite of a deprecated function, it does not query your repo directly. It talks to a Git MCP server. Any other compliant agent could have asked the same way. Underneath, MCP rides on JSON-RPC 2.0.

What does MCP stand for, and who is behind it

MCP stands for Model Context Protocol. Anthropic introduced it in November 2024. OpenAI adopted it in March 2025. In December 2025, Anthropic donated the protocol to the Linux Foundation’s Agentic AI Foundation, a directed fund co-founded with Block and OpenAI. Today, Anthropic, OpenAI, Google DeepMind, and Microsoft all natively support MCP, with over 500 public MCP servers available by early 2026.

The governance handoff matters. MCP is no longer an Anthropic project that other vendors agreed to play along with. It is a neutral standard with shared ownership, the same posture HTTP and TCP had once they became infrastructure.

Architecturally, MCP solves the M×N integration problem. Before MCP, connecting every model to every tool meant a custom connector per pair. With MCP, every model implements the protocol once and every tool implements it once. M×N work becomes M+N. That is why the standard caught so quickly.

How MCP works: hosts, clients, servers, and three primitives

APIs are built for developers to call from code. MCP is built for AI agents to call at runtime. An MCP server exposes typed tools, read-only resources, and reusable prompt templates that an agent discovers on its own. The agent never sees API keys or raw endpoints, only the safe tools the server allows.

MCP architecture has three roles:

• Host. The AI app the user interacts with, like Claude Desktop, ChatGPT, Cursor, or Windsurf. The host runs the LLM and decides when to call out.
• Client. A process inside the host that maintains a one-to-one connection to a specific MCP server.
• Server. A service you control that wraps part of a system and exposes capabilities to agents.

An MCP server offers three primitives:

1. Tools. Executable functions, like search_repo, create_ticket, query_warehouse, or search_products. The agent decides when to call them.
2. Resources. Read-only data the agent consumes for context, like a customer history record or a pricing rule.
3. Prompts. Reusable templates for how the agent should interact with a system, like the wording it uses to confirm an action with side effects.

The same shape works across industries. A GitHub server exposes search_repo. A Zendesk server exposes read_ticket and draft_reply. A Shopify Storefront server exposes search_products and cart_lines. What changes per system is which capabilities are safe to expose.

Read more: Claude Blog Factory using MCP — a production MCP host, client, and server flow with real names on the boxes.

What is an MCP server, exactly?

An MCP server is a small service you control that wraps part of a system and exposes specific tools to AI agents in a standard way. A GitHub server lets an agent search a repo and edit files. A Zendesk server lets an agent read tickets and draft replies. A Snowflake server lets an agent run scoped warehouse queries. A Shopify Storefront server lets an agent search products and build carts. The server validates each call and decides what the agent can and cannot do.

You will deal with two flavors: public MCP servers shipped by vendors or the community (hundreds exist by 2026 for the major SaaS systems), and custom servers you build for systems your vendor does not cover. The right starting point is checking what is already published for your stack before building.

MCP vs API: what is actually different

An API is a contract between developers and a system. MCP is a contract between an AI agent and a system. The difference is who is calling, why, and what they can see.

MCP does not replace APIs. It sits on top of them. An MCP server you build almost always calls your existing REST or GraphQL API internally, then translates the result into an agent-friendly shape. scandiweb’s PPC audit agent, for instance, calls the Google Ads API through an MCP server, which keeps the API key off the model.

So “MCP vs API” is the wrong question. The real one is which of our APIs should be wrapped in MCP servers, and which capabilities those servers should expose to which agents.

Why MCP matters now: the agentic AI shift

MCP matters because every major AI app in 2026 supports it. ChatGPT, Claude, Copilot, Cursor, and Gemini all read MCP servers natively. The standard is governed by the Linux Foundation. Over 500 public servers existed by early 2026. For any team planning AI agents, MCP is now the integration layer your stack will be measured against.

This is the shift specialists call agentic AI. A year ago the framing was “AI-powered features”, an LLM in a sidebar. Today the framing is “agents that act”: a model that reads your data, decides what to do, and runs commands across your tools without an engineer in the loop. That is what MCP enables.

The implication is clear. If your systems are not reachable by an agent through MCP by the time users expect ChatGPT, Claude, or Copilot to do work on those systems, you are not behind on AI. You are missing from the workflow.

Read more: Agentic commerce explained — the customer-facing version of the same shift.

MCP use cases across industries

MCP unlocks seven core use cases for AI agents: (1) developer tooling, search and edit code through GitHub or Cursor servers; (2) customer support, triage and draft replies through Zendesk or Intercom; (3) internal data access, query Snowflake, Notion, or Confluence; (4) eCommerce, read catalog, build carts, and check inventory through Shopify or Adobe Commerce; (5) content and marketing operations, draft and audit content; (6) sales and CRM, enrich accounts and prep meetings; (7) security and IT ops, triage alerts and run runbooks.

The boundary line matters as much as the list. Irreversible writes, PII writes outside policy, payments above a merchant-set threshold, and anything that crosses your security policy or EU AI compliance obligations belong behind human-controlled review, not an agent tool. The MCP server enforces that by not exposing the dangerous capability. Do not rely on the agent to behave. Rely on the server to refuse.

MCP across industries: developer tools, customer support, internal data, and commerce

The honest picture as of mid-2026, with four sub-sections at equal weight.

MCP in developer tooling

Developer tools were the first place MCP went mainstream. Cursor, Claude Desktop, Windsurf, and Zed shipped support in 2025; GitHub Copilot added it in 2026. Public servers exist for GitHub, GitLab, Linear, Sentry, and PagerDuty. A real flow: a developer asks Claude inside Cursor to find every callsite of a deprecated function and propose a refactor. The agent reaches the codebase via a Git server, reads related issues via a Linear server, and proposes the change as a draft pull request. scandiweb’s Blog Factory is a production MCP-based agent that runs content-engineering workflows the same way.

MCP in customer support

Customer support is where MCP most directly affects unit economics. Zendesk, Intercom, and Salesforce Service Cloud are integrating MCP-compatible interfaces in 2025–2026 for AI-drafted ticket replies and handoffs. A real flow: a customer asks about an order on a support chat. The agent calls a Zendesk server to read the ticket and customer history, then a billing server for order status, and drafts a reply the human reviews. The server lets the agent read tickets, draft replies, and tag issues, but not close or refund them without a human. The point is compressing the read-and-draft cycle, not replacing the team.

MCP in internal IT and enterprise data

Internal data is where the enterprise case lives. Public servers exist for Slack, Notion, Linear, GitHub, Snowflake, Databricks, Confluence, and Google Drive, with more landing every quarter. A real flow: an analyst asks Claude to “summarize last quarter’s churn drivers across Snowflake, Notion, and call transcripts.” The agent calls a Snowflake server for the numbers, a Notion server for the strategy doc, and a transcript server for the call data, then synthesizes. The honest gaps in 2026 are auth, audit trails, and multi-tenant scoping. Teams getting value today treat the MCP server as the policy boundary, not the agent’s promise to behave.

MCP in eCommerce and retail

eCommerce moved fast because the platforms did. Adobe Commerce made MCP the default agent protocol in 2026, with built-in catalog, cart, pricing, and inventory exposure. Shopify shipped four MCP servers by the Winter ’26 Edition (Dev, Storefront, Customer Account, Checkout) and co-developed the Universal Commerce Protocol with Google at NRF January 2026. On March 24, 2026, Shopify Agentic Storefronts went live by default for US merchants, making 5.6 million stores discoverable inside ChatGPT, Copilot, Google AI Mode, and Gemini. A real flow: a shopper in ChatGPT asks for “black running shoes under $120 in size 11 that ship by Friday.” The agent calls a Shopify Storefront MCP to query the catalog, filter by inventory, check shipping, and build a cart. For teams considering a custom build, see our Shopify eCommerce development services.

Read more: Top AI agencies — the agency landscape behind MCP-ready stacks, for teams deciding who builds.

When MCP fits your roadmap, and when it does not

For most teams the question is not whether to adopt MCP, but when. The honest test has three parts: a real agent use case waiting on it, systems that can support it cleanly, and a team that can carry both the build and the security work. If none of those is true yet, track MCP but do not build toward it this quarter. Build too early and you rebuild when primitives evolve. Wait too long and you show up in 2027 to agent traffic your stack cannot serve.

Use MCP now if:

• You have an AI agent use case committed for FY26 (developer copilot, support agent, internal data agent, customer-facing storefront agent, or ops automation).
• The systems you would expose ship MCP servers today or have clean APIs ready to wrap.
• You operate three or more disparate systems an agent would need to coordinate across.
• You want your stack reachable from ChatGPT, Claude, Copilot, Cursor, or Gemini without a per-vendor custom integration.

Wait on MCP if:

• No AI agent use case is committed past proof-of-concept.
• The systems you would expose lack stable APIs, and an MCP wrapper would inherit that instability.
• The MCP primitives your use case relies on (elicitation, resource links, structured outputs) are still in active spec evolution.
• The team carrying the build cannot also carry the security work that MCP servers require.

Frequently asked questions about MCP

What does MCP stand for in AI?

MCP stands for Model Context Protocol. It is an open standard introduced by Anthropic in November 2024 and governed by the Linux Foundation’s Agentic AI Foundation since December 2025. It gives AI models a single way to connect to external tools, data, and systems, so a model can read live data and take actions without each integration being custom-built.

What is MCP in plain language?

MCP is the protocol that lets an AI agent ask a tool a question and run a command on it, in a way every major model and every compliant tool understands. Think of it as USB-C for AI. With MCP, any compliant agent can call any compliant tool, including codebases, support systems, data warehouses, and commerce stacks.

How is MCP different from a regular API?

An API is built for developers to call from code. MCP is built for AI agents to call at runtime, on their own. MCP servers expose typed tools an agent can discover and invoke without prior hardcoding, and keep API keys and unsafe calls hidden behind the server. APIs do not give an agent that safety layer.

What are MCP servers used for?

MCP servers expose specific capabilities of a system to an AI agent in a standard way. The common categories are developer tools (code search, file edits), customer support (ticket read, draft reply), internal data (warehouse queries, document retrieval), and commerce (catalog, cart, pricing, inventory). The server stays in your control.

Is MCP an Anthropic product?

No. Anthropic created and open-sourced MCP in November 2024 and donated it to the Linux Foundation’s Agentic AI Foundation in December 2025, a directed fund co-founded with Block and OpenAI. Anthropic, OpenAI, Google DeepMind, and Microsoft all support MCP natively. It is a multi-vendor standard.

How does MCP work, step by step?

An AI host (Claude Desktop, Cursor, ChatGPT) opens a client connection to an MCP server. The server lists the tools, resources, and prompts it offers. The agent picks a tool, sends a typed request over JSON-RPC 2.0, and the server runs the action and returns the result. The agent never sees secrets or anything the server has not exposed.

Do I need to build my own MCP server?

Often no. Hundreds of public servers exist by 2026 for GitHub, Slack, Snowflake, Notion, Linear, Zendesk, Shopify, and many other systems. You typically build custom servers only for proprietary systems, like an internal PIM or a domain-specific workflow. Check what is already published before building.

Is MCP secure?

MCP is as secure as the server you put behind it. The protocol keeps secrets on the server side, so the model never sees API keys. The real security work sits in the server: scoping each tool, validating inputs, rate-limiting, and authenticating the agent. Treat it like any public API, with one extra rule: assume the caller is an LLM and constrain accordingly.

The bottom line on MCP

MCP is no longer a forecast. It is the protocol your AI agents will be measured against in 2026. The hosts have shipped, the major vendors have shipped servers, and the systems your team uses every day, from GitHub to Zendesk to Snowflake to Shopify, are already reachable through MCP. What separates the teams that get value from the teams that ship orphan demos is how tightly they scope what their agents are allowed to do.

The starting move is rarely “build everything at once”. Pick the agent use case with a real business reason behind it, wrap the systems it needs, scope the tools tightly, ship, and iterate.

If you want to build with MCP and the question is where to start, talk to our team and we will scope it with you.

The post What Is MCP? The Definitive Guide to the Model Context Protocol appeared first on scandiweb.

If you’re weighing Shopify against Shopify Plus, you’re probably in one of three rooms: a Basic or Advanced store outgrowing rate limits, B2B requests, or expansion-store sprawl; a finance review where third-party gateway fees suddenly dwarf the subscription; or a planning meeting where someone said “headless” and the dev team quoted Plus.

All three end on the same spreadsheet, with the same question: when does the upgrade actually pay back?

Short answer — Plus pays back the day your third-party gateway fees plus your subscription cross roughly $2,300 a month, which usually happens between $500K and $700K monthly revenue, well before the often-quoted $1M GMV threshold.

The rest of this guide covers the features, pricing, and migration realities that shift that number for B2B, multi-region, and headless builds — drawn from 20+ Shopify migrations scandiweb has shipped since 2014 (The New York Times, Durex, Hope-sthlm, Kouboo, and Edasi).

Why trust this guide

• Shopify Plus Partner since 2014; Adobe Commerce Gold and Hyvä Platinum Partner
• 2,100+ eCommerce projects, $4B+ in annual client GMV, 700+ brands across 40+ industries
• ISO 9001, ISO 27001, ISO 27017, and PCI DSS certified
• Shopify clients include The New York Times, Durex, Hope-sthlm, Kouboo, and Edasi

What is Shopify Plus, and how is it different from standard Shopify?

Shopify Plus is the enterprise tier of Shopify. It runs on the same platform as Basic, Shopify, and Advanced – but removes the limits and adds an enterprise support and B2B layer. The standard plans fit stores up to roughly $1M–$2M annual revenue; Plus is designed for everything above that, plus any store that needs native B2B, multi-region operations, a customized checkout, or a headless storefront.

Standard plan pricing: Basic $39/mo, Shopify $105/mo, Advanced $399/mo. Plus is $2,300/mo or 0.4% of monthly revenue (whichever is higher), capped around $40,000/mo at very high volume.

The full-feature delta is in the table below; the key one is that Plus removes Shopify’s 0.5% transaction fee on third-party payment gateways – the line that drives most of the upgrade math (see Shopify’s published rate limits for the API ceiling).

Shopify vs Shopify Plus: side-by-side comparison

Pricing reflects Shopify’s published rates as of May 2026; verify against shopify.com before signing.

Where the gap actually matters: a deeper look at Shopify Plus features

Checkout and Checkout Extensibility

The largest functional gap between Shopify and Shopify Plus is checkout. Standard plans get Checkout Extensibility with restrictions on extension count, custom JS, and branding. Plus opens the full surface: apps and UI extensions on every checkout step, Shopify Functions for custom discount and shipping logic, and a Branding API for pixel-level visual control.

For high-AOV brands, checkout A/B testers, and B2B sellers with negotiated pricing, this single capability often justifies the upgrade. (Note: Shopify’s older Scripts layer is deprecated in favor of Functions, so any Scripts-dependent merchant should plan a Functions migration alongside the Plus move.)

B2B and the Wholesale Channel

Advanced ships limited B2B; Plus ships the full stack: company accounts, customer-specific catalogs and price lists, net payment terms, draft orders, quick-order forms, and a dedicated Wholesale Channel for running a separate B2B storefront from the same admin.

For merchants moving off Magento B2B, BigCommerce B2B Edition, or legacy ERPs, this is the feature that forces the decision. If B2B is more than 10–15% of revenue, you’ll need Plus. We cover the broader picture in our B2B eCommerce overview.

Shopify Functions, Flow, and the Scripts replacement

Shopify Functions (server-side WebAssembly modules for discounts, shipping, payments, and cart validation) are on every plan, but Plus gets higher execution limits and priority handling. Shopify Flow, the no-code automation engine, is also on every plan; Plus adds advanced templates and unlimited workflow runs that matter at scale – fraud auto-cancellation, B2B approval routing, post-purchase tagging for retention.

Multi-store and Organization Admin

If you sell into multiple regions or run multiple brands, the Organization Admin is the biggest operational reason to upgrade. From one dashboard you manage up to nine expansion stores plus dev stores, with unified permissions and consolidated analytics. Standard Shopify gives you exactly one store per plan. A typical international DTC config looks like five stores under one contract: US, EU, UK, APAC, plus a B2B Wholesale store.

APIs, rate limits, and headless commerce

The API ceiling is where standard Shopify breaks for technical teams. Plus has roughly 20× the call rate on REST and GraphQL, which is what makes a serious build on Hydrogen, React, or Next.js viable. If your roadmap includes a PWA, a native mobile app pulling live catalog data, or any real-time personalization layer, you’ll hit the standard rate limits within weeks of go-live. It is the single constraint we run into first on non-Plus stores; we cover it in our headless commerce practice.

POS Pro, staff accounts, and permissions

Plus includes Shopify POS Pro at up to 200 locations – the right answer for retail chains, pop-up networks, and omnichannel brands. Standard plans charge POS Pro per location as an add-on. Staff accounts go from 15 on Advanced to unlimited on Plus, with granular role-based permissions. See our omnichannel retail case studies for the patterns that work.

Apps, themes, and customization limits

The App Store and Theme Store are the same across all plans, but Plus merchants get earlier feature access, fewer Liquid restrictions, and higher limits on custom apps and metafields. See our best Shopify integrations and Shopify themes guide for the picks we install most.

Security, compliance, and uptime SLA

Plus is the only Shopify tier with a published 99.99% uptime SLA, and the only tier suitable for enterprise compliance reviews. PCI DSS Level 1 is baked into Shopify itself, but if procurement wants SOC 2 reports, ISO 27001 attestation chains, or audit logs, Plus is the practical floor.

How much is Shopify Plus in 2026?

Shopify Plus costs $2,300/mo or 0.4% of monthly revenue (whichever is higher), capped around $40,000/mo at very high volume. The variable component kicks in past ~$800K monthly revenue. In practice, almost every Plus merchant signs a one- or three-year contract and negotiates discounts at higher GMV commitments.

For comparison, standard Shopify plan pricing:

“Shopify enterprise pricing” is the same thing as Shopify Plus pricing – Plus is the enterprise tier. There is no separate enterprise SKU above Plus.

Hidden costs of Shopify Plus

The sticker price is only part of TCO. A realistic Plus budget includes:

• Apps and subscriptions: $500–$5,000+/mo (subs, reviews, search, loyalty, ERP connectors)
• Shopify Payments: 2.4–2.9% + 30¢/txn – Plus removes the 0.5% third-party gateway cut but processing fees still apply
• Theme dev or headless build: one-time $30K–$200K+
• Migration from Magento, BigCommerce, or legacy: $40K–$250K+ depending on data volume, integrations, and B2B complexity
• Ongoing dev and maintenance: 0.5–2 FTEs internal, or a Plus Partner retainer

For a breakdown against your stack, talk to scandiweb.

Shopify Plus vs Shopify Advanced: when does the math flip?

The fastest payback test is transaction fees alone. On Advanced you pay $399/mo plus 0.5% on third-party gateway transactions; process $500K/mo through a third-party gateway and you’re at ~$2,900 all in. On Plus the 0.5% disappears – Plus is $2,300/mo flat at that volume. In practice the flip happens earlier because Plus also reduces some app costs and cuts operational workarounds.

When to upgrade from Shopify to Shopify Plus

Upgrade when the math pays back, or when a feature you need is only available on Plus.

Revenue thresholds

The industry rule of thumb is to consider Plus past $1M annual GMV and commit by $2M – which holds for single-region DTC on Shopify Payments. The threshold moves earlier for B2B-heavy merchants and multi-region rollouts (Plus removes third-party gateway fees and adds the B2B/Organization Admin stack at the same time) and later for single-region Shopify Payments merchants, who often don’t hit payback until $3M–$5M annual GMV. Revenue is a lagging signal: if a B2B, headless, or multi-region launch is six months out, upgrade now – migration sits on its critical path.

Operational signals that override the revenue threshold

Upgrade when any of these are true, regardless of revenue:

• You need B2B with company accounts, net terms, and price lists
• You’re launching in a second country and need a separate store with its own currency, language, and tax setup
• You need to customize checkout beyond what apps allow
• You’re going headless on Hydrogen or a custom front-end and need API headroom
• You operate more than 10 retail locations and need POS Pro at scale
• Procurement, legal, or compliance demands a published uptime SLA and enterprise contracts
• You’re hitting API rate limits or staff seat caps weekly

If two or more apply, it’s no longer whether to upgrade – only when.

How to upgrade to Shopify Plus, step by step

1. Contact Shopify or a Shopify Plus Partner. Sales conversation, needs assessment, contract negotiation – allow two to four weeks. A Plus Partner can usually shorten the cycle and negotiate better terms.
2. Plan the technical move. Existing Shopify stores upgrade in-place. From Magento, BigCommerce, WooCommerce, or custom: data migration, theme rebuild, and integrations are the real project – allow one to four months.
3. Configure Plus capabilities. Wholesale Channel, expansion stores, Organization Admin permissions, Flow workflows, custom checkout extensions, B2B catalogs. Get Organization Admin right the first time – it’s hard to refactor later.

Pair the move with a Shopify SEO checklist review and a performance optimization pass; those two account for most avoidable revenue loss during platform changes.

Is Shopify Plus worth it?

Below $1M GMV, single market, no B2B, no headless plans: not yet – standard Shopify gets you 90% of the way for a tenth of the cost. Above $1M GMV, or any merchant who needs B2B, multi-store, headless, or customized checkout: yes, and the payback usually lands inside 6–12 months. The case studies below show what the lift looks like in practice; see also our conversion rate optimization practice for the architecture work that compounds the Plus upgrade.

Shopify Plus case studies from our portfolio

A few of the migrations behind the numbers in this article.

The New York Times Store – Adobe Commerce to Shopify Plus in 60 days

A 170-year-old brand with 50,000+ catalog items replatformed off Adobe Commerce onto Shopify Plus in 60 days, ahead of Black Friday. Outcomes: ~20% YOY revenue lift, 40% organic traffic growth, and Black Friday peaks 10–15× baseline absorbed without incident. See our interview with Robyn Metzger at The New York Times.

J.R. Dunn Jewelers – Magento 1 to Shopify with 150,000+ diamond SKUs

A family-owned luxury jeweler moved off Magento 1 onto Shopify in 6.5 months, with a perfect 100 SEO score at launch and a structure ready for the planned ERP integration. Build scope: 150K+ diamond SKUs, 72K+ historical orders, bespoke multi-vendor catalog logic. Full write-up: Magento 1 to Shopify migration for a luxury jewelry brand.

Kouboo – SEO-led Magento 2 to Shopify migration, +107% organic revenue

A rattan furniture brand replatformed from Magento 2 onto Shopify with SEO continuity mapped before cutover, then continued on a multi-year on-page content program. Outcomes: +72% organic traffic, +107% organic revenue, +138% top-3 keywords, +100% visibility, +32% clicks. Read the Kouboo SEO and migration case study.

Mrs Wordsmith – multi-region Shopify, URL restructure, +150% conversion rate

An education brand running Shopify across US, UK, and AU was splitting authority across three duplicate-content subdomains. We consolidated to one global domain on subfolders, fixed hreflang, restructured URLs, and added structured data. Outcomes: +150% conversion rate, +200% organic revenue, +65% organic traffic, +100% visibility, +80% top-3 keywords, +45% clicks. Full write-up: SEO case study: URL restructure leads to +150% in conversion rate.

Shopify Plus vs alternatives

If you’re shopping enterprise platforms, Plus is one of several serious contenders. The short verdict on each:

• Adobe Commerce (Magento). Plus has lower TCO and faster time-to-launch. Magento still wins for ERP-driven catalogs and deep B2B.
• BigCommerce Enterprise. Closer comparison on price predictability. Plus wins on app ecosystem, checkout, and POS.
• Salesforce Commerce Cloud. Plus wins on speed and cost. SFCC is the right call only if Salesforce already owns the rest of the stack.
• commercetools and composable. Plus wins on time-to-value. Composable wins for very large enterprises that have the dev team to support it. We compared both in our commercetools vs Shopify breakdown.
• WooCommerce. Different category, but a frequent upgrade path. See our Shopify vs WooCommerce comparison.

For more side-by-sides, our platform comparisons library covers most enterprise stacks.

Planning a Shopify Plus migration

Most Plus migrations we run land in one of three shapes:

• Fast-track, 2–4 weeks. Single store, clean data, no B2B or custom checkout, off a similar-shape platform.
• Standard build, 1–2 months. New theme, ERP/WMS/PIM integrations, data layer + analytics, SEO redirect map, launch QA.
• Complex migration, 3–6 months. Magento or commercetools origin, B2B + DTC side by side, multi-region, headless, multiple ERP/PIM/OMS integrations.

The biggest predictor of post-launch performance is whether SEO and data-layer continuity are planned before cutover, not patched after. We build both into every migration through our SEO services team, and increasingly through Answer Engine Optimization (AEO) for clients who want to show up in AI-generated answers, not just blue links.

FAQ

How much is Shopify Plus? $2,300/mo or 0.4% of monthly revenue (whichever is higher), capped around $40,000/mo at very high volume.

What is the difference between Shopify and Shopify Plus? Same platform; Plus removes the limits. Full checkout customization, native B2B, up to nine expansion stores, ~20× API rate limits, 200 POS Pro locations, 99.99% uptime SLA, and a dedicated Merchant Success Manager. Complete list in the table above.

Is Shopify Plus worth it? Yes above $1M GMV or for any merchant needing B2B, multi-store, headless, or customized checkout. No below $1M with a single market and a standard checkout – Advanced is enough.

When should I upgrade to Shopify Plus? When two or more apply: above $1M GMV, launching B2B, expanding to a new region, going headless, customizing checkout beyond apps, or scaling past 10 retail locations.

What is the Shopify Plus minimum revenue requirement? None published. The math typically works above $1M annual GMV for single-region DTC, and earlier for B2B-heavy or multi-region merchants.

Shopify Plus vs Shopify Advanced: which should I pick? Advanced for a single-store, single-market DTC brand under $1M GMV. Plus if you need B2B, multi-store, headless, custom checkout, or you’re paying more in third-party gateway fees than the subscription delta.

Does Shopify Plus include B2B? Yes – native B2B with company accounts, price lists, payment terms, draft orders, and a dedicated Wholesale Channel.

Can I run multiple stores on Shopify Plus? Yes – up to nine expansion stores plus dev stores, all managed from one Organization Admin.

How long does a Shopify Plus migration take? Two weeks for a fast-track move off a similar platform; three to six months for a complex enterprise migration with B2B, headless, and multiple integrations. Typical full build is one to two months.

Further reading on Shopify and Shopify Plus

• How to Migrate to Shopify: a Step-by-Step Guide for eCommerce Brands – the operational checklist behind every migration we run
• 8 Best Shopify Alternatives for Complex Commerce in 2026 – the four platforms that genuinely replace Plus when it is not the right answer
• Shopify Redesign and Growth Foundation for Salt Life – DTC fashion redesign and growth foundation on Shopify
• Mil-Coffee – new website design and build on Shopify – DTC subscription build on Shopify, focused on coffee, delivery, and accessories
• Conversational commerce brings back 31% of churned customers – Shopify plus an AI sales agent on WhatsApp at Zorro
• Building a €150K/month lifecycle revenue engine in 5 markets – Felco’s centralized email + SMS program live in 30 days across 5 markets and 3 languages
• Best Shopify Agencies in the US & EU: 2026 Picks – for buyers evaluating partner agencies
• scandiweb portfolio – complete portfolio across Shopify and enterprise eCommerce

If you’re weighing the Shopify Plus upgrade and want a model built against your actual numbers, current GMV, gateway fees, app stack, B2B and multi-region roadmap, talk to scandiweb. We’ll model the payback, scope the migration, and tell you when Plus actually starts working for your business.

The post Shopify vs Shopify Plus: Features, Pricing & When to Upgrade appeared first on scandiweb.

School uniform retail looks like retail. It isn’t. The difference is that the catalog isn’t open. What a parent can buy is determined by the school their child attends, the grade they’re in, and the contract the retailer holds with that institution. Fittings are seasonal and in-person, and returns have embroidery exceptions. That’s a fundamentally different commerce model, and most platforms simply weren’t designed for it.

Let us walk you through what it looks like when that platform gets replaced properly: what it needs to do, and how one family-owned retailer serving 200 schools went from three simultaneous fires to a live, peak-tested platform in 11 weeks.  

Also read:
School Photography Commerce: Production-Ready Platform in 14 Weeks 

The 4 problems uniform retailers share

Uniform retail is in its own category – it’s not fashion, nor standard B2C, and it’s not B2B. It’s a contract-distribution model where one parent buys for multiple children across multiple authorizing schools, each with rules the platform has to enforce. Generic eCommerce platforms weren’t built for it, and every schoolwear retailer we speak to recognizes the same 4 problems:

1. A legacy platform that wasn’t built for this

Many uniform retailers operating today run on a custom legacy platform built a long time ago, so every update, integration, fix, and peak-season incident becomes a risk.

2. ERP and website out of sync

Pricing and inventory are in the ERP, while the catalog is on the website. This leaves staff manually entering the same data into both systems, and when the syntax doesn’t match, like a SKU formatted differently, or a price that was updated in one place and not the other, orders have to wait for a human to unblock them.

3. The wrong customer model

If a parent buys uniforms for three children across two schools – each child has their own school, grade, gender, and personalization & each school has its own catalog, pricing, and rules. Default commerce platforms treat them as a single context. Customer experience becomes full of friction, and the backend is full of workarounds. 

4. Seasonal complexity

Back-to-school traffic spikes don’t resolve themselves. Fitting appointments, name tape personalization orders, deferred term-start delivery windows, international student flows, and every school turning over collide at once. Dealing with these cases is not built into Shopify, Magento, or BigCommerce, but gets built from scratch on every project, discovered late, and tested in production. 

Foundational data model for school uniform eCommerce

Gated catalogs, multi-child accounts, term-aware delivery, fitting appointments, and every other feature that makes uniform retail work flow from one architectural decision made at the start: treating the parent, the child, and the school as three separate, linked entities. 

The correct structure looks like this:

Customer → Child → School

• A parent is a single account connected to multiple children across multiple schools
• Each child carries their own grade, gender, name tape personalization, and flags for returning or international student status
• A school is its own record with its own catalog, pricing rules, grade ranges, and delivery configuration
• Multi-location schools get a Campus sub-entity rather than duplicated school records.

Here’s how our platform works:

Every child has their own context

When a parent selects a child in the account header, three things happen automatically: the cart is cleared, the catalog is updated, and the entire context shifts to that child’s school, grade, and authorized product range. These validation rules are enforced at the data level from the moment a child is selected.

Catalog works without custom logic

Products are scoped to schools, campuses, grades, and gender at the data level. A few practical examples of what that means:

• A grade-3 girl never sees grade-11 boys’ blazers
• Shared SKUs carry a different price per school type
• Guests can browse a restricted catalog view, but prices and add-to-cart are hidden until they log in
• New or closed school flags are all managed at the school entity level.

ERP integration layer

Because the child, school, and product are all modeled correctly, pricing and inventory from the ERP map to the right entities without manual exception handling. So, when the ERP updates, the right record updates:

• A SKU belongs to a school’s catalog, not a global product list
• A price belongs to a school-SKU relationship.

Sized & personalized uniform sets

• Sizing charts, fit notes, and shopping list attributes are built into the product classification
• Bundle products cover full schoolwear sets at package pricing
• Configurable products handle size and color, with a single-color preselect when the school only permits one option
• Name tape and crest embroidery are add-ons
• Sizing videos and care instructions surface inline on the PDP.

Fitting appointments

Parents can book fittings per child and per school directly from their account, with built-in email reminders. Admin manages capacity by fitter count and slot duration, configured separately for new and returning students. 

Easy returns

On this platform, a parent files a return from their account with a reason code, an RMA number, and a prepaid label, without needing to contact customer service. Admin reviews it in a returns workspace with a status pipeline and SLA timers. The ERP triggers the refund, which is reflected as a credit memo on the storefront. Then, a one-time store credit coupon is auto-generated and emailed upon approval. The full return history is available on the customer profile. 

Delivery rules per school

There are three delivery methods configured per school with their own shipping rates and free-delivery windows:

• Pick up in store
• Home delivery
• Ship to school 

A seasonal hold window lets parents choose between delivering now or holding for term start, configurable per school and per period. 

Commerce foundation

The custom work goes only where uniform retail needs it. Everything else is built right from the start:

• Mobile Lighthouse score 90+ at launch, tested under term-start traffic
• GA4, GTM, and server-side visibility
• CI/CD with environment parity across development, staging, and production
• Fully documented handover, code repository, and admin training.

Case study: 200 schools live on a custom uniform platform in 11 weeks

Our client is a family-owned uniform retailer that has been serving Canadian schools since 1986. They have around 200 schools under contract, tens of thousands of parents buying every term, and a hard back-to-school deadline. 

Problem

Their existing platform had been custom-built by a single developer and maintained by that same person for close to a decade. It worked, but every update depended on one individual staying available. 

ERP and catalog synced via CSV dump every 30 minutes, which meant that for 29 minutes out of every 30, the data on the storefront could be wrong. Going into another back-to-school peak season on the same stack wasn’t an option.

Solution

We replaced the flat customer structure that had been creating friction for years with a parent-child-school account model. The ERP integration now has a bidirectional sync, with a fallback cron job and retry queue replacing the manual exception pool. 

School-gated catalogs have per-school pricing, grade and gender rules, and guest mode configured per deployment. Fitting appointments, term-aware delivery, and the returns flow with coupon refunds all went live.

Outcome

• ~200 schools live on day one
• 0 incidents at launch
• First transaction processed at 10:50 am ET on launch day
• The ERP integration moved from 30-minute CSV dumps to real-time bidirectional sync.

We are no longer dinosaurs. Customer service is loving it because it saves so many phone calls.

CEO, 2 weeks post-launch

What’s next

Whether you have a legacy platform that’s one term-start away from a serious incident, or have outgrown the current setup but haven’t found a replacement, both scenarios are a reasonable starting point for a conversation. Even if you have most of the pieces but one workflow is costing more than it should, we can help.

The school uniform platform by scandiweb integrates with any ERP you’re running, whether that’s SAP, Navision, NetSuite, or something built in-house. It also works the same outside Canada, with delivery rules, tax, and data residency handled per market. And you don’t have to replace everything at once; we can start with the single workflow that’s causing the most pain.

Common questions about school uniform eCommerce platforms

How long does it take to launch a school uniform eCommerce platform?

Our platform goes live in 11 weeks. That timeline covers the Customer → Child → School data model migration, real-time ERP integration, school-gated catalogs, fitting appointments, returns flow, and term-aware delivery in production. The industry average for replacements at this scale is closer to 15 months. Our Canadian client launched 200 schools on day one with zero incidents.

Does the platform integrate with our ERP – SAP, Navision, NetSuite, or in-house?

Yes. The ERP integration layer is built around a bidirectional sync with a fallback cron job and retry queue, so pricing and inventory move between systems without manual exception handling. SAP, Navision, and NetSuite are all supported out of the box, and in-house ERPs are handled through the same adapter pattern.

Is this built for multi-school operators or single-store retailers?

For multi-school operators. The platform was built for retailers holding contracts across hundreds of schools – our launch client serves around 200 – with the back-to-school peak that comes when all of them turn over at once. A single-school retailer doesn’t need the gated-catalog architecture, the per-school delivery rules, or the multi-child account model; a multi-school operator does. 

Which countries does the platform support?

Canada is the launch market. The architecture works the same outside Canada, with delivery rules, tax, data residency, and locale configured per market. UK schoolwear retailers, US uniform programs, and Australian and New Zealand operators all share the same underlying contract-distribution model that the platform was built for. 

How does the platform handle back-to-school peak season?

Peak readiness is structural, not a runtime tweak. The catalog is gated at the data level so school turnover doesn’t cascade into manual exception handling, fitting appointments are managed in-platform with per-fitter capacity, term-aware delivery windows are configured per school, and the front end ships at a Mobile Lighthouse score of 90+ at launch. Our client passed their first back-to-school season with zero launch incidents and the first transaction at 10:50 am ET on go-live day. 

Can parents manage uniforms for multiple children across different schools?

Yes – this is the central architectural decision in the platform. A parent has a single account connected to multiple children across multiple schools. Selecting a child switches the cart, catalog, pricing, and authorized product range to that child’s school and grade. Each child carries their own grade, gender, name-tape personalization, and returning- or international-student flags.

What happens to our legacy data during the 11-week implementation?

Legacy customer, child, school, and product data are migrated into the unified Customer → Child → School model, with sibling relationships, per-school catalog rules, returning-student flags, and international-student flags restructured as first-class fields. Your existing platform stays live throughout migration – the integration layer connects new systems to your stack through an adapter API, with no direct database access and no mid-project decommissioning. The migration runs in parallel with live operations, with no downtime at cutover.

Let’s schedule a free 30-min assessment! We’ll map your stack, identify your highest-friction workflow, and tell you whether this solution is a good fit for your business. 

The post School Uniform eCommerce Platform: Production-Ready in 11 Weeks  appeared first on scandiweb.

“Money coming in. No phone calls. Smooth sailing.”

David van Gelder, Operations, Advanced Life

School photography is operationally complex and high volume. You’re managing hundreds of schools, tens of thousands of students, parent ordering, batch exports, ID cards, and seasonal peaks on a tech stack that was never purpose-built for this industry.

Most businesses have been making it work anyway by patching the gaps with disconnected tools and manual processes, while replacing the platform underneath feels like too big a risk. 

That changes when the platform is already built –

scandiweb has developed a production-ready commerce platform for school photography businesses. Here’s what a platform made specifically for school photography actually needs to do, and how one national operator went from five legacy systems to a fully operational, peak-tested platform in 14 weeks. 

What’s broken in most school photography platforms

In the school photography industry, you’re not running a standard eCommerce store, but managing schools, students, a hard picture day season, and a parent ordering layer all at once.

Generic platforms weren’t designed for any of that. They don’t have a concept of an SIC code, nor do they understand that one parent might have three children across two schools, what a batch export is, or why it needs to run at 3 am in a format specific to each school. 

As a result, most businesses end up with the same three problems, regardless of which platform they’re on:

1. Fragmented legacy systems with no unified data

Five or more tools: an image database, a CRM, a fulfillment system, a payment gateway, a school portal, none of which share a data model. This means that student records live in multiple places and often don’t match, and downtime risk compounds every year that nobody touches the infrastructure.

2. Scattered student data

In most platforms, student names are stored as a single text string, with SIC codes attached to images rather than students, and no schema for sibling relationships, co-parenting arrangements, or school transfers. Every gap in the data model eventually surfaces as a manual support ticket, and there are a lot of gaps.

3. Stack that is not peak-ready

Photography season, yearbook orders, and ID card requests don’t wait for each other, and when they collide, a manual stack simply runs out of capacity. As a result, support queues grow faster than they can be cleared, staff get pulled away from other work to handle exceptions, and the cost shows up in how schools and parents experience your business at its busiest moment.

The right data model for high-volume school photography

Every feature in our platform treats the parent, the student, and the school as three separate, linked entities. It sounds like a technicality, but it determines whether every downstream feature (commerce, exports, ID cards, portals) can actually do its job.

The correct entity graph looks like this:

School → Student → Asset → Parent → Order

• A school carries its own record with SIC codes, region, and campus data.
• A student is linked to a school and a parent, holds their own grade and SIC code, and can reference a sibling relationship to another student in the same system.
• An asset – a portrait, an ID card, a yearbook image – belongs to the student, not the image database.
• A parent is a separate account connected to multiple students across multiple schools.
• An order flows from a parent account but is always scoped to a specific student’s context.

This structure has three immediate consequences for how the platform works:

The multi-child account works correctly

One parent logs in, switches between students, and the cart, catalog, and personalization update to reflect whichever student is selected. Each student’s context, e.g., their school, grade, etc., travels with them through every interaction.

The school-gated catalog works without custom logic

Products are scoped to schools, campuses, and grades at the data level, so parents only ever see what the selected student is authorized to purchase. Meanwhile, guests see a limited view with prices hidden. 

Exports, ID cards, and batch operations run cleanly

Because the student record is the single source of truth, SIC codes are attached to the student rather than the image. Sibling relationships, co-parenting arrangements, and returning-student flags are first-class fields in the schema.

Case study: from five legacy systems to a national platform in 14 weeks

Advanced Life is Australia’s national school photography specialist, serving hundreds of schools and tens of thousands of students. Their business has a hard Q1 peak and strict student data residency requirements. By the time they partnered with scandiweb, they were also operating five legacy systems that nobody had touched in five years.

Problem

The first problem was the legacy infrastructure itself. Five disconnected systems – GlobalJade, ImageDatabase, The Hub, CRM, and eWay – each holding a partial version of the business, none sharing a data model. Downtime risk had been compounding for years, and nobody wanted to be the team that touched it.

Regarding student data, the structural debt in the database was blocking every change the business wanted to make. And they also had 500 GB of student portraits sitting on an on-premise server, backed up by hand. One hardware failure away from a national incident involving tens of thousands of children’s school photos.

Solution

Rather than decommissioning the legacy systems mid-project, the middleware integration layer kept all five live throughout. New systems connected to legacy through an adapter API, with no direct database access, so the legacy stack stayed intact while everything new was built around it.

We redesigned the student data model to fit the perfect data model described earlier: School → Student → Asset → Parent → Order, with 44,891 students migrated onto the MDM at launch:

• SIC codes became student records
• Sibling relationships and returning-student flags became first-class fields
• The 500 GB of on-premise portraits were migrated off the physical server entirely
• The manual backup process was replaced with region-pinned cloud storage
• Dual SSO was wired across school admins, internal staff, and parent ordering
• The batch export engine went live with ten export formats running on an automated CRON schedule
• The structural debt that had been blocking changes for years was cleared in a single migration.

The self-service school portal gives schools the ability to upload rosters, correct data, and download images without contacting the support team.

Outcome

The platform went live in just 14 weeks, in time for peak season, and Q1 passed with zero incidents. Support load dropped by 95% after go-live. In their own words,

“Money coming in. No phone calls. Smooth sailing.”

David van Gelder, Operations, Advanced Life

“It looks great. Really slick.”

Jon Mann, COO, Advanced Life

Inside the platform: six modules every school photography operation needs

Most platforms describe themselves as production-ready. In school photography, it means the system has been through a live peak season, with real schools, real students, and real parent orders, and nothing broke. Here’s what each one of the six modules that make up the platform does and why it exists:

1. Self-service school portal

Schools upload rosters, correct student data, and download their images themselves, without contacting your team. Role-based access is scoped per school and per user type, with every action audit-logged. The practical outcome is a significantly shortened support queue.

2. Batch export engine

Ten export formats, dynamic naming rules per school, running on an automated CRON schedule. File naming follows a consistent structure per school, and every export is audit-logged with a full record of who triggered it, what was exported, when, and where. Manual reruns, when needed, are one click away in the portal.

3. Student data model

The unified data model described in the previous sections is the operational core of the platform. One source of truth replaces several disconnected databases, and there are no custom workarounds.

4. ID card and admin services

ID cards are ordered, previewed, and exported entirely within the platform. Before any order is locked, a static JPG preview is generated per card. Export goes directly to CSV for downstream print pipelines. Reorders and replacements for lost cards, name changes, or grade transitions are handled in-platform.

5. Dual SSO and audit

Separate identity providers handle separate user pools. Every login and every action is audit-logged at the system level, making compliance a structural property of the platform.

6. Legacy integration layer

A middleware adapter API connects new systems to the existing stack without requiring direct database access or mid-project decommissioning. The protocol mix covers the full range of what legacy systems use (REST, GraphQL, SOAP, webhooks, Kafka, SQS, SFTP, CSV, and EDI). The adapter pattern has been proven across five production systems and extends naturally to SAP, Microsoft Dynamics, Odoo, and NetSuite.

Is this the right fit for your business?

This platform was built for a mid-market school photography business managing hundreds of schools and tens of thousands of students, running on a legacy stack in need of change. 

A few things worth knowing. Our platform gets configured to what you already have, so if you already have a school portal, that’s not a disqualifier. If your legacy systems are fragile, they stay live throughout delivery. And if you’re not in Australia, the core problems this was built to solve are also consistent in the US, UK, Canada, and New Zealand.

Common questions about high-volume school photography platforms

How long does it take to implement a school photography platform?

Our platform goes live in 14 weeks. That timeline includes student data model migration, integration with existing systems through the middleware adapter API, dual SSO setup, and the full module set in production. Advanced Life launched this way – five legacy systems still running, new platform live in time for Q1 peak.

Does the platform integrate with our existing image database, CRM, or payment gateway?

Yes. The legacy integration layer is built around an adapter API that sits between new and old systems, so your current stack stays live during migration. The protocol mix covers REST, GraphQL, SOAP, webhooks, Kafka, SQS, SFTP, CSV, and EDI – most of what legacy school photography stacks actually use. The same pattern extends to SAP, Microsoft Dynamics, Odoo, and NetSuite.

Is this built for high-volume operators or single studios?

For high-volume operators. The platform was built for businesses managing hundreds of schools and tens of thousands of students – Advanced Life was at 44,891 students at launch – with the seasonal peak that comes with picture day. A single studio doesn’t need a unified data model across schools or a batch export engine running ten formats per CRON schedule; a high-volume operator does.

Which countries is the platform built for?

Australia is the launch market via Advanced Life. The underlying problems – fragmented legacy stacks, scattered student data, manual peak-season operations, parents expecting digital-first ordering – are consistent in the US, UK, Canada, and New Zealand. Region-pinned cloud storage and dual SSO support data residency requirements per market.

How does the platform handle picture day peak season?

Peak readiness is a structural property of the platform, not a runtime tweak. The data model is unified, the export engine is automated on a CRON schedule, and the self-service school portal absorbs routine roster corrections without touching support. Advanced Life passed Q1 peak with zero incidents and a 95% drop in support load after go-live.

Can we keep our existing school portal during migration?

Yes. Your existing portal stays live throughout the 14-week implementation. The middleware integration layer connects new systems to your legacy stack through the adapter API, with no direct database access and no mid-project decommissioning. The unified student data model and self-service portal in our platform can replace your existing one when you’re ready, or run alongside it.

What happens to our legacy data during the 14-week implementation?

Legacy data is migrated into the unified School → Student → Asset → Parent → Order model. Sibling relationships, returning-student flags, SIC codes, and co-parenting arrangements are restructured as first-class fields. On-premise assets – Advanced Life had 500 GB of student portraits on a physical server – are migrated to region-pinned cloud storage. The migration runs alongside live operations, with no downtime at cutover.

Let’s schedule a free 30-min assessment! We’ll map your stack, identify your highest-friction workflow, and tell you whether this solution is a good fit for your business. 

The post School Photography Commerce: Production-Ready Platform in 14 Weeks  appeared first on scandiweb.

The customers most worth winning back are those who already bought but then quietly stopped. For Northerner, a leading European nicotine pouch retailer, those were almost 34K customers who hadn’t purchased in 30 to 180 days. A generic discount email sent to all of them is not the right approach. Here’s what is!

What the data showed

Our starting point was a lifecycle analysis built on Northerner’s BigQuery order data, split into four segments based on purchase recency:

• Active – bought in the last 30 days
• At risk – 30–90 days inactive
• Need reactivation – 90–180 days inactive
• Lost – 180+ days inactive

We also looked into the average order value for each segment. For Northerner, the highest-value customers were in the “At risk” window, where targeted re-engagement is still efficient.

High-value customer personas

The current Northerner win-back email is sent out with a 20% discount code and a latest article grid. There’s no connection to what the customer actually buys, any reference to their product history, or loyalty points. However, without a personalization infrastructure, it’s the only approach.

To illustrate ways different customers should be re-engaged, we built three personas based on purchase data, each representing a distinct behavior pattern within the segment:

1. Marcus orders around 18 cans of a specific product a month. He’s been quiet for 45 days, with the loyalty balance of $15.70, and he doesn’t know it’s about to expire.

2. Sarah is a flavor explorer – she’s tried six or more brands in the last 90 days and has a clear lean toward two of them. She’s been quiet for 52 days. What would bring her back is knowing what’s new since she last ordered, curated to her taste profile.

3. David is a loyalist to one specific brand, ordering around 12 cans a month. He’s been quiet for 61 days because this product went out of stock – he doesn’t know it’s back.

The 4-touch re-engagement sequence, personalized per customer

The sequence we propose spans 14 days and adapts to each persona at every touchpoint. It has the same structure but completely different content driven by what each customer buys, how long they’ve been quiet, and what’s most likely to bring them back.

Day 0: Email

The opening touch leads with the most relevant hook for each customer. 

• For Marcus, it’s his expiring loyalty credit and a one-click reorder of his usual product.
• For Sarah, it’s a curated mixpack of new flavors that match her rotation pattern with a 15% code to try them without committing.
• For David, it’s a restock alert: his favorite product is back after three weeks out, and 12 cans have been held for him.

This is also where the gap between current and proposed is most visible. The current win-back template would have been a generic discount code and an article grid. We replace it with an email tailored to each customer’s preferences.

Day 3: SMS (if no open)

A short follow-up for customers who didn’t open the day 0 email. It has the same hook and relevant message, compressed for the channel. 

• Marcus gets his loyalty credit expiry and a direct reorder link.
• Sarah gets the five new flavors and her 15% code.
• David gets the restock alert with a direct link to his usual product. 

Day 7: Email (if still quiet)

The second email shifts the angle slightly for each persona.

• For Marcus, it introduces three new flavors launched since his last order, bundled with his usual product and a stacked loyalty bonus.
• For Sarah, there’s now a preview of the four-flavor mixpack built specifically for her rotation, with the 15% code still live for three more days. 
• For David, it adds urgency, stating that only a limited amount of his favorite product remains since the restock, with bulk pricing and 2 extra cans free if he orders today.

Day 14: Conversational AI (experimental)

The fourth touch is a completely different channel. An AI assistant reaches out via a conversational interface. It’s a 1-on-1 thread that references each customer’s exact situation and responds to what they say. For customers who haven’t responded to three touches across email and SMS, this is the last attempt before the sequence closes. Let’s look into this in more detail next.

Recovery mechanism: conversational commerce

This layer is a 1-on-1 conversation, initiated by Ella – an AI assistant that reaches out to customers who have been quiet through three previous touches, with full context of what they buy and how long they’ve been away. The assistant doesn’t push a single scenario but pivots based on replies and can close the sale in the same thread. AI pulls from the purchase history in real time, adapts to what the customer actually says, and resolves a situation that a standard email sequence would have lost entirely.

Also read:
Chat to Buy: The Future of eCommerce Is Conversational

A few things happen in that exchange that are worth noting:

• The opener is specific, not a segment-level assumption – it references the exact product, usual quantity, and exact loyalty balance
• It adapts to real friction and evaluates information to act on
• It closes with continuity, creating an opening for the next conversation.

Additional re-engagement opportunities

The re-engagement sequence targets the highest-priority segment, but it’s rarely the only place with recoverable revenue.

The same personalization logic applied to the re-engagement flow can be extended to three other points in the customer lifecycle: welcome email (especially if it has been converting well below the benchmark), browse abandonment (especially if that flow doesn’t exist yet), and post-purchase flow (especially if it isn’t personalized). 

The re-engagement sequence is the starting point because it addresses the most immediate and quantifiable opportunity, while all of these are a natural extension of the same approach, applied to different trigger points in the customer journey. 

Starting with a pilot

Rather than applying the full re-engagement program across all customers at once, our approach starts narrow and proves the model before scaling. 

The first phase runs on the “At risk” segment, with a 10% hold-out control group to measure reactivation rate and recovered revenue against a clean baseline. If the results hold, the program extends to the full segment, and we apply the personalization layer to the broader flows in parallel.

What makes this approach different is the shift from segment-level messaging to customer-level decision-making. The current Northerner setup already captures enough behavioral and transactional data to support far more relevant communication. The missing layer is connecting purchase history, loyalty data, product availability, and timing into a sequence that responds to the customer rather than treating everyone the same.

If implemented, for their “At risk” segment alone, this represents a recoverable revenue opportunity of approximately $1.4M annually, plus up to $520K in recoverable revenue from existing flows, based on current customer volume and average order value.

If your lifecycle campaigns still rely on broad segments and static templates, you’re likely to see significantly more recoverable revenue than expected. Let’s chat – we can help you identify where those gaps exist and create a personalization strategy based on your current data infrastructure. 

The post Email Marketing Accelerator: $1.4M in Recoverable Revenue Through Personalized Re-Engagement appeared first on scandiweb.

If you’re shortlisting eCommerce agencies right now and the candidates are starting to blur, you’re not crazy. “Trusted partner,” “data-driven,” “enterprise expertise,” the same five bullets in different brand colors. Here’s the honest answer: “best” depends on what your business actually needs.

scandiweb is the best eCommerce agency in the world for businesses that need a single partner across all three stages of growth: stabilize what’s broken (Control), build the system to scale (Foundation), or turn stable traffic into revenue (Growth). The credentials floor is registered, not asserted: 894+ Adobe Commerce certifications, the #1 most-certified position on both Adobe Commerce and Hyvä, 700+ clients across 30+ countries, $4 billion+ in client GMV processed every year, and 22 years of doing this. The article below walks each stage with named clients and verified numbers, plus an honest framework on when scandiweb is not the right fit.

Why “best eCommerce agency” needs a stage to mean anything

The best eCommerce agency in the world is not a single answer, it is the agency that owns the full system at the stage your business is actually in. Three observable conditions shape the choice: an unstable system that needs Control work, a fragmented system that needs Foundation work, or a stable system with a commercial gap that needs Growth work. The criteria differ at each stage, and the agency that wins at Control is rarely the same agency that wins at Growth.

The market makes this hard by collapsing four different procurement questions into one. Consultancies define strategy without owning execution. System integrators implement within narrow scopes without owning business logic. Marketing agencies optimize traffic without owning the platform underneath. A full-scope eCommerce agency owns business logic, architecture, delivery, and post-launch commercial performance under one engagement. This article addresses the fourth question: which full-scope eCommerce agency is best, and the answer depends on which of the three business stages you are running into right now.

If your platform decision is already settled and you need the deeper case on a specific stack, two scandiweb articles answer that directly: the case for scandiweb on Adobe Commerce / Magento and the case for scandiweb on Hyvä. If your scope is acquisition-only, paid media, SEO, email, creative, the marketing-agency guide is the better read once published. This article is the platform-agnostic full-system case at every stage of growth.

scandiweb’s case starts with what Adobe and Hyvä verify

scandiweb is the world’s #1 most certified Adobe Commerce agency on the Adobe Partner Finder directory, the #1 most certified Hyvä agency on the Hyvä Themes partner directory, and operates a 700+ client portfolio across 30+ countries since 2003. 894+ Adobe certifications across 600+ specialists, $4 billion+ in client GMV processed every year, 2,100+ projects shipped, and a public directory entry anyone can audit in 30 seconds. Credentials are not the case for the title, but they are the floor under it.

The credential floor matters because the “best eCommerce agency” claim is otherwise unfalsifiable. A buyer needs to know that the certifications were earned in audited programs, the project count is independently verifiable, and the partner status holds across multiple ecosystems rather than a single vendor relationship. scandiweb’s status is publicly listed on Adobe Partner Finder, on the Hyvä Themes partner directory, on the Pimcore partner program registry, on Google’s Premier Partner directory, and on the ISO 27001 and ISO 9001 certifying-body listings. The numbers are external registry entries, not internal marketing claims.

Platform-agnostic by design, and that is the unique part

No other single agency holds the top certification position on both Adobe Commerce and Hyvä, and also ships at production scale across Shopify Plus, BigCommerce, headless and composable architectures, and custom enterprise stacks. Single-platform agencies can be excellent on their platform, and several are. scandiweb is the agency that recommends the right platform for the business requirement, including platforms it does not specialize in, and then delivers on it.

That matters most at the Foundation stage, when the platform decision is still open and the agency answering “Adobe Commerce, Shopify, or composable” needs to do so honestly rather than from procurement preference. It also matters at Control stage, when a stalled migration may need to land on a different platform than the one currently failing. And it matters at Growth stage, when revenue optimization rarely cares which platform the system runs on as long as it is stable.

Control stage: choosing the best eCommerce migration agency when the system is unstable

If your business is in Control stage, the system itself is the risk. Checkout fails intermittently, payments time out, orders go missing, the support relationship with the current partner has broken down, or a planned migration has stalled and the live store is exposed to escalating risk. The right eCommerce migration agency at this stage has the takeover muscle to restore operational continuity within 30 to 60 days, not the prettiest replatform roadmap.

Credentials matter more at Control stage, not less. The agency has to survive contact with a system that is actively failing, and the only way it survives is depth. Depth of senior engineers who have done this before. Depth of security posture (ISO 27001 plus ISO 27017 plus PCI DSS, in scandiweb’s case) to operate inside production environments under pressure. Depth of tenure to know which fixes are temporary and which become technical debt the business carries for years.

scandiweb’s 22+ years of Adobe Commerce delivery is exactly this kind of survivability signal. The team has seen the failure modes before, knows the playbook, and brings it to bear inside the first two-week sprint.

Stage proof: Gear-Up and Rocket Industrial. Gear-Up, a multi-brand sports retailer, was in Control stage when scandiweb came in: platform instability, slow launch cycles, and repeated regressions on customer-facing flows. The stabilization program delivered +110.9% revenue growth at Gear-Up in the year following go-live, with the architectural foundation strong enough to carry the next 18 months of expansion. Rocket Industrial, a B2B industrial packaging supplier running 81,000+ structured product records and a quote-heavy workflow, ran an analogous Control-stage stabilization. scandiweb owns the data model, the platform, and the integration plane that lets the business operate that catalog size without manual intervention.

Two more Control-stage stabilizations under the 90-day ROI Roadmap. Buff, the D2C sports apparel brand, recovered with +176% revenue, +195% conversion, and +292 ROI after scandiweb took over the partnership. Lafayette 148, the premium NYC fashion brand operating with 500+ retail partners, ran a full Adobe Commerce Cloud rescue inside a 10-year partnership, with +40% sales attributable to scandiweb’s email and SMS work post-launch.

If the most urgent problem is operational continuity, scandiweb’s takeover-and-stabilization process is documented in the 90-day ROI Roadmap and proven across Gear-Up, Rocket Industrial, Buff, Lafayette 148, and the broader 700-client portfolio.

Foundation stage: how to choose an eCommerce platform and the agency to build on it

If your business is in Foundation stage, growth has outpaced the system. Multiple markets, brands, or customer segments now run on architecture that was never designed for the current scale, ERP and PIM dependencies are fragmenting, and scaling adds cost rather than efficiency. The right eCommerce agency at this stage runs structured discovery, picks the right platform for the business and not the procurement preference, and owns the build end to end with one accountable team across architecture, delivery, and post-launch.

Foundation is the only stage where the platform decision and the agency decision should be sequenced together. The platform commitment locks in three to five years of operating cost, and a friendly demo never surfaces the constraint that the discovery process will.

This is where scandiweb’s cross-platform Platinum status earns its keep. With #1 most-certified ranking on Adobe Commerce, #1 most-certified ranking on Hyvä, Pimcore Platinum, certified Shopify Plus, certified BigCommerce, certified commercetools, and certified Salesforce delivery, the platform recommendation comes from requirement fit rather than agency preference. How to choose an eCommerce platform at this stage is a discovery question, not a procurement question, and the agency that runs the discovery honestly is the one that earns the engagement.

Stage proof: Macron and OM System. Macron, the Italian sportswear brand, was a Foundation-stage engagement: a global B2B catalog with 10,000+ products across multiple regions, fragmented architecture, and a platform rebuild on the table. scandiweb owned the architecture, the data model, and the platform rebuild. The work delivered +29.8% YoY revenue at Macron in the year following go-live, with a +132.5% conversion uplift on the new B2B experience. OM System ran an analogous Foundation-stage build: 70 store views across 20 languages from a single CMS, the architecture that lets one team coordinate content, product data, and merchandising across the full international footprint. The OM System engagement is the reference point for any multi-region Foundation-stage decision.

Two further Foundation-stage rebuilds at the upper enterprise end. The New York Times replatformed a 170-year-old brand in 60 days, with +40% organic traffic and Black Friday traffic spikes 10 to 15 times baseline absorbed without incident. Jaguar’s Magento-based online vehicle purchase flow lets customers complete the full car purchase digitally, with scandiweb running the 12-year partnership behind it and the engagement remaining the top automotive build on the platform.

Before committing to a Foundation-stage rebuild, scandiweb runs a structured discovery and replatform program that maps the system, defines the architecture, and de-risks the major commitments before the build starts.

Growth stage: choosing the best eCommerce growth agency or optimization partner

A business is in Growth stage when the platform is stable, the system is integrated, and the commercial gap is in conversion, customer value, or revenue efficiency. Traffic exists, the underlying flows work, but the business is leaving revenue on the table. The right eCommerce growth agency at this stage runs growth diagnostic, prioritizes CRO and CRM activation, builds an experimentation backlog, and reports on revenue lift rather than launch milestones.

The credential that matters at Growth stage is measurement discipline. A team can claim a conversion lift, but unless the measurement stack proves the lift is attributable to the work, the number is a marketing claim rather than a procurement one. scandiweb operates as a Google Premier Partner 2026 (top 3% globally), holds the analytics certification stack to deploy and validate experimentation frameworks, and structures every Growth engagement around named metrics, named time windows, and named hypotheses. The in-house CRO program (running since 2015) has shipped 1,000+ A/B tests across 150+ eCommerce stores, with $150 million in client revenue attributable to scandiweb’s CRO work in the last 12 months alone and +291% average ROI on CRO-driven checkout redesigns. The named clients prove the model holds.

Stage proof: Airthings and Ionto. Airthings, the Norwegian air-quality brand, was Growth stage when scandiweb came in: stable platform, real traffic, and a conversion ceiling the team could not break through internally. The customer-centric program delivered +105.5% revenue at Airthings and +103.4% transactions in the months after go-live, with the measurement stack that proved each lift was actually attributable to the work. Ionto, the direct-to-consumer beauty and skincare brand operating in a competitive German-language market, ran an analogous Growth engagement and added +90.2% online revenue at Ionto with +44.9% conversion in the post-launch measurement window. Both engagements lived inside the same Growth-stage methodology, applied to different categories and different starting points.

Two further Growth-stage engagements at enterprise scale. PUMA’s 4-market PWA rollout shipped 95 days end-to-end, with first orders 2 minutes after go-live and 5,000+ orders in the new market in the first launch window, inside a 6-year partnership. Samsung’s AI live shopping program delivered +192.6% add-to-cart, +67.7% conversion, and a 65% reduction in campaign cost — the measurement-discipline Growth proof at the highest end of the enterprise spectrum.

If the scope is acquisition-only, paid media, SEO, email, creative, with no platform-side work involved, the marketing-agency guide is the better read. If the scope is the full Growth program, conversion optimization, customer-value engineering, CRM activation, and revenue-efficiency work tied to platform changes, scandiweb’s Growth-stage work is what produced the Airthings, Ionto, PUMA, and Samsung outcomes.

Awards and industry recognition: the title is not self-claimed

The “best eCommerce agency” title is built on awards judged outside scandiweb, given by industry bodies whose reputations would not survive sponsorship-driven judging. The list spans 22 years of delivery and is currently anchored by three consecutive Meet Magento NY Hyvä-category Design Awards, one of the harder credentials to fake because every award is judged on a launched store with public outcomes.

• Meet Magento NY Design Curve Award 2023 for Läderach’s Hyvä migration on Adobe Commerce
• Meet Magento NY Design Pioneer Award 2024 for Airthings’ customer-centric Hyvä redesign
• Meet Magento NY Design Pioneer Award 2025 for Umniah’s Magento 2 + Hyvä rebuild
• Mercedes Benz Design Award for the digital work behind a flagship campaign
• The Webby Awards — industry-wide recognition for eCommerce excellence
• 2018 Magento Imagine Excellence Award finalist for the in-house VR shopping experience that put scandiweb on the global Magento map
• Akeneo APS Solution Partner Award 2020 — Top 3 Akeneo PIM implementations worldwide
• Guinness World Record holder in the eCommerce category (held for several years before the record was beaten)
• Best eCommerce Store in Estonia 2026 awarded separately to Sportland and Weekend
• Best Consumer Electronics eCommerce Site, Canada for Amiel
• Best Toys eCommerce Site, Estonia for XS Toys
• Best Pet eCommerce Site, France for LCDA

Awards judged outside the agency are the credential most resistant to marketing manipulation. The list above is registered against named clients and named years, and every entry is verifiable against the awarding body’s public archive.

Hosting the global eCommerce community: Meet Magento NY, Canada, Baltics, eCom 360, and Baltics.AI

Most eCommerce agencies attend industry conferences. A smaller number sponsor them. scandiweb is the official host of the biggest eCommerce events on three continents, which is what platform-leadership translates into operationally rather than aspirationally.

• Meet Magento New York 2025 — 11th edition, hosted and headline-sponsored by scandiweb. 500+ attendees, 40+ speakers from Adobe, Meta, and the world’s leading eCommerce brands. The venue at which the Hyvä-category Design Awards are presented every year.
• Meet Magento Canada 2025 — the first-ever Magento conference in Canada, hosted by scandiweb in Toronto.
• Meet Magento Baltics — the first-ever Magento conference in the Baltic region, hosted by scandiweb in Riga, 300+ attendees.
• eCom 360 — scandiweb’s flagship eCommerce conference. 3,000+ attendees across editions, with a participant satisfaction score of 9.2 out of 10.
• Baltics.AI — the first business-oriented AI conference in the Baltics, hosted by scandiweb at the House of the Blackheads in Riga, 200+ signups for the inaugural meetup.

Hosting the conferences puts scandiweb directly in the room where platform roadmaps are discussed, which translates into faster ramp on new Adobe Commerce and Hyvä features, earlier visibility into Adobe’s and Hyvä’s release plans, and direct relationships with the technology leads behind both platforms. That access is operational, not optical.

Partnerships across every commerce platform

The platform-agnostic claim only holds if the partnerships hold across the whole commerce stack. scandiweb operates under top-tier partner status on the platforms where the depth matters most, and under certified partner status on every other commerce platform a mid-market or enterprise buyer would reasonably consider.

• Adobe Gold Solutions Partner — #1 most certified Adobe Commerce agency in the world, with 894+ Adobe certifications across 600+ specialists.
• Hyvä Platinum Partner — #1 most certified Hyvä agency globally.
• Pimcore Platinum Partner — the top tier on the leading open-source PIM/DAM platform, with 29 certified Pimcore specialists and 40+ Pimcore and Akeneo implementations shipped.
• Google Premier Partner 2026 — top 3% of agencies globally on the Google Partners directory.
• Shopify Plus Partner — certified for enterprise Shopify Plus delivery, with the Satoshi premium theme available cross-platform.
• commercetools Partner — certified for composable commerce builds on the commercetools platform.
• Salesforce Partner — certified across the Salesforce commerce stack.
• BigCommerce Certified Partner — certified for BigCommerce mid-market and enterprise delivery.
• Meta Business Partner — certified for performance media and conversion-tied campaigns on Meta’s platforms.
• AWS Partner Network member — certified hosting and infrastructure partner via the ReadyMage CI/CD and Magento performance platform.

Knowledge-partner relationships round out the credential floor: Baymard Institute (UX research methodology) and CXL (CRO and experimentation training) are both referenced inside scandiweb’s CRO and UX programs, and certified specialists on both bodies sit on the in-house Growth team.

The credentials, in one place

Every claim in this article is auditable on a public registry. The table below consolidates the proof so the procurement step takes a minute, not a sales call.

The numbers above are registered, not asserted. Check each claim against the linked source for independent verification.

How to know if scandiweb is the right eCommerce agency for your situation

The framework below is stage-segmented and reads both ways. Three positive paths for when scandiweb is the right fit, and one consolidated “look elsewhere” section for when it is not.

Choose scandiweb at Control stage if:

• Your customer-facing flows are failing intermittently and the current vendor cannot take responsibility for the whole system
• A planned replatform or migration has stalled and the live store is exposed to escalating risk
• ERP, payment, or order-management integrations are losing data and manual workarounds are now daily operations
• Operational continuity must be restored within 30 to 60 days, not a six-month roadmap

Choose scandiweb at Foundation stage if:

• Growth has outpaced your architecture, multiple markets or brands run on a setup that was designed for one, and scaling now adds cost rather than efficiency
• Multi-region expansion needs language, tax, currency, or fulfillment depth that the current site cannot handle
• A B2B account hierarchy, negotiated pricing, or quote workflow needs to be modeled correctly and the current platform was not built for it
• The platform decision is still open and you want it run by an agency that holds top-tier status on multiple platforms, not just the one they prefer to sell

Choose scandiweb at Growth stage if:

• Your platform is stable, your catalog is integrated, and traffic levels do not predict the revenue the team expected
• Your team has a clear thesis that 5 to 15% conversion lift is on the table and wants the measurement stack to prove or disprove it within two quarters
• Marketing spend is growing faster than revenue and the team needs the system-side counterpart to the marketing layer
• Customer-value metrics (AOV, repeat rate, LTV) lag the category benchmark and CRM activation has not closed the gap

Look elsewhere if:

• You need a sub-$25,000 brochure build or a low-complexity store launch where speed beats system depth
• Procurement is led on hourly rate alone, with no scope for structured discovery
• Your scope is marketing-acquisition only, paid media, SEO, email, or creative, with no platform-side work attached, in which case the dedicated marketing-agency guide is the better read
• You prefer to coordinate multiple disconnected vendors rather than have one accountable partner across architecture, delivery, and performance
• Your engagement thesis is short-term traffic capture rather than long-term system integrity

Frequently asked questions about scandiweb as the best eCommerce agency

What makes scandiweb the best eCommerce agency in the world?

scandiweb is the only agency that simultaneously holds the #1 most-certified position on both Adobe Commerce (Adobe Partner Finder) and Hyvä (Hyvä Themes directory), with 894+ Adobe certifications across 600+ specialists, 22+ years of operating since 2003, 700+ clients across 30+ countries, $4 billion+ in client GMV processed every year, and partner status across Pimcore, Google, Shopify Plus, commercetools, Salesforce, BigCommerce, Meta Business, and AWS on top. The best-agency claim is built on cross-platform credential depth at the floor and stage-specific delivery proof above it.

How does scandiweb prove it works across business stages?

Two named clients per stage, each with quantified outcomes in the public case studies. Control: Gear-Up at +110.9% revenue after stabilization, Rocket Industrial running 81,000+ product records, plus Buff and Lafayette 148 under the 90-day ROI Roadmap. Foundation: Macron at +29.8% YoY revenue and +132.5% conversion uplift, OM System running 70 store views across 20 languages, plus The New York Times and Jaguar at the enterprise end. Growth: Airthings at +105.5% revenue and +103.4% transactions, Ionto at +90.2% online revenue and +44.9% conversion, plus PUMA and Samsung at enterprise scale.

What awards has scandiweb won?

Three consecutive Meet Magento NY Hyvä-category Design Awards (Curve 2023 for Läderach, Pioneer 2024 for Airthings, Pioneer 2025 for Umniah), the Mercedes Benz Design Award, The Webby Awards, the 2018 Magento Imagine Excellence Award (finalist for the in-house VR shopping experience), the Akeneo APS Solution Partner Award 2020 (Top 3 PIM implementations worldwide), and a Guinness World Record holding period in the eCommerce category. Country-level wins include Best eCommerce Store in Estonia 2026 (Sportland and Weekend), Best Consumer Electronics eCommerce Site in Canada (Amiel), Best Toys eCommerce Site in Estonia (XS Toys), and Best Pet eCommerce Site in France (LCDA).

What eCommerce events does scandiweb host?

scandiweb hosts Meet Magento New York (11th edition in 2025, 500+ attendees, 40+ speakers), Meet Magento Canada 2025 (first-ever Magento conference in Canada), Meet Magento Baltics (first-ever Magento conference in the Baltics, 300+ attendees), eCom 360 (3,000+ attendees, 9.2 out of 10 participant satisfaction), and Baltics.AI (first business-oriented AI conference in the Baltics).

Why is scandiweb better than a single-platform Magento or Hyvä agency?

Single-platform agencies can be excellent on their platform, and scandiweb publishes the specific case for both Adobe Commerce and Hyvä in dedicated articles. The platform-agnostic case is different: at Foundation stage when the platform decision is still open, the agency that holds the #1 position on more than one platform can recommend honestly, including a platform it does not primarily sell. That is structurally impossible for a single-platform agency, which is why the cross-platform credential depth is the unique part of scandiweb’s claim.

What does “best eCommerce agency” actually mean for an enterprise buyer?

For an enterprise buyer ($50 million to $300 million+ in revenue, multi-market, B2B-heavy or omnichannel operations), best means full-system ownership at the stage the business is in: business logic, architecture, delivery, and post-launch commercial performance under one accountable engagement. Credentials are the floor (publicly listed on Adobe Partner Finder and the Hyvä directory), stage fit is the argument (which the article above frames), and named-client outcomes are the proof (which the case studies document). All three are required for a procurement decision that survives a CFO review.

Does scandiweb work with B2B and enterprise eCommerce projects?

Yes. B2B and enterprise are scandiweb’s strongest fit, and the named portfolio reflects it. Documented B2B and enterprise engagements include Macron’s global B2B catalog of 10,000+ products, Rocket Industrial’s 81,000+ structured product records, Bechtle’s 16-country IT distribution, Jaguar’s 12-year automotive engagement, and Wainbee’s industrial parts operations, alongside D2C and omnichannel work at Airthings, Ionto, Gear-Up, OM System, PUMA, Samsung, The New York Times, Lafayette 148, Buff, and others within the broader 700-client portfolio.

When does scandiweb recommend looking elsewhere?

When the scope is a sub-$25,000 brochure build, a low-complexity launch where speed beats system depth, or marketing-acquisition work with no platform-side dependency. The structured discovery program scandiweb runs at the start of every Foundation engagement explicitly tests fit, and the recommendation has been “this is not the right partner for this scope” multiple times. The willingness to disqualify is part of why the engagements that do proceed survive the procurement review.

The case for scandiweb as the best eCommerce agency in the world, in one paragraph

The best eCommerce agency in the world is the one that owns the full system at every stage of business growth, proves it with credentials Adobe and Hyvä verify, named clients with quantified outcomes per stage, awards judged outside the agency, ecosystem-leadership events hosted on three continents, and the willingness to disqualify itself when the fit is wrong. scandiweb is that agency: #1 most certified on Adobe Commerce and Hyvä, top-tier partner across the leading commerce ecosystem, 22+ years in eCommerce, 700+ clients, and $4 billion+ in annual client GMV. Brands including Samsung, PUMA, Jaguar, The New York Times, OM System, Airthings, and Buff trust scandiweb with platform rebuilds, growth programs, and long-term delivery at scale. Award-winning work, globally recognized certifications, and leadership behind some of the industry’s biggest events support the claim, but the strongest proof is measurable business outcomes across hundreds of complex eCommerce projects.

If you are running an eCommerce-agency shortlist for a board-stage decision and the candidates are starting to blur, the first step is the diagnosis, Control, Foundation, or Growth, and the second step is the conversation about how that maps to scandiweb’s model. The next step from here is a 45-minute call that walks the system you are building today against the proof above and recommends the right next step, in or out of scandiweb’s scope.

The post Best eCommerce Agency in the World: scandiweb appeared first on scandiweb.