Building an online store from scratch

A website with a buy button is the easy part. An online store is the machine behind it: catalogue, payments, delivery, stock and support, all leaning on each other. When one piece slips, you don’t get an ugly screenshot. You lose a sale at the moment someone was reaching for their card. That’s why building a store has more to do with what happens after the Place order click than with how the homepage looks.

What follows is the route from idea to a store that takes orders. The platform you build on, payments and delivery, how the catalogue is put together, what moves the price, and the places projects tend to trip. By the end you should be able to make these calls yourself, instead of nodding along to whoever quotes you first.

Start with your products and your process, not the design

Sit with a few questions before anyone says the word “platform”. The whole project leans on the answers.

• How many products, and how often does the range change? Thirty items and thirty thousand are not the same store underneath.
• Do products come in variants (size, colour, configuration), and do you need stock counted per variant?
• Where does the product data live now? Typed in by hand, or pulled from an ERP (the system that already holds your stock and prices) or a supplier feed?
• Once an order arrives, who deals with it, and where should it land: an inbox, a messenger, a CRM?

Without those answers, any number you’re quoted is a guess dressed as a price. The store gets built around how you handle an order. The photo on the front page comes later.

The dearest mistake we see: a gorgeous catalogue gets designed, and stock, payments and returns only come up after launch. Bolting that logic onto a store that’s already live costs far more than wiring it in while it’s still on paper.

Platform: builder, ready-made CMS, or custom

No single answer wins here. It depends on your scale, and there are roughly three roads.

Approach	Who it fits	The real downsides
Builder (Shopify, Wix)	Fast start, up to ~100 simple products	Subscription fees, logic limits, hard to fit non-standard processes
Ready-made CMS (WooCommerce and similar)	Mid-size catalogue, typical needs	Plugins conflict; speed and security need upkeep
Custom development	Complex logic, integrations, large scale	Costlier start, needs a maintenance team

Stuck between snapping it together on a builder and having it built for you? We weigh that up properly in site builder vs custom development. The rough rule: a builder is cheap to begin with and quietly charges you back later through its limits, while custom asks for more upfront and doesn’t run into a wall as you grow.

Payments and delivery: where the sale is won or lost

The customer is on the last step, ready to pay. This is where they either go through or give up. So payments and delivery belong in the plan from the outset, not screwed on once the pretty parts are done.

For payments on the EU market, you’re usually looking at card payment through a gateway (Stripe, Mollie, Adyen), plus whatever your buyers expect on top: PayPal, a local method or two. Every one of those is its own integration, and each one gets tested three ways: the payment that goes through, the one that’s declined, the refund.

Delivery means hooking into your carriers, couriers and pickup points alike, so rates are worked out and labels printed without anyone retyping an address. That’s hours off your team’s week, and a whole class of “wrong street, parcel returned” errors gone.

The order in which these parts go in:

1. A cart that adds up correctly: product, delivery and discounts.
2. An order form that asks for the bare minimum.
3. A payment gateway that copes with every status, not just the happy one.
4. Delivery with carrier choice and rates calculated for the customer.
5. A notification to the customer and to your manager on every order.

Catalogue and product page: where the selling actually happens

A catalogue is a way to find things, not a list to scroll. Once you’re past five hundred products, filters, sorting and a search that works are the whole game. Picture someone who knows roughly what they want, clicks twice, doesn’t see it, and is gone. Faceted filters (narrowing by price, brand, attributes) want to be there from the build. Graft them onto a large database afterwards and you’ll feel it.

The product page does more selling than the homepage ever will. Good photos, a description that tells the truth, what’s in stock, the price, the variants, and a buy button with nothing in the way. A store with a thousand products turns sluggish without much effort, and a page that’s still thinking when the thumb has stopped is a page that gets left. More on that in website speed and Core Web Vitals. The same goes for the phone layout: most people buy from a phone now, so it isn’t a later job.

What the price actually rides on

Stores get quoted one at a time, and two that look identical can sit a few times apart on price. Here’s where the gap comes from.

• The products themselves: how many, and how complicated. Variants, bundles and stock tracking all add weight.
• Integrations. Payment gateways, carriers, CRM, ERP, marketplaces. Every connection is more hours to build and test.
• Where the data comes from, whether someone types it in or it imports automatically with stock kept in sync.
• Content: who’s producing the photos and descriptions for a few hundred items.
• Support once it’s live. A store needs ongoing care, updates, backups, the odd fix. We bill that by the hour and show it plainly, from €60/h (€90/h for urgent work).

We pulled the general pricing logic apart in what actually drives the price of a website. The same line holds for a store: what you pay for is the logic under the pages, never the pages themselves.

The mistakes that cost real money

Launching everything at once is the classic one. Six months polishing features nobody asked for, when a solid core plus the integrations that matter could have been earning already.

A few more worth naming. Going light on payment testing, because the refund or decline path you never tried is the one that loses money and goodwill in front of a customer. A catalogue with no filters, invisible on a short range and a quiet disaster on a long one. Treating mobile and speed as someone else’s problem, when your best buyers are arriving on a phone. And shipping a store with no support plan: leave a site untouched and within a year it’s slow and open to trouble.

If you mostly want to show what you make and gather enquiries rather than run a full cart, a catalogue site might be the better fit. Cheaper, simpler, less to maintain.

A store comes together as a run of decisions, taken in order. If you’re sitting on a product range and the urge to sell online but no clear first step, write us a few lines about what you sell and how orders reach you today. We’ll shape the online store development around the scale you actually have and quote it stage by stage.