Choose an ecommerce platform by testing your own order journey: product selection, price, payment, stock, delivery and returns. Attractive design or a low subscription fee cannot compensate for a missing essential workflow. Compare platforms using the same product data and order scenario.
Describe your sales model
Direct-to-consumer sales, trade accounts with negotiated pricing and subscriptions create different requirements. List variants, customisation, products that need a quotation and actions customers must complete in their accounts. Catalogue size alone does not describe complexity. A small range with unusual pricing or fulfilment rules may require more detailed implementation than a larger standard catalogue.
Map the current operation as well. Where is product information maintained? Which system owns stock? Who changes prices and processes orders? Separate immediate requirements, reasonably expected near-term needs and ideas that have not been validated. This avoids paying for unnecessary complexity on the basis of a vague intention to scale.
Separate essential features from preferences
Mark essential payment, product-data, fulfilment and integration requirements as pass-or-fail criteria. Do not give them the same treatment as a cosmetic preference. A high design score cannot compensate for an unsupported payment or accounting workflow your business needs. Ask whether support comes from a built-in capability, an additional application or custom development.
For cross-border selling, consider language, currency and operations together. A translated interface does not mean delivery and customer support are ready for every market. Verify market-specific requirements with the relevant providers and specialists. Avoid treating a platform name as evidence that the entire international operating model is covered.
| Decision area | Scenario to demonstrate | What the proposal should clarify |
|---|---|---|
| Product model | Create a product with real options | Data limits and administration |
| Payments | Successful, failed and refunded order | Provider, connection and ownership |
| Inventory | Stock changes across two channels | Source of truth and synchronisation |
| Delivery | Different regions and parcel rules | Supported rules and exceptions |
| Development | Add a new business rule | Scope, maintenance and ownership |
Compare operating costs as well as setup
Implementation is only part of the commercial picture. Ask about subscriptions or hosting, themes, applications, integrations, content entry, training, maintenance and change requests. Identify the items that could become more expensive as usage increases. Compare proposals over the same evaluation period and against the same scope.
Operational effort also has a cost. If creating a campaign, changing a page or managing a product requires development support, the business must be prepared for that dependency. There is no universal winner between a more managed service and a setup offering greater control.
The relevant question is how much flexibility you need and whether you have the capacity to maintain it.
Try a difficult order in the demo
Illustrative test: use a product with size and colour options. When a selection changes, do price, stock and delivery information update correctly? Change the basket quantity, enter a different shipping area and try your required payment method in the provider’s test environment.
Find the same order in the administration area. Check the stock movement, customer notification and cancellation or refund steps. Do not mark a feature as complete because somebody says it can be added later. Include any required app, development and maintenance in the comparison.
- The selected variant matches the price.
- Unavailable combinations behave correctly.
- Delivery conditions are clear for the selected area.
- Successful and failed test payments are handled correctly.
- The order, cancellation and refund can be followed in administration.
Plan data and URLs for a migration
Migration includes more than uploading products to a new admin panel. Inventory existing pages, product relationships, relevant customer and order records, and external links. Confirm which data can move and by what method. Map old URLs to appropriate replacements based on the actual content.
Sending every old address to the homepage does not help a customer find the product they intended to view.
Shopify's official migration guidance includes checking imported data, configuring payment and delivery, and placing test orders. Whatever platform you choose, validate successful and failed payments, cancellation, refunds and fulfilment within your own workflow. Review the customer notifications generated by these actions as part of acceptance.
Verify the choice before committing
Document the selected option, why alternatives were rejected and which uncertainties remain. Do not treat an unproven feature as delivered. Assign ownership for development, migration, testing, content and operational training. Set the launch date alongside the conditions those workstreams need to meet.
After selection, success should mean more than the site becoming publicly available. The team must be able to manage products and orders, customers must be able to complete tasks, and support responsibilities must be clear when something fails. A suitable platform supports the business's present operations while providing an understandable basis for future development.
- Essential workflows have been demonstrated with realistic examples.
- Additional applications and custom work are listed in writing.
- Data, URL and integration responsibilities are assigned.
- Testing and acceptance criteria are included in scope.
- Training and post-launch support arrangements are clear.