Websites

Online store: what to decide before development starts

Catalogue, product attributes, delivery, payment, stock and integrations — decisions made before any layout work. Changing them later costs noticeably more.

In an online store, design isn't the hardest part. The hard part begins where products have to be described consistently, stock has to match reality, and payment and delivery have to fit how the company already works. These decisions are made before development, because changing them later affects almost the entire project.

Catalogue: structure and product attributes

The catalogue is the foundation. Everything else — filters, search, exports, recommendations — is built on top of it.

First you need to define the category structure. There are two forks here that people often pass without thinking:

  • Can a product sit in several categories at once? If so, plan for it upfront — reworking a live catalogue is unpleasant.
  • What counts as a product and what as a product variant? A T-shirt in three colours and four sizes — is that twelve products or one product with twelve variants? The product page, stock, cart and all sales analytics depend on the answer.

Next come attributes. Each category needs its own set of characteristics: shoes have size and material, appliances have power and dimensions. You need to decide which attributes are used in filters, which only in the description, and which are mandatory.

This is also the place to agree on units and formats. If one product lists weight in grams, another in kilograms and a third as the text "about half a kilo", a weight filter is impossible. The rule is simple: anything you need to filter by must be a separate field with a strict format, not part of the description.

A catalogue can't be "filled in later". Products entered under different rules will have to be migrated by hand, and the more of them there are, the more it costs.

Delivery and payment

Delivery options define the logic of the cart and checkout. Questions that need answers before development:

  1. Which delivery methods will there be? Pickup, courier, shipping companies, pickup points — each has its own logic for addresses and lead times.
  2. How is the cost calculated? Flat rate, by zone, by weight and dimensions, by the carrier's tariff via its service. Calculation through a third-party service is an integration with its own timelines and limitations.
  3. Is there free delivery, and above what amount? This affects the cart: the buyer needs to see how much more to add.
  4. What about bulky goods? If part of the range can't be shipped the usual way, the rule should live in the system, not in a manager's head.

Payment is much the same story. Online card payment, cash on delivery, invoices for businesses, instalments — the set depends on the audience. Returns are a separate decision: who processes them, how money goes back to the buyer, whether it's reflected in the system automatically.

If the store sells to both consumers and businesses, that's effectively two checkout scenarios with different fields and different documents. Plan for it immediately — adding a second scenario to a finished checkout costs more than designing it from the start.

Stock: where the truth lives

The most common source of problems in a working store is stock that doesn't match. A buyer placed an order, the money was taken, the item isn't there. Then comes a refund, apologies and a spoiled impression.

Three things need deciding.

Which system is the master. Is stock kept in accounting software, a warehouse program, a CRM or the website itself? There must be one source of truth. If an item can be written off both in the warehouse and on the site, getting out of sync is guaranteed.

How often data syncs. Once a day, every few minutes, or in real time on an event. The faster goods turn over, the more critical the delay. For one-off and rare items the difference is especially noticeable.

What to do at zero. Hide the product, show it marked "out of stock", accept pre-orders. Each option has consequences: a hidden product loses its accumulated search positions, while a page with a label keeps them.

A separate question is reservation. Is an item locked when added to the cart, at checkout, or after payment? And for how long? Without an explicit rule, two buyers will purchase the last unit.

Integrations with accounting systems and CRM

An integration isn't "plugging in a module". It's an agreement about which data flows in which direction and which system is the master for each type of data.

A typical set of directions:

  • From the accounting system to the site: product list, prices, stock, sometimes descriptions and images.
  • From the site to the accounting system: orders, customer data, chosen delivery and payment.
  • From the site to the CRM: enquiries, abandoned carts, purchase history.
  • Back to the site: order statuses, tracking numbers.

Questions to settle in advance: which field matches products across the two systems (SKU, barcode, internal code), what happens on a data conflict, what to do if the accounting system is unavailable at the moment of ordering. The last one matters most: an order mustn't be lost because the accounting system is under maintenance — it's accepted and queued for transfer.

One more thing worth discussing: not everything needs to come from the accounting system. Names and descriptions there are often written for the warehouse, not for the buyer. Sometimes it's better to keep marketing content on the site side and take only prices and stock from accounting.

Who fills in the product pages, and how

The most underestimated part of the project. The store can be ready and still have no sales because the product pages are empty.

You need to answer:

  • Where do texts and photos come from? Your own, from the supplier, bought separately. Supplier descriptions are often duplicated across dozens of stores, and search engines notice.
  • Who physically enters the products? An employee, a contractor, an automatic import from a price list.
  • How long does one product page take? Multiply by the number of products and you get the real launch timeline, which is usually longer than the development timeline.
  • How is quality maintained? You need a standard: which fields are mandatory, what the photo requirements are, how names are worded.
  • How are new products added? Manual entry doesn't scale. If the range updates often, import from a file or from the supplier's system is needed from day one.

A practical tip: create a few real product pages before layout work starts. They immediately show which fields are missing, where descriptions are too long and where photos are the wrong format.

Why it costs more to change later

Because these decisions sit at the foundation, not on top.

Changing the "product — variant" model rewrites the product page, cart, order, exports and analytics. Adding a second warehouse changes the stock logic and delivery calculation. Business customers appearing after launch means new fields, new documents and a new branch in checkout. Replacing the source of truth for stock means redoing the whole integration.

A separate cost is data that has already accumulated. With a dozen products, the structure can be rebuilt. With thousands, and orders coming in, every rework turns into a migration with results that have to be verified.

What to do before starting

A short list worth settling in writing before development begins:

  1. The category structure and the decision on products with variants.
  2. The attribute set for each category, marking what's used in filters.
  3. Delivery methods and cost calculation rules.
  4. Payment methods, the business-customer scenario, the returns procedure.
  5. The master system for stock, sync frequency, behaviour at zero, reservation rules.
  6. The list of integrations with the direction of exchange and the product matching key.
  7. The person responsible for content, the content source and a timeline estimate for the whole range.
  8. A dozen real product pages as a sample.

When these points are settled, development of an online store goes predictably. When they aren't, timelines slip not because of code but because of decisions that will have to be made anyway — only later and at a higher cost. If there's no answer on some point, that's a perfectly good reason to discuss it before the work starts.