Development Agency
Contact Sign in Get a project quote

Service

Online shop development

For retailers and brands selling direct who need a shop designed around their own catalogue structure, stock locations, fulfilment process and stores, rather than a hosted template with the awkward parts worked around in plugins.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A retailer with a few hundred products and two physical shops usually sells online through a hosted platform chosen years ago.

  • The catalogue was entered quickly, so a jumper that comes in six colours and five sizes exists as thirty separate products with their own stock counts, and the size guide lives in a PDF nobody updates.
  • Stock is counted in the till system at each shop and again in the online platform, and the three numbers drift apart every week.
  • A customer orders the last pair of boots online at nine in the morning; a shop assistant sells the same pair across the counter at eleven; the warehouse discovers the gap on Tuesday and sends an apology.

Where it gets harder

Orders are printed, picked from a paper list and booked with the carrier by retyping the address into the carrier portal.

  • Returns arrive with a handwritten note and are refunded whenever someone remembers to look at the pile.
  • Promotions are set up by hand the night before and sometimes forgotten the morning after.
  • The owner wants to offer click-and-collect from the shops and sell through shopping channels, but the platform cannot see shop stock and the product feed rejects half the catalogue for missing attributes.
  • Every workaround adds a plugin, and the monthly bill grows while the shop slows down.

Scope of the service

What the build covers

A custom online shop build normally covers the catalogue, stock, selling and fulfilment core. The catalogue carries products with variants built from attributes you define, such as size, colour and material, with images, size guides and related products per variant family. Stock is held per variant and per location, so a shop, a warehouse and a supplier drop-ship line each have their own count, with rules for which locations feed online sales and which reserve for the counter. The storefront covers category browsing, search and filters, bundles, wish lists and reviews. Checkout connects to a payment provider through our provider-independent payment layer, with shipping methods and zones, discount codes, gift wrapping and configurable VAT rules applied per line. Fulfilment covers pick lists, carrier label creation through the carrier you use, shipment tracking, click-and-collect with a ready-for-collection step, returns with reasons and refunds against the original payment, and customer accounts with order history. Abandoned-basket emails, stock alerts and a product feed for shopping channels round it off.

We walk through a real week in your shop first: how a new line is set up, how stock arrives and is counted, who picks and packs, how returns are handled and where the till and the website disagree. Each of those becomes a named workflow stage in the scope document.

Deliberately out of scope

  • Your accounting, purchasing from suppliers beyond recording goods in, and the physical till itself, which we connect to rather than replace

When the scope grows

Scoping scenario

A homeware brand with a warehouse, three shops and a drop-ship supplier wants online stock to draw from the warehouse first, then from any shop with more than a set minimum, with click-and-collect only where the shop actually holds the item and drop-ship lines shown with their own delivery estimate. The location rules and the drop-ship split make this a custom build, and the scope document says so plainly.

Deliverables

What you receive

  • Discovery notes from walking through your catalogue setup, stock counts, picking and returns
  • A written scope document naming each workflow stage, the stock location rules and what is left out
  • Designs of the product page, checkout, the order and fulfilment screens and the returns flow on mobile and desktop
  • The build, deployed to your hosting or ours, with the payment provider and carrier connected
  • Migration of products, variants, customers and order history from your current platform
  • Training for the shop manager, warehouse and customer service, 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 your current platform, till exports, carrier and payment accounts; a look at the catalogue and how stock is counted today.

    Project stage: Onboarding

  2. Planning

    Discovery with the owner, the shop manager and whoever picks orders; the variant model, stock location rules and fulfilment stages are written into the scope document.

    Project stage: Planning

  3. Design

    Product page, category, basket and checkout designed on the phones your customers use; order, picking and returns screens designed for the warehouse.

    Project stage: Design

  4. Development

    Built in layers: catalogue and stock first, then storefront and checkout, then fulfilment, returns and the channel feed.

    Project stage: Development

  5. Client review

    Your team places, picks, ships and returns test orders with the payment provider in test mode and tells us where the flow does not match the shop floor.

    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

    Catalogue and customers migrated, stock reconciled against a fresh count, payment and carrier verified against live accounts you 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 and wallet payment providers through the provider-independent payment layer
  • Parcel carriers for label creation, tracking and collection bookings
  • Till and point-of-sale systems for shop stock and counter sales
  • Shopping channel and marketplace product feeds in the format each channel specifies
  • Email providers for order notifications and abandoned-basket recovery
  • Accounting software for sales, refunds and payment provider settlement
  • Product review platforms where you already collect reviews

How we would approach it

Worked example

Concept demo

A homeware brand with a warehouse, three shops and a drop-ship supplier

The situation

A homeware brand wants online stock to be drawn from its warehouse first, then from any of its three shops that holds more than a minimum it sets per product, while a range of large furniture is shipped directly by a supplier with a longer delivery estimate.

Why it is a custom build

The custom route is needed because of the location priority rules and the split between warehouse, shop and supplier fulfilment, which go beyond the single-stock-pool model most hosted platforms assume.

The scope we would propose

  • Stock per variant per location with a priority order and a per-product counter reserve
  • An allocation step at order time that picks the fulfilling location and raises a pick list there, click-and-collect offered only from shops where the item is physically in stock, drop-ship lines split into their own shipment with the supplier notified and the delivery estimate shown on the product page
  • A nightly reconciliation report listing where the till count and the shop count disagree

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

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

  • Number of products and the depth of the variant and attribute model
  • Stock locations and whether a till or warehouse system must be kept in step
  • Payment provider and the payment methods required at checkout
  • Carriers, shipping zones and whether labels are created inside the system
  • Click-and-collect, drop-ship or split-shipment rules
  • Channel feeds and review platforms to connect
  • Volume and quality of products, customers and order history to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Online shop package

Catalogue with variants, stock per location, checkout through a payment provider, fulfilment with carrier labels, returns, click-and-collect and customer accounts for retailers and brands.

Custom build
View the package

FAQ

Frequently asked questions

When is the package enough and when do we need a custom build?

If a single stock pool or straightforward per-location stock, standard checkout and one carrier cover your shop, the online shop package is the right fit and we quote for that. Location priority rules, split shipments between warehouse, shop and supplier, or a till that must stay in step in real time point to the custom route.

Can you move our shop from a hosted platform?

Usually yes. Products, variants, images, customers and order history are exported from your current platform, mapped into the new catalogue and imported, with redirects from every old product and category URL so search rankings and bookmarks keep working. The scope document states what can be carried over once we have seen the export.

How is VAT handled?

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

Which payment providers and carriers can be connected?

Checkout runs through a provider-independent payment layer, so the card or wallet provider is chosen with you in the proposal and can be changed later. Carriers are connected through the interfaces they publish for label creation and tracking, and the scope document names the ones in scope.

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 online shop 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 Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences