Aurora Creation
PLEN

A D2C implementation on Shopify for manufacturers and private-label brands

We design and build D2C stores on Shopify that join the shopping experience to the catalogue, the integrations, analytics and order-handling processes.

The project starts from the sales model, not from a list of features. We establish how the product reaches the customer, what happens to an order after checkout and which of the company's systems have to exchange data with the store.

Let's discuss a D2C implementationCheck whether Shopify fits your model
  • Store UX and design
  • Shopify and feature development
  • Integrations and data
  • QA and launch
ManufacturerShopify storeShipmentCustomer

D2C on Shopify — how does it differ from ordinary B2C?

D2C (direct-to-consumer) is the sales model in which a manufacturer or a brand sells straight to the end customer, with no traditional distributor or retail network in between.

An ordinary B2C store also sells to a consumer, but it usually does so as a retailer of someone else's products: it buys the goods, resells them and earns the margin. In D2C the store belongs to the owner of the product, so along with the channel the company takes over the price, the product content, the service and everything the channel knows about the customer.

Aurora Creation builds D2C stores on Shopify for manufacturers and brands that want to grow a direct online sales channel of their own. The scope of the project follows from what that channel changes inside the company — and it changes more than the mere presence of the products online.

What a channel of your own changes

  • Sales

    The company sets the offer, the prices, the promotions and the return rules itself, and answers for the channel's result itself. There is no intermediary carrying part of the risk — and none taking part of the margin.

  • Marketing

    Traffic to the store has to be built in-house: through content, visibility in search, campaigns and returning customers. In distribution the retailer looked after the product's exposure; in a direct channel the brand does.

  • Customer data

    Direct sales give access to what distribution does not hand over: who buys, how they reach the product and what they buy again. So where that data goes, who manages it and on what consent has to be settled from the start.

  • Logistics

    Instead of a pallet to a distributor, the company ships single parcels to consumers — with its own packaging, couriers, parcel tracking and returns handling. That is usually the largest operational change in the whole project.

  • The relationship with distributors

    The new channel stands beside an existing sales network, so prices, promotions and product availability need one shared policy. Channel conflict is settled in commercial policy; the store configuration only mirrors it.

A manufacturer that already has a sales network starts from the question of what the new channel does to the existing one. The rules that have to be settled then are gathered in the section on the other sales channels.

How do you combine D2C with distributors, marketplaces and other channels?

A brand's own store is rarely the only place the product can be bought. Distributors, retail networks and marketplaces stay alongside it, and every one of those channels sells from the same offer and the same warehouse.

Channel conflict does not come from the mere existence of a manufacturer's store. It comes when the distributor learns from their own customer that the brand sells cheaper or faster. That is why the eight decisions below are taken before Shopify is configured — they are commercial policy, and the store only mirrors them.

Settled before the store is configured

  • Pricing policy

    The brand's store either holds the recommended price or goes below it. Most often D2C stays at the list price, and the channel's advantage is the complete range, availability and service rather than a discount.

  • Promotions and sales

    The campaign calendar covers both channels or only one. If a promotion is for the brand's store only, the distributor should know about it in advance — that is usually cheaper than explaining it afterwards.

  • Product availability

    Not every product has to go into both channels. Personalisation, bundles and limited editions are often D2C exclusives while volume stays with distribution — the channels are then not selling the same thing and the conflict largely disappears.

  • Product data

    Descriptions, attributes, photographs and translations should have one source that the store, the marketplaces, the distributor and the offline catalogue all draw on. If that source is a spreadsheet, each channel ends up describing the same product differently.

  • Stock levels

    The D2C store sells from the same stock pool as distribution or from a separate one. That decides which channel wins when stock runs low, and it has to be reflected in the ERP or WMS integration together with the update frequency.

  • Order fulfilment

    A consumer order is packed and shipped by someone other than whoever loads a pallet for a distributor. We establish who ships, which warehouse the goods leave from, how returns come back and which system holds the order status.

  • Marketplaces

    Allegro, Amazon and price comparison sites are a sales channel, not the brand's own storefront. Which products go into the listing, who is the source of the price and the stock level, and where the orders land all have to be settled, so the same product does not exist in three versions.

  • The terms of working with distributors

    Some of this is not store configuration but a document: who sells in which market, whether a partner may advertise on the brand name, and how the brand supports sales at the distributor. The store will not invent those rules — it can only carry them out.

These decisions are recorded together with the sales model during discovery, and the configuration of prices, stock and integrations follows from them. If the distributors are to buy in the same store, the scope is described by a B2C + B2B implementation on Shopify.

When should you choose an individual D2C implementation on Shopify?

An individual implementation makes sense once a standard scope stops being enough. This path is for companies that treat D2C as a significant sales channel and need a store fitted to their own product, brand and operational back office.

  1. 01

    The brand needs its own shopping experience

    An off-the-shelf layout is not enough to present the product, its variants, materials, how it is used or how collections differ. The project needs its own information architecture, wireframes and visual layer.

  2. 02

    The store has to exchange data with company systems

    Prices, products, stock, orders, customers or documents have to flow between Shopify and an ERP, PIM, WMS, CRM, fulfilment provider or other tools.

  3. 03

    Sales cover more than one market

    The project has to account for languages, currencies, payments, shipping, local content and how the offer is managed. What is available depends on the Shopify plan, the countries sold to and the payment configuration.

  4. 04

    The team needs a partner running the whole project

    The company does not have the resources to coordinate UX, development, integrations, analytics, testing and launch on its own.

Compare this service with AURORA SHOPI

Shortcuts taken during implementation come back as manual work

A store can look finished and still create problems in the warehouse, in marketing, in accounting or in customer service. That usually happens when features are chosen before the sales process has been sorted out.

The scope is built from how the product reaches the customer and what happens to an order after checkout. The four decisions below are the ones most often taken too early.

  • The catalogue structure was copied from the ERP

    What follows later

    Customers struggle to find a product and marketing cannot build collections and campaign pages comfortably.

  • Every need was solved with a separate app

    What follows later

    Subscriptions, dependencies and the risk of conflicts during updates all grow.

  • Integration was left until the end

    What follows later

    The team moves data by hand and discovers what is missing just before launch.

  • The design was made without the promotion, shipping and variant rules

    What follows later

    Finished views have to be rebuilt once development has started.

Each of these situations can be caught before development begins. It takes describing the sales process, the data sources and the purchase rules before the first store view is designed.

The scope starts at the sales process and ends at a working flow of data

The implementation covers the layer the customer sees and the way the company manages products, orders, payments, shipping, returns and reporting.

Areas of the implementation

  1. 01

    Sales model and requirements

    We establish the markets, customer groups, the structure of the offer, product variants, promotions, shipping, payments, returns and which teams are responsible on the company's side.

  2. 02

    Information architecture and UX

    We design the navigation, search, listings, product pages, cart, customer account and the paths that lead to a purchase.

  3. 03

    UI design

    The visual layer follows from the brand identity and the nature of the product. It produces desktop and mobile views, error states, forms and the components needed during implementation.

  4. 04

    Shopify configuration and development

    We configure the store, the theme, collections, templates, sales settings and the features defined during the analysis. Custom solutions are used where the Shopify standard or an app does not support the required process.

  5. 05

    Integrations

    We connect Shopify to the systems responsible for product data, prices, the warehouse, order fulfilment, customers, marketing and reporting.

  6. 06

    Analytics and consent

    The project accounts for how sales are measured, e‑commerce events, campaign tagging and the consent management mechanism.

  7. 07

    Testing and launch

    We check the views, devices, sales rules, payments, shipping, integrations and data. The launch runs against a prepared checklist.

If product data is scattered across spreadsheets, the ERP and marketing catalogues, it is worth checking before the implementation whether its source should become Pimcore. A store is not a good place to tidy up descriptions and attributes that offline sales and a printed catalogue also rely on.

Let's discuss the scope of your implementation

An order should pass through the systems without being retyped

Connecting two APIs does not close the subject of integration. The owner of the data, the direction of synchronisation, the update frequency, the reaction to an error and the way information is reprocessed all have to be agreed.

Company systemsChannels and data recipientsERPtwo-wayprices, stockorders, invoicesPIMinto Shopifyproducts, descriptionsattributes, translationsWMS and fulfilmenttwo-waystock, shipmentsfulfilment statusesCRMtwo-waycustomers, consentscontact historyShopifysales layerPayments and couriersauthorisations, labelsparcel trackingMarketplaceslistings, stockordersMarketing automationpurchase eventssegmentsAnalytics and reportinge‑commerce events, campaignssales

Company systems

  • ERPtwo-way

    prices, stock, orders, invoices

  • PIMinto Shopify

    products, descriptions, attributes, translations

  • WMS and fulfilmenttwo-way

    stock, shipments, fulfilment statuses

  • CRMtwo-way

    customers, consents, contact history

Shopifysales layer

Channels and data recipients

  • Payments and couriersout of Shopify

    authorisations, labels, parcel tracking

  • Marketplacesout of Shopify

    listings, stock, orders

  • Marketing automationout of Shopify

    purchase events, segments

  • Analytics and reportingout of Shopify

    e‑commerce events, campaigns, sales

The final set of systems, the directions and the data scope are established during discovery.

  • An app or a custom integration

    During the analysis we check which processes the Shopify standard handles, where an off-the-shelf app is enough and where an integration built for the specific model is needed. An app is often the fastest route, but not always the cheapest over several years.

  • The cost and dependencies of apps

    Every app is assessed for its subscription cost, its effect on store performance, the access it gives to data and the dependency it creates on an outside vendor. A set of a dozen apps can cost more than one integration maintained in-house.

  • Data ownership and the direction of synchronisation

    For each type of data we establish one source system. Without it the same price or stock level is overwritten in both directions, and the discrepancy only surfaces during a complaint.

  • Error handling and reprocessing

    An integration needs a defined reaction to a missing response, a rejected record and a duplicate. We agree who sees the error, where the information about it goes and how the data is processed again.

Let's discuss the integrations

The schedule is set once the scope and the dependencies are known

The number of products, markets and integrations, the quality of the data and the scope of the design affect a project more than the number of store pages does.

Every stage ends with a decision or with material to accept, so the company knows what it is approving and what happens next.

  1. 01

    Qualification

    We talk about the sales model, the offer, the markets, the current technology stack and the expectations of Shopify. This stage can end with a recommendation of a different service or platform.

    Resulta decision on going further with the analysis

  2. 02

    Discovery and architecture

    We describe the processes, the users, the catalogue, the systems, the integrations, the sales rules and who is responsible on each team.

    Resultthe scope, a dependency map and the technical assumptions

  3. 03

    UX, content and UI

    The information architecture, wireframes, components, mobile views and the visual design are produced.

    Resultan accepted interface design

  4. 04

    Configuration and development

    We configure Shopify, implement the theme, develop the agreed features and prepare the integrations.

    Resulta working test version

  5. 05

    Data and testing

    We import or prepare the data needed for launch. We check the purchase rules, payments, shipping, the views and the flow of information between systems.

    Resultan accepted launch plan

  6. 06

    Launch and stabilisation

    We launch the store against a checklist. After go-live we monitor tickets, errors and the data needed for further development.

    Resultthe store handed over to operational work

Let's discuss how your project would run

The process shows who answers for the decisions, the quality and the launch

Every area of the project should have an owner, acceptance criteria and an agreed way of raising changes. That is what keeps the effect of new ideas on the budget and the schedule under control.

  1. 01

    Running the project

    The project has a permanent Project Manager, a backlog and a work status the client can see, plus an agreed rhythm of meetings and updates.

  2. 02

    Estimates and scope changes

    Estimates are built on a described scope. Every change is priced and accepted before it is implemented, so the effect of a new idea on the deadline is visible immediately.

  3. 03

    Code quality and testing

    Changes go through code review and QA on Aurora Creation's side. Acceptance testing on the client's side happens before launch.

  4. 04

    Launch and hand-over

    The production deployment follows a plan and a checklist. The client receives documentation of the solution and access to the code, the configuration and the accounts needed for further work.

What the project leaves behind

  • the accepted scope and assumptions
  • the solution architecture
  • a description of the data flow
  • a list of apps and dependencies
  • test scenarios
  • launch instructions
  • a list of access rights and account owners
  • a backlog for further development
Book a technical call

After launch the store moves into maintenance and growth

The first weeks make it possible to check user behaviour, how the integrations work and the problems that show up in order handling. What is gathered goes into a backlog of fixes and further development.

Stabilisation is part of the implementation. Once it is over the store can move into ongoing support, whose scope and terms are described on a separate page.

See Shopify maintenance

Scope of the engagement after go-live

  • stabilisation after launch
  • fixes and updates
  • feature development from the backlog
  • QA of subsequent changes
  • monitoring and ticket handling

D2C on Shopify in practice — Słodka Manufaktura

The Słodka Manufaktura online store on Shopify

A direct sales channel of its own

Słodka Manufaktura

The patisserie sold mostly on site and took cake orders in conversation and in messages. Its store on Shopify became its first online channel of its own: the customer picks the product, configures the cake, sees the price that follows from the parameters they set and places the order without contacting anyone. The loyalty programme came to cover both channels at the same time — purchases online and at the patisserie.

  • a move from mostly on-site sales to an online channel of its own,
  • a cake configurator that walks the customer through the parameters,
  • automatic calculation of the order price,
  • a loyalty programme joining online and in-store purchases,
  • customers placing their orders themselves.
See the D2C on Shopify case study for Słodka Manufaktura

Questions before a D2C implementation on Shopify

The answers cover the sales model, scope, cost, integrations, markets and the other channels. The details for a specific project are established during discovery.

Let's discuss your sales model

B2C describes selling to a consumer regardless of who runs the store — including a retailer reselling someone else's products. D2C narrows that to the case where the store belongs to the manufacturer or the owner of the brand, so along with the channel the company takes over the price, the product content, the service and the customer data. Technically both stores can run on the same Shopify; the difference is in the sales model and in who answers for the channel.

The service is for manufacturers and private-label brands that want to launch a new direct sales channel. It usually concerns projects that need their own UX, integrations, several markets or features beyond the standard scope of AURORA SHOPI.

AURORA SHOPI has a defined scope and is built for a simpler starting model. A D2C implementation is priced after an analysis and can cover its own UX, UI design, integrations, custom solutions and a multi-market configuration.

An individual implementation has no list price — the estimate is produced after an analysis. The cost is driven by the number of products and variants, the number of markets, the scope of the design, the number and complexity of the integrations, the quality of the data and any features beyond the Shopify standard. If a fixed price known upfront is needed, the point of reference is AURORA SHOPI, with a fixed scope on one market.

We do not give a date before the scope is settled. The schedule is driven by the number of markets, the scope of the design, the number of integrations and the quality of the data, not by the number of store pages. A build with a fixed scope, one market and no integrations fits into AURORA SHOPI in 30 days; an individual project takes longer, and its stages and their results are set out in the schedule after discovery.

The estimate is produced once the catalogue, markets, integrations, data, design and features are settled. The client should receive the scope, the assumptions, the dependencies, the estimate and a plan of stages. Giving a date before the analysis increases the risk of later changes.

Yes, and that is how most manufacturers launching a store of their own operate. It takes one shared policy on prices, promotions and product availability, plus a decision on which stock pool the store sells from. Those decisions are taken before Shopify is configured — they are gathered in the section on the other sales channels.

Yes, that scope can be part of the project. The available languages, currencies, payment methods, taxes and the way markets are managed depend on the Shopify plan, the company's country and the providers used — the rules are described in the Shopify Markets documentation. We check those dependencies during discovery.

Yes, and beyond those the scope can cover CRM, fulfilment, payments, couriers, marketplaces, marketing automation and analytics. For each system we establish which one is the source of a given type of data, the direction of synchronisation, how often it runs and what happens to a rejected record. If product descriptions and attributes are to feed other channels as well, their source can become Pimcore.

Yes. Allegro, Amazon and price comparison sites are connected either through apps or through an integration built for the specific model — depending on how many rules have to run on the way. Before the build we establish which products go into the listing, who is the source of the price and the stock level, and where the orders land.

Yes. The scope can cover information architecture, wireframes, the desktop and mobile interface design, a component library and the views needed for implementation. How far it is customised depends on the project.

Store views are designed freely, but the Shopify checkout itself is modified through the checkout extensions mechanism, and what can be changed depends on the plan. The same applies to the new customer accounts with passwordless login and self-service returns. That is why we do not promise an arbitrary rebuild of the checkout before the configuration has been verified.

After go-live the store goes through a period of stabilisation. Tickets, data and the team's observations go into the backlog. Further work can continue under the Shopify maintenance service.

We consider a different platform when the model calls for a large number of non-standard rules, deep changes to the sales process or an architecture that would need many workarounds and apps to maintain on Shopify. That decision follows an analysis of the processes and the total cost of the solution — the usual point of reference is Magento 2.

Let's first establish what D2C store actually has to be built

We will go through the sales model, the offer, the markets, the integrations and the expectations of the design. On that basis we can point to the right path and the scope needed to prepare an estimate.

Małgorzata Gudalewska, Head of Sales at Aurora Creation

Małgorzata Gudalewska

Head of Sales

+48 664 531 867[email protected]
[email protected]ul. Jana Henryka Dąbrowskiego 28, 15-872 Białystok, Poland

Worth having for the first call

  • a rough number of products and variants
  • the markets you plan to sell in
  • the names of the systems the store has to connect to
  • who manages the product data
  • the date the store should go live
See all Shopify services
No files chosen
Thank you, we'll get back to you within 1 business day.

You do not need a finished brief before the first call. Documentation, data exports and descriptions of non-standard processes can follow later.