Cloud platform: a store within predefined rules
In the cloud model, the store runs in the supplier’s service. For example, inSales describes its CMS as a system with a storefront, products, orders, payments, delivery and integrations. On the same page, the company describes a visual editor and design changes through HTML and CSS.
This gives an owner a useful starting point: working screens and store settings can be assessed directly. Changing the appearance, however, does not establish how deeply order calculations, inventory allocation or discount rules can be changed. Those parts need separate checks against the chosen platform’s and applications’ documentation.
Consider a cloud option when essential processes fit the available mechanisms. When comparing, establish which plan and applications your scope needs, where data is stored and how products and orders are exported. Terms can change; record them in the proposal with the date they were checked.
Self-hosted CMS: more responsibilities for the owner
Another option is store management software installed and maintained in your chosen infrastructure. WooCommerce, for example, runs on WordPress; its official guide covers installation, products, shipping, payments and order management separately.
Self-hosting lets you choose the environment and contractor, but someone must be responsible for updates, backups and recovery. Having a catalogue administrator does not cover these duties: a product editor and a specialist who fixes extension incompatibilities do different jobs.
For a commercial CMS, the product edition matters too. The 1C-Bitrix Site Manager licence comparison distributes capabilities across editions. “A store on Bitrix” is therefore insufficient: the proposal needs the specific edition, add-ons and their purposes. Compatibility with your accounting configuration also needs a separate check.
Custom development: flexibility with a product to maintain
A custom application is worth discussing when important trading rules are difficult to implement through the selected platforms’ standard tools. An order might require particular approvals or be assembled from interdependent components. These are possible requirements, rather than a description of every store.
Someone must design product and order storage, administrative operations, payment, staff roles, updates and recovery from failures. A studio or internal team becomes responsible for those parts. The owner needs to agree who maintains the system after handover and how another team could continue the work.
Compare custom development with a ready-made CMS using the same end-to-end process. An impressive storefront configurator can conceal manual order assembly in accounting software. If that manual work is acceptable initially, record it explicitly instead of paying for automation in advance.
Test the platform with one demanding order
Take an essential scenario that is more involved than a standard purchase. For example: a customer chooses a size, applies a discount and orders delivery to the required region; after payment, a manager issues a partial refund. Your process determines the scenario. There is no need to add unusual conditions just to make the test harder.
For each step, identify the mechanism: a built-in feature, a named extension, customisation or a manual operation. If custom code is needed, establish where it resides and how it remains compatible with platform updates. For an application, find out who maintains it and what happens if it is disabled.
The result should be a demonstration or documented flow for that specific order. A list of integration logos does not establish whether the required fields are transferred or refunds are supported. A limitation at one essential step can rule out a platform before design discussions begin.
Check search visibility and catalogue operations
A store expecting search traffic needs manageable category and product URLs, accessible links and rules for variants. Google explains that extra addresses for the same content and unstable parameters can complicate crawling. These rules help assess an implementation; they do not promise rankings.
Ask to see the planned category with filters, a product page with variants and title editing. Establish who decides which filter combinations are accessible to search engines. Editing metadata is useful, but does not itself determine which pages offer meaningful content that buyers need.
Look at an employee’s ordinary work too: changing a price, uploading stock in bulk and finding an incorrect item. If an essential operation requires a programmer, account for the cost and turnaround of that maintenance.
Understand the exit terms before committing
Every model has a dependency: a cloud supplier, a set of extensions or a development team. Establish in advance which data you can obtain when changing solutions. For the catalogue, variants, images and category relationships matter; for orders, line items, amounts, statuses and identifiers. A file containing product names does not replace a complete export.
Compare development, required subscriptions, maintenance and a potential migration over the same period. Account for confirmed needs for complex features now; record uncertain plans separately. This keeps the first release manageable and chooses its technical foundation around actual trading.
Record the chosen solution’s trading rules and constraints in a technical specification, and compare options’ costs using a shared estimate scope.
If you are choosing between a platform and custom development, tell us how an order should work and which systems need to exchange data. At pommeDeTerre, you can discuss online store development, the first release’s scope and the reasons for choosing a technology.