Service

E-commerce Development

For businesses selling online whose catalogue, pricing, customers or fulfilment do not fit a hosted shop template, whether they sell to consumers, to trade accounts, by subscription or as downloads.

The problem

What goes wrong today

Where it usually starts

Businesses asking for e-commerce development are rarely starting from nothing.

  • They have a hosted shop or a shop plugin that was fine for the first hundred products and is now held together by paid extensions, each with its own settings page and its own idea of what a product is.
  • Trade customers are served by email and a price list in a PDF because the shop cannot show different prices to different accounts.
  • The subscription line runs through a separate service with its own customer records, so the same person has two logins and support cannot see both.
  • Stock is corrected by hand after every busy weekend because the warehouse system and the shop disagree.

Where it gets harder

Payment fees crept up when the platform tied checkout to its own provider, and moving away would mean rebuilding everything.

  • Promotions take an evening to set up and still misfire on bundles.
  • The product feed to shopping channels rejects half the catalogue for missing attributes nobody knew were required.
  • The owner can list exactly what the shop should do, because the business has been doing it by hand for years; what they lack is a shop designed around their catalogue, their customers and their fulfilment rather than the other way round.

Scope of the service

What the build covers

An e-commerce build normally covers the catalogue, pricing, checkout, fulfilment and customer core, with the shape of each decided by what you sell and to whom. Consumer shops need variants, stock per location, search and filters, baskets, discount rules and returns. Wholesale portals add trade accounts with approval, account-specific price lists, minimum quantities, credit terms, repeat orders and invoicing. Subscription commerce adds plans, renewal dates, skips and pauses, failed payment handling and the operational side of recurring fulfilment. Digital products add licences, download limits and delivery without stock. All of them share checkout through our provider-independent payment layer, so the card, wallet or direct debit provider is chosen with you and can change later, with webhooks verified and nothing marked paid from a browser redirect. Tax is configurable rules applied per line, never advice.

Fulfilment covers pick lists, carrier labels, tracking, click-and-collect and returns with refunds to the original payment. Customer accounts, order history, notifications and a product feed for channels complete the core.

When the scope grows

Scoping scenario

A specialist food producer sells to consumers, supplies forty trade accounts on monthly terms and runs a subscription box, all currently on three separate systems with three customer lists. The scope we would propose merges them into one catalogue and one customer record with three selling modes, and the scope document names which fulfilment stages, price rules and migration steps are included.

Deliberately out of scope

  • Your accounting beyond the connection to it, purchasing from suppliers, the physical till, and marketplace selling on third-party platforms beyond the product feed, each of which we connect to rather than replace

Deliverables

What you receive

  • Discovery notes from walking through how products are set up, priced, ordered, picked, shipped and returned today
  • A written scope document naming the selling modes, price rules, fulfilment stages and what is left out
  • Designs of the product page, basket and checkout for each customer type, and the order and fulfilment screens, on mobile and desktop
  • The build, deployed to your hosting or ours, with the payment provider and carriers connected and tested
  • Migration of products, variants, customers, accounts, subscriptions and order history from your current platforms
  • Training for shop, warehouse and customer service staff, with a short written guide
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current shop, subscription and trade systems, payment and carrier accounts; exports of catalogue, customers and orders.

    Project stage: Onboarding
  2. Planning

    Discovery with the owner, whoever manages trade accounts and whoever picks orders; selling modes, price rules and stages are written into the scope document.

    Project stage: Planning
  3. Design

    Product, basket and checkout designed on the phones your customers use, trade and subscription account areas for their users, fulfilment screens for the warehouse.

    Project stage: Design
  4. Development

    Catalogue and pricing first, then checkout and the payment layer, then fulfilment, accounts, subscriptions and feeds.

    Project stage: Development
  5. Client review

    Your team places, picks, ships, renews and returns test orders of each type with the payment provider in test mode.

    Project stage: Client review
  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions
  7. Ready for launch

    Data migrated and stock reconciled, live payment and carrier accounts verified under your control, redirects from old URLs in place.

    Project stage: Ready for launch
  8. Delivered

    Orders flow through the new shop; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card, wallet and direct debit payment providers through the provider-independent payment layer
  • Parcel carriers for labels, tracking and collection bookings
  • Warehouse, till and point-of-sale systems for stock and counter sales
  • Accounting software for sales, refunds, credit terms and settlement
  • Email and SMS providers for order, renewal and abandoned-basket messages
  • Shopping channel and marketplace product feeds
  • Review platforms and loyalty schemes you already use

How we would approach it

Worked example

Concept demo

A food producer selling to consumers, trade accounts and subscribers from one catalogue

The situation

A specialist food producer runs a consumer shop, supplies forty trade customers on monthly terms through emailed price lists, and ships a subscription box through a separate service, with three customer lists that never agree.

Why it is a custom build

The custom route is needed because the three selling modes share one catalogue, one stock picture and one customer record, which hosted shop platforms and their extensions keep apart.

The scope we would propose

  • One catalogue with variants and stock per location
  • A consumer checkout
  • Trade accounts with approval, account price lists, minimum quantities and monthly invoicing
  • Subscription plans with renewal dates, skips and failed payment handling
  • A single customer record across all three
  • Fulfilment with pick lists grouped by despatch day and carrier labels
  • Migration of the three customer lists with duplicates matched and confirmed

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Selling modes in scope: consumer, trade, subscription, digital or a combination
  • Catalogue size and the depth of the variant and attribute model
  • Price rules: account lists, quantity breaks, promotions, bundles and tax configuration
  • Stock locations and whether a warehouse or till system must be kept in step
  • Payment methods required and the carriers to connect
  • Returns, refunds, credit terms and invoicing requirements
  • Volume and quality of catalogue, customer, subscription and order data to migrate
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

Which of your packages is the right starting point?

It depends on who you sell to. The online shop package covers consumer retail with variants, stock and fulfilment; the wholesale ordering package covers trade accounts, price lists and credit terms; the subscription box package covers recurring orders. When a business needs two or three of these on one catalogue and one customer record, this service is the route, and the proposal says so.

Can we keep or change our payment provider?

Checkout runs through a provider-independent payment layer, so the provider is a choice made with you in the proposal and can be changed later without rebuilding the shop. Webhooks are verified and de-duplicated, and an order is never marked paid from the browser return page.

How is VAT handled?

Through tax rules you configure per product category, customer type and destination, applied at checkout and shown on invoices. The system applies the rules you set; which rate applies to which product remains a matter for you and your accountant.

Can you move our shop from a hosted platform?

Usually yes. Products, variants, images, customers, subscriptions and order history are exported, mapped and imported, with a redirect from every old product and category URL so bookmarks and links keep working. The scope document states what can be carried over once we have seen the export.

Who owns the shop afterwards?

You do. The source code, catalogue, customers and orders are handed over at delivery. Hosting and maintenance are optional and agreed separately, and the shop can be moved to another provider.

Get a project quote for e-commerce development software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote