What to build an online store on: a website builder, a CMS or custom development

Which products and how many items will be in the catalogue

I look at three things: the product's complexity, the breadth of the assortment and the frequency of changes.

If you have 20 products and simple variants, you can live on a simple solution. If you have thousands of items, attributes, filters and frequent price updates, you need a platform where the catalogue doesn't break the admin panel and speed.

Another marker is structure. One level of categories is almost always simple. Several levels and cross-overs by attributes immediately raise the requirements for the CMS and the database.

Which sales channels you need: SEO, advertising, marketplaces, social media

I clarify where you want sales to come from in the first months and in a year.

If you're betting on SEO, you need proper work with categories, filters and landing pages, and you need speed, because a slow store cuts both rankings and conversion.

If you're betting on advertising, I check how the platform holds peak load and how it gets along with analytics. Advertising quickly exposes weak spots in the cart and checkout.

If you sell through marketplaces and social media, I look at exports, stock and unified accounting. Otherwise you'll start getting confused about prices and availability.

Which processes to automate: warehouse, delivery, returns

I consider an online store not a display case but a process. And that process almost always comes down to accounting and logistics.

If you keep your warehouse in 1C or another system, the integration becomes critical. If you work with delivery by tariffs, pickup points and tracking, the platform must be able to calculate delivery at checkout and pass order statuses.

Returns and exchanges matter too. I fix in advance who makes the decision, where the history is stored and how the client sees the status. Without this, support drowns in manual correspondence.

A builder and SaaS platform

I choose a builder or SaaS when the business needs a fast launch and a minimum of technical tasks. You rent a ready-made platform, assemble the storefront, configure products, connect payment and start selling.

The plus is speed, and that the platform usually covers hosting, basic security and some updates itself. The minus is obvious: you depend on the service's rules, pricing and available integrations, and you live within the ready-made logic of cart, discounts and delivery.

If you plan to grow actively, I immediately look at how you'll take the data out. In such solutions, migrating the catalogue, orders and customers often becomes a separate project.

A CMS with a ready store module

I consider a CMS when you need control over the site and content and want to develop SEO. Here you get your own hosting and admin panel: you install the store module and configure the catalogue structure, filters and search pages.

The plus is flexibility — you can change the design, extend features and better manage category pages and demand landing pages. The minus is responsibility: you need updates, backups and plugin control, otherwise the store accumulates errors, conflicts and speed problems over time.

I always warn about dependence on modules. One critical plugin can become a point of risk: if the developer stops supporting it, you pay with time and money for workarounds.

Custom development on a framework

I choose custom on a framework when the store is already a system, not just a site. You get code and architecture built for your sales model and don't adapt to the limits of ready-made engines.

The plus is that you design the catalogue, prices, discounts, roles and integrations the way the business needs. There's also a plus in speed and stability if the right architecture is built in from the start. The minus is the entry threshold: you need a clear spec, discipline in changes and a support plan after launch.

I look at custom as a long game. It pays off when you know for sure you'll develop the product, connect accounting, automate the warehouse and build personal accounts.

For a fast start and a simple assortment

I recommend this path if you have a small catalogue, clear prices and simple delivery. You need to launch sales, collect the first orders and understand which products actually sell. Here speed matters more than perfect code.

I'd start with a basic set: catalogue, product card, cart, checkout, payment, notifications, and one or two integrations you can't work without every day.

If you're at the start and unsure of the model, a builder often gives the cheapest test. And when stable sales and clear processes appear, you can move to a CMS or custom without chaos.

Limits on design, functionality and data ownership

In builders and SaaS I almost always see the same ceiling: you can assemble a storefront fast, but you rarely can build a store around your own logic.

On design you depend on the template. Colours and blocks change, but you often can't nail a unique catalogue, card and checkout structure — and in an online store that hits conversion.

On functionality you live within what the platform allows: discounts, bundles, roles, B2B prices, complex delivery, partial payment, pre-orders. All of it quickly runs into limits and paid apps, and each app adds risk and cost.

On data I look at three zones: catalogue, customers, orders. In SaaS the data is usually stored with the service; export exists, but it's not always complete and convenient — links are often lost (statuses, payment history, order sources, customer card fields). Then migrating to another system becomes a separate project.

What to check before launch: domain, payments, exports, access

Before launching on a builder I do a short check — it saves weeks of nerves.

Domain — who owns it and where the access is. I fix access to the registrar and the admin email. If the domain is registered to a contractor, you depend on them.

Payments — which payment methods you'll actually accept, how the platform connects payment, how statuses and notifications work, where payment info is stored. It's important to quickly find the problem if a client says they paid.

Exports — export of catalogue, orders and customers: formats and fields, and separately the export of stock and prices if you keep accounting outside the platform. This is item number one if you plan growth and a future migration. Access — roles (admin, content, order operator, accountant) and fixing who has access to payments and the domain. One shared login almost always ends in losses and errors.

Content management and SEO capabilities

A CMS's strength is content. I can build a structure for demand, create category and subcategory pages, manage texts, blocks, internal linking and metadata.

For SEO I immediately check the technical base: clean URLs, canonicals, filter indexing, pagination, microdata, speed. Even on the same CMS the result heavily depends on how the theme and plugins were assembled and how the server was configured.

Another plus is control over landing pages. You aren't limited to cards and categories: you can make pages for brands, collections and scenarios. This helps both SEO and advertising.

Dependence on plugins and updates

With a CMS I always count the risks through plugins. Almost any store on a CMS is assembled from modules: payment, delivery, integrations, SEO, caching, security. That's normal, but it's a system of parts.

Each plugin can conflict with another and requires updates. If you don't update the core and modules, you accumulate vulnerabilities and bugs. If you update without testing, you risk breaking the checkout or cart.

I recommend deciding right away who is responsible for updates, backups and error control. If you have no in-house team, it's easier to plan support from the start. At Qazaqsoft there's a site support and development line for such tasks — it's convenient to connect it after launch, when the store starts to live and change.

What tasks WooCommerce, OpenCart and 1C-Bitrix are usually chosen for

WooCommerce is usually chosen when you need a store alongside content: a blog, articles, landing pages, SEO sections and the catalogue in one admin panel. I see this option in small and medium businesses, when it's important to start fast and then grow features with modules. But I plan support right away — without it, plugins and updates start conflicting.

OpenCart is usually taken when the catalogue and simple trading logic come first: cards, categories, filters, orders, basic discounts. I often see it in stores with a clear assortment that don't need complex content marketing. Here it's important to watch module quality and speed and not turn the store into a builder of random extensions.

1C-Bitrix is usually chosen when the business already lives in the 1C ecosystem and wants a tight link with accounting: orders, stock, statuses, data exchange. Bitrix is also taken by companies that need strict access roles and manageability in the admin panel. But this choice requires discipline: you need an administrator, updates and performance control.

Non-standard logic for prices, discounts, roles and personal accounts

Custom is needed when you have complex prices and don't want to live with compromises. Most often I see these tasks:

• different prices for different customer groups
• B2B terms and personal price lists
• discounts that depend on brand, category, bundle and purchase history
• role-based restrictions: the operator sees one thing, the manager another, the partner a third
• personal accounts where the client sees contracts, invoices, statuses, returns and history

On a CMS this can often be assembled, but then fragility begins: one module drags in another, and you still hit the limits of the logic.

Complex integrations and speed requirements

I choose custom when integrations solve a business task every day. Typical examples:

• warehouse and accounting live in a separate system and the exchange runs by complex rules
• delivery must be calculated at checkout by real tariffs and limits
• you need many data sources: several warehouses, several storefronts, different currencies and rules
• you need high speed for the catalogue, search and filters under heavy traffic

Here I look at the architecture: I design in advance where the truth for stock and prices is stored, who manages order statuses and how the system will survive peak load.

Custom's risks: timelines, support, documentation requirements

Custom has a price, and I always name it plainly.

Timelines — you don't launch in a couple of days; you go through analysis, design, development and testing. If you change requirements along the way, the timelines grow.

Support — the store lives after release: bugs, updates, new integrations, UX improvements. If you don't plan support, custom quickly becomes expensive to own.

Documentation — I require the logic to be fixed: integration diagrams, roles and rights, price and discount rules, order statuses, return scenarios. Without documentation you become hostage to specific people, and any team change becomes a risk.

SEO and content: filters, clean URLs, indexing, speed

I look at SEO as a set of technical edits that are hard to redo later without losses. If the platform doesn't let you manage these things properly, the store will depend only on advertising.

Filters — I decide right away which to index and which not. Filters bring traffic but easily create thousands of junk pages, so the platform must be able to manage indexing, canonicals and pagination and give control over meta-tag templates.

Clean URLs — I check how addresses for categories, subcategories and cards are built. I need a clear URL and a stable structure, so addresses don't change after editing a category or importing products. Indexing — robots.txt, sitemap.xml and rules for duplicates (product variants, sorts, parameters, on-site search).

Speed — I check it on categories, cards and the cart. Slowdowns almost always come from three places: heavy photos, plugins and scripts, a slow server and database. The platform must provide caching and control over what loads on the page, otherwise you lose both rankings and sales.

Conversion and UX: search, product card, checkout

I consider UX the main lever in e-commerce. The same traffic can give different results if the store is inconvenient.

Search — I check how it works by products, SKUs and attributes: you need suggestions, typo correction and proper results. If search is weak, people go to marketplaces because it's faster there.

Product card — how the platform shows price, availability, variants and delivery. The client must understand the product in a minute: photos, specs, reviews, return terms and a clear 'buy' button. If the card blurs the answer, conversion drops even with good design.

Checkout — I count the steps to payment and remove the extra. I don't force registration before purchase unless it's B2B, I check how the platform guides the client after a payment error and how it saves the cart, and I look at checkout on a phone. In Kazakhstan mobile traffic almost always dominates, and a weak checkout kills advertising.

Security and stability: updates, backups, access roles

I treat an online store as an operating system. It has no right to go down while you're running ads and taking orders.

Updates — who updates the core, theme and plugins, and how. In a CMS without updates you accumulate vulnerabilities, in SaaS you depend on the service, in custom — on your own release discipline. In every case you need a process.

Backups — where the backups are and how fast you can recover. I separately check database backups, because orders and customers matter more than pictures. Without clear recovery, any failure turns into downtime and lost money.

Access roles — content manager, order operator, accountant, administrator, with restricted access to payments and critical settings. One shared login always leads to errors and conflicts, and then you can't tell who made a change.

Online payment: what matters for connection and fiscalisation

I first find out where you're registered and how you currently accept money. This affects the connection method and who is responsible for the receipt and reporting.

Then I check payment scenarios: pay by card immediately, pay by link, partial payment, pay on delivery, refund and cancellation. If the platform can't store statuses and process refunds correctly, it'll be hard for you to resolve disputes with clients.

I look at fiscalisation separately. Businesses often think connecting acquiring is enough, then the question of the receipt and linking payment to the order surfaces. I recommend fixing in advance where the receipt is generated, who sends it and how it's reflected in the admin panel. And I don't give everyone one login to the payment account — I set up roles and fix who has rights to refunds and to changing the details.

Delivery: tariffs, tracking, pickup points and checkout calculations

I look at delivery as part of sales. The client decides in the cart: if they don't understand the cost, timeline and terms, they close the tab.

I'd start with a map of regions: Almaty and Astana, the rest of Kazakhstan, self-pickup, pickup points, courier. Each scenario needs its own rules — weight and dimension limits, free delivery above an amount, paid delivery by zones.

Then I check the calculation at checkout: the platform must calculate delivery before payment and show the total without surprises. Tracking matters no less — I set up status transmission (accepted, packed, handed to delivery, in transit, delivered) so the client sees what's happening and support doesn't spend time on explanations.

Accounting and CRM: 1C, warehouse, order statuses and notifications

I always ask one question: where is your source of truth for stock and prices. If it's 1C or warehouse software, the site shouldn't live a separate life.

I check what exactly you want to sync: the catalogue and attributes, stock by warehouse, prices and discounts, reserves, order statuses, documents. If this isn't defined in advance, the integration starts sprawling and breaking processes.

Then I look at order statuses inside the store and in accounting: who changes the status (manager, warehouse, delivery, payment). I recommend making statuses simple and unambiguous and setting up notifications for the client and the team. If you sell through several channels (site, marketplaces, social media, offline), I choose one system as the main one and build the exchange around it rather than duplicating accounting in different places.

If you'd like, I can look at your current set of requirements and tell you whether a builder or CMS will hold up or whether you already need custom. To develop an online store around your process, it makes sense to go to the Qazaqsoft service page for turnkey online-store creation in Almaty and Kazakhstan.

The store hits the platform's speed and limits

At first the store works fine. Then the catalogue, filters, photos and traffic grow — and you start catching slowdowns, especially on mobile and at checkout.

In builders and SaaS you often can't fix the cause, only soften the symptoms. In a CMS you can optimise, but sometimes you hit the core, the plugins and the theme architecture.

The second signal is logic limits: you need one small thing, but the platform won't give it (complex discount rules, delivery combinations, roles for operators and partners, smart search, pre-orders, bonuses), and it all turns into a set of paid modules and conflicts. The third signal is the cost of changes: when any edit takes more and more time and breaks neighbouring features, I suggest costing out custom. Sometimes it's cheaper than endless patches.

Integrations become critical for operations

I consider this the main trigger for moving to custom. While you have one warehouse and simple statuses, you can live on a builder or CMS. But then the business asks to link everything into one flow — and that's where losses begin.

I often see three problems. First — data diverges: stock in accounting is one thing, on the site another; the client pays, but the product isn't there. Second — statuses don't match: payment went through but the order hangs as new; the order shipped but the client doesn't see tracking; a return was agreed but isn't reflected in accounting.

Third — each integration lives as a separate module: today you added payment, tomorrow delivery, then CRM, and you get a tangle where one update breaks another. At this point I'd fix the source of truth (where products, prices, stock and statuses live) and who has the right to change them. If you can't work every day without this, you need an approach where integrations are designed as a system, not as a set of plugins.

You need scaling, roles, B2B features and flexible prices

As the store grows, it stops being one interface for everyone. Roles and scenarios appear, and the platform must hold them without workarounds. I usually see these requests:

• different prices for different clients and contracts
• personal discounts and price lists
• wholesale terms and minimum batches
• deferred payment and invoices
• a B2B client's personal account with documents and order repetition
• roles inside the client's company, where one person places and another approves

Another block is scaling: several warehouses, several cities, different delivery rules, different storefronts for different segments. On ready-made solutions this often turns into compromises that hit the margin and the team's working speed. If you already see such tasks in the plans, it's better to choose an architecture in advance where roles, prices and accounts don't break one another.

Catalogue structure and product attributes

A catalogue isn't a list. It's your future navigation, filters and SEO. First I fix the structure: categories and subcategories, cross-overs (if one product lives in several branches), brands, collections, series.

Then I describe the attributes:

• attributes for filters
• product variants: size, colour, volume
• units of measurement
• SKUs and barcodes, if they matter for accounting
• photos and rules for images

And one more item often forgotten — what counts as a unique product. If you get this wrong, you'll later redo the import, filters and cards.

Rules for pricing, discounts and delivery

I always ask the business to describe the rules on paper — not in their head and not in fragments of correspondence.

Prices: one or several price types, price by warehouse or general, with or without VAT, rounding and currency. Discounts: by amount, by promo code, by client group, on a category or brand, compatibility rules (can they be stacked).

Delivery: zones and cities, the free-delivery threshold, weight and dimension limits, self-pickup and pickup points, calculation before payment and showing the timeline.

If you fix these rules before development, you'll choose a platform faster and configure the checkout more precisely. And you won't change the logic in production when orders are already coming in.

Analytics and events: what to measure from day one

I put analytics on a par with payment and delivery. Without it you don't understand where the store loses money and can't tell a traffic problem from a checkout problem.

I'd measure the purchase funnel (category view, card view, add to cart, going to checkout, choosing delivery and payment, successful payment) and traffic quality by channel (SEO, advertising, social media, marketplaces — not only orders but behaviour too).

Separately I track errors and failures: payment errors, delivery and amount-calculation errors, 404 pages and filter problems, cart preservation after an error. And business metrics that affect decisions: average order value, repeat purchases, the share of cancellations and returns, order processing time.

I recommend writing events for your goals from the start. Otherwise each channel will count its own way, and you'll start arguing with the numbers instead of making decisions.