First, let's talk about this
If your monthly order count is low and your product structure is standard, starting on a hosted platform makes more sense than a shop written from scratch. You'll see the difference not in the setup cost but in the maintenance and update burden.
The reason companies move to custom development is usually rules rather than volume: different pricing for dealers, calculation by dimension, an ERP connection. If none of those apply, don't rush.
The path of a single order
The health of a shop is shown by one order moving from start to finish without interruption. During setup we test that path step by step.
- 01
Finding
The visitor finds the product through search, a category or an ad. The page has to load fast, and price and stock have to be clear.
- 02
Basket
Shipping cost and delivery time belong here. The most common reason baskets get abandoned is a surprise figure appearing at checkout.
- 03
Payment
Card details are entered inside the provider's frame and never reach us. The 3D Secure flow gets tested with a real card.
- 04
Confirmation
The order record opens, both sides get a notification, stock is drawn down.
- 05
Dispatch
The shipping integration creates the consignment, the tracking number is attached to the order and passed to the customer.
- 06
Returns
The cancellation window and return conditions run in line with regulation, and requests are tracked from the panel.
A working example: pekerox.com
A shop selling marine, industrial and solar plant cleaning chemicals. You can open it and look around; everything described here is running there.
The real problem on that job wasn't the number of products. The same product is sold to a boat owner as "bilge cleaner" and to an industrial plant as "heavy degreaser". Forced into a single category tree, none of the three buyer types could find what they were after. We built the categories around use case instead, and a product can appear in more than one.
With chemicals, the use case and the dosage are part of the buying decision. So the technical information sits next to the price, not buried at the bottom of the catalogue page.
- Category, product, basket, shipping and payment all work end to end
- The featured, new arrivals and on-sale rows are managed from the panel
- Built with Next.js, with shop management on a separate panel
Legal obligations when you sell into Turkey
If you're selling online to customers in Turkey, the rules below apply. They aren't optional, and they get planned alongside the technical setup. If you're selling into another country, its own regime applies instead — the equivalents there need checking separately.
This table is for information, not legal advice. We aren't lawyers; the texts need reading by your own solicitor or accountant before they go live.
How is the payment setup chosen?
Two routes: take a virtual POS from your bank, or use a payment provider's infrastructure. The bank's commission is usually lower and the application takes longer. With a payment provider it's the other way round.
Either way, card data doesn't land on our server. The payment page opens inside the provider's frame or through a redirect, which leaves most of the PCI-DSS burden with the provider.
During the application, providers open your site and look at it. If the distance selling contract, returns and delivery terms, privacy policy and clear company details aren't live, the application comes back. We prepare those pages as part of the setup.
The biggest line item: product data
Projects run late because of data, not software. Products with no photograph, whose description sits in a scanned catalogue PDF and whose dimension table lives in scattered spreadsheets don't count as ready to go live.
- For every product: name, code, category, short and long description, at least one photograph
- For products with variants: a dimension and colour table, matched to stock codes
- Weight and volumetric weight, for the shipping calculation
- Descriptions written in the customer's language, not the catalogue's
- A field mapping table, if data is coming across from an ERP
Why search works differently on a shop
Because the page count grows fast. Left unchecked, filter and sort parameters mean the same product list can be reached from dozens of different addresses.
- Canonical management on filter and sort addresses
- Showing alternatives on a sold-out product instead of deleting the page
- A short but genuine description on category pages
- Product and offer structured data, with price and stock status
- Review markup only where there are real customer reviews