E-commerce solutions
E-commerce development
A shop differs from a website not in its design but in the fact that the money and goods passing through it have to agree with your accounting, your stock and your courier. So the decision is almost never "which platform" first — you need to know how many products and variants there will be, who updates stock, what a return looks like and who issues the invoice. Only then does platform choice become a technical question rather than an assumption.
Discuss a shop scopeIn short: what decides it
Four things decide almost everything. Catalogue complexity — how many variants, sizes and pricing rules. Operations — who updates stock and whether there is a single source for it. The money path — payment methods, invoicing, VAT and returns. And your existing systems: if you already run accounting or warehouse software, that usually sets the limits. Starting from a platform name is the most common mistake.
When building a shop is justified
- Selling online is a distinct sales channel rather than information about what you stock.
- The catalogue has variants, pricing rules or bundles that a simple form cannot express.
- Stock and invoices live in another system, so the data has to agree without manual re-entry.
- Returns and refunds need to be handled as a defined process rather than case by case.
When something simpler is enough
- There are only a few products, sold rarely — a website with an enquiry form or an invoice on agreement may be enough.
- You sell through an existing marketplace and that works — then the website is needed for information and trust only.
- You want to test demand before investing — one clear landing section fits better than a full catalogue.
Platform routes and their limits
Below is an illustrative comparison of platform routes, to help you prepare for a conversation. It is not a price list and not a recommendation for a specific case: the route follows the catalogue, the operations and the systems already in use. The third column lists cost and risk factors rather than amounts.
| Platform route | What it usually suits | Limits and cost factors |
|---|---|---|
| Content system with a commerce module | A small or medium catalogue where content matters as much as selling. | Extra modules accumulate with requirements; each brings its own update and compatibility work. |
| Dedicated commerce platform | A more complex catalogue with variants, pricing rules and several languages. | More capability out of the box, but also more settings that have to be understood and maintained. |
| Hosted (SaaS) platform | When you want to start quickly and accept a standard workflow. | A monthly fee and the platform’s own limits; customisation only as far as the vendor allows. |
| Custom build | Unusual pricing, configurators, or selling that is part of the system itself. | The most freedom and the largest ongoing commitment — everything is yours to maintain. |
| Migration from an existing shop | The shop already runs, but the platform no longer fits the requirements. | Scope is driven by data quality and preserving URLs, not by new features. |
How the work runs
- 01
Catalogue and operations
First we describe what is sold and how it looks as data: variants, units, pricing rules, the source of stock figures. Alongside that we establish who does what daily — takes the order, prepares the shipment, handles the return. No platform is chosen yet.
- 02
Choosing the platform route
With the catalogue and operations in hand, the routes are compared against the same criteria and the reason for the chosen one is written down. Recording the reasoning means the decision can be revisited when requirements change, instead of starting over.
- 03
The money and delivery path
Payments, delivery methods and invoicing are connected, and what happens on failure is described with them: a declined payment, a partial refund, a cancelled shipment. These cases are defined before launch, because afterwards they become customer-service work.
- 04
Launch checks and handover
Before launch the whole path from product to return is walked through, and URLs and redirects are verified if the shop is being migrated. Platform, payment and account access is transferred in your name, so the shop does not depend on its supplier.
What drives cost and duration
- The number of products and variants, and how unusual the pricing rules are — atypicality matters more than catalogue size.
- The number of integrations: accounting, warehouse, couriers, payments — each boundary has its own failure cases.
- Whether data is migrated from an existing shop, and what condition it is in.
- The number of languages and markets, because that changes tax and shipping rules as well as text.
- How much of the operation stays manual — usually only visible once the daily flow is written down.
Worth considering before we talk
- 01How many products and variants will there be at the start, and who will maintain them?
- 02Which system is the source of truth for stock and prices, if there is more than one?
- 03What does a return look like, and who carries it out day to day?
- 04Who issues invoices, and how must that reach your accounting?
- 05If the shop already runs — which URLs must be preserved?
Let us scope the shop
A note about what you sell, roughly how many products, and which systems you already run is enough. Please do not send logins or real customer data — a general description is a fine starting point.